技術

最近正在準備換份工作, 看到網上有份題庫, 覺得不錯, 準備整理下, 複習下所學知識, 為面試做足準備, 下面是我整理了一上午的題庫答案, 希望能幫大家溫習下知識; 當然如果同為找工作的朋友, 也希望你能找到份誠心的工作;之後的答案已附下方, 謝謝大家(^__^) 嘻嘻……

基礎

① 什麼是動態語言？
動態語言，是指程式在執行時可以改變其結構：新的函式可以被引進，已有的函式可以被刪除等在結構上的變化。比如眾所周知的ECMAScript(JavaScript)便是一個動態語言。除此之外如Ruby、Python等也都屬於動態語言，而C、C++等語言則不屬於動態語言。
有三個名詞容易混淆：
Dynamic Programming Language (動態語言或動態程式語言)
Dynamically Typed Language (動態型別語言)
Statically Typed Language (靜態型別語言)
所謂的動態型別語言，意思就是型別的檢查是在執行時做的。
② 靜態型別
而靜態型別語言的型別判斷是在執行前判斷（如編譯階段），比如C#、

Java就是靜態型別語言，靜態型別語言為了達到多型會採取一些型別鑑別手段，如繼承、介面，而動態型別語言卻不需要，所以一般動態語言都會採用dynamic typing，常出現於指令碼語言中.需要明確說明一點，那就是，是不是動態型別語言與這門語言是不是型別安全的完全不相干的，不要將它們聯絡在一起！
優缺點：
靜態型別語言的主要優點在於其結構非常規範，便於除錯，方便型別安全；缺點是為此需要寫更多的型別相關程式碼，導致不便於閱讀、不清晰明瞭。動態型別語言的優點在於方便閱讀，不需要寫非常多的型別相關的程式碼；缺點自然就是不方便除錯，命名不規範時會造成讀不懂，不利於理解等。順便說一下，現在有這樣一種趨勢，那就是合併動態型別與靜態型別在一種語言中，這樣可以在必要的時候取長補短，Boo就是一個很好的試驗性例子。
③

Objective-C的動態執行性
objective-c語言是C語言的一個子類，所以objective-c是一個靜態語言，但是Objective-C的三大特性之一的多型性讓其擁有了動態性。
oc的動態性讓程式可以在執行時判斷其該有的行為，而不是像c等靜態語言一樣在編譯構建時就確定下來。它的動態性主要體現在一下三個方面：
* 動態型別 * 如id型別。實際上靜態型別因為其固定性和可預知性而使用得更加廣泛。靜態型別是強型別，而動態型別屬於弱型別。執行時決定接收者。
這裡補充講一下強、弱型別：語言有無型別、強型別和弱型別三種。無型別的不做任何檢查，甚至不區分指令和資料；弱型別的檢查很弱，僅能區分指令和資料；強型別的嚴格在編譯期進行檢查。強型別語言在沒有強制型別轉化前，不允許兩種不同型別的變數相互操作
* 動態繫結 * 讓程式碼在執行時判斷需要呼叫什麼方法，而不是在編譯時。與其他面嚮物件語言一樣，方法呼叫和程式碼並沒有在編譯時連線在一起，而是在訊息傳送時才進行連線。執行時決定呼叫哪個方法。
* 動態載入 * 讓程式在執行時新增程式碼模組以及其他資源。使用者可以根據需要載入一些可執行程式碼和資源，而不是在啟動時就載入所有元件。可執行程式碼中可以含有和程式執行時整合的新類。
物件是執行時類的一個例項。在類裡聲明瞭的例項變數和方法，它的每個例項都在記憶體中擁有同樣的例項變數，以及指向那些方法的指標。在oc中物件永遠是通過指標來引用的。

3.為什麼代理要用weak？代理的delegate和dataSource有什麼區別？block和代理的區別?
代理屬性都用weak或是assign修飾, 現整理下weak(assign)與strong(retain)修飾區別:

@property (nonatomic, weak) id<MainVCDelegate>delegate;

• 1

• 1

weak:指明該物件並不負責保持delegate這個物件，delegate這個物件的銷燬由外部控制

@property (nonatomic, strong) id<MainVCDelegate>delegate;

• 1

• 1

strong：該物件強引用delegate，外界不能銷燬delegate物件，會導致迴圈引用(Retain MainVC)

Datasource和Delegate兩者的區別:
Datasource 是在告訴使用者之前的view中都有什麼東西，有什麼屬性啊，屬性的值都是多少，是隻關於資料的東西。
Delegate 是在告訴使用者之前的view有什麼方法可以供我呼叫。
一個是資料，一個是操作.

block和代理的區別:
首先兩者作用是一樣的，都是進行單一回調。不同的是，delegate是個物件，然後用過一個物件自己呼叫代理協議函式來完成整個流程。block是傳遞一個函式指標，利用函式指標執行來進行回撥。還有在記憶體管理上需要注意，delegate不需要儲存引用。block對引用資料有copy的處理。

3. 屬性的實質是什麼？包括哪幾個部分？屬性預設的關鍵字都有哪些？@dynamic關鍵字和@synthesize關鍵字是用來做什麼的？
屬性的組成: @property = ivar + getter + setter;
例項變數+get方法+set方法,也就是說使用@property 系統會自動生成setter和getter方法;

我們經常使用assign,weak,strong,copy,nonatomic,atomic,readonly等關鍵字，下面我們列個表格去歸納一下屬性關鍵字具體作用:

@synthesize和@dynamic區別, 在宣告property屬性後，有2種實現選擇:
@synthesize
編譯器期間，讓編譯器自動生成getter/setter方法。
當有自定義的存或取方法時，自定義會遮蔽自動生成該方法
@dynamic
告訴編譯器，不自動生成getter/setter方法，避免編譯期間產生警告
然後由自己實現存取方法
或存取方法在執行時動態建立繫結：主要使用在CoreData的實現NSManagedObject子類時使用，由Core Data框架在程式執行的時動態生成子類屬性
iOS_研究(3)[email protected] 屬性的本質是什麼?

5.屬性的預設關鍵字是什麼？
對於基本資料型別預設關鍵字是
atomic,readwrite,assign
對於普通的OC物件
atomic,readwrite,strong

6.NSString為什麼要用copy關鍵字，如果用strong會有什麼問題？（注意：這裡沒有說用strong就一定不行。使用copy和strong是看情況而定的）
怎麼用 copy 關鍵字？

8.可變集合類 和 不可變集合類的 copy 和 mutablecopy有什麼區別？如果是集合是內容複製的話，集合裡面的元素也是內容複製麼？
首先我們要先明白一個概念，什麼是淺複製，單層深複製，完全複製(每一層都深複製)
淺複製也就是所說的指標複製，並沒有進行物件複製;
單層深複製，也就是我們經常說的深複製，我這裡說的單層深複製是對於集合類所說的(即NSArray,NSDictionary,NSSet)，單層深複製指的是隻複製了該集合類的最外層，裡邊的元素沒有複製，(即這兩個集合類的地址不一樣，但是兩個集合裡所儲存的元素的地址是一樣的);
完全複製，指的是完全複製整個集合類，也就是說兩個集合地址不一樣，裡邊所儲存的元素地址也不一樣;
明白了這三個概念之後，我們就來說一下他們的區別所在：
- 非集合類（NSString，NSNumber）

[immutableObject copy]  //淺複製  
[immutableObject mutableCopy] //深複製
[mutableObject copy] //深複製
[mutableObject mutableCopy] //深複製

• 1
• 2
• 3
• 4

• 1
• 2
• 3
• 4

結論：不可變進行copy是淺複製，mutableCopy是深複製，可變的copy，mutableCopy都是深複製
- 集合類（NSArray，NSDictionary, NSSet):

[immutableObject copy]  //淺複製
[immutableObject mutableCopy] //單層深複製
[mutableObject copy] //單層深複製
[mutableObject mutableCopy] //單層深複製

• 1
• 2
• 3
• 4

• 1
• 2
• 3
• 4

結論：不可變進行copy是淺複製，mutableCopy是單層深複製，可變的copy，mutableCopy都是單層深複製
那麼如何實現多層複制呢？
以NSArray舉例說明

 NSArray *copyArray = [[NSArray alloc] initWithArray:array copyItems:YES];  // 完全複製

• 1

• 1

需要特別注意的是
以上我們所說的兩種情況預設都實現了NSCopying和NSMutableCopying協議
對於自定義繼承自NSObject的類
- copy需要實現NSCopying協議，然後實現以下方法，否則copy會crash

-(id)copyWithZone:(NSZone *)zone {
      CopyObject  *copy = [[[self class] alloc] init];
      copy.name = self.name;
      copy.mobile = self.mobile;
      copy.company = self.company;
      copy.descInfo = self.descInfo;
      return copy;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

• mutableCopy時，需要實現NSMutableCopying協議，否則mutableCopy會crash

-(id)mutableCopyWithZone:(NSZone *)zone {
      MutableCopyObject  *mutableCopy = [[[self class] alloc] init];
      mutableCopy.name = self.name;
      mutableCopy.mobile = self.mobile;
      mutableCopy.company = self.company;
      mutableCopy.descInfo = self.descInfo;
      return mutableCopy;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

9.為什麼IBOutlet修飾的UIView也適用weak關鍵字？
因為當我們將控制元件拖到Storyboard上，相當於新建立了一個物件，而這個物件是加到檢視控制器的view上，view有一個subViews屬性，這個屬性是一個數組，裡面是這個view的所有子view，而我們加的控制元件就位於這個陣列中，那麼說明，實際上我們的控制元件物件是屬於view的，也就是說view對加到它上面的控制元件是強引用。當我們使用Outlet屬性的時候，我們是在viewController裡面使用，而這個Outlet屬性是有view來進行強引用的，我們在viewController裡面僅僅是對其使用，並沒有必要擁有它，所以是weak的。

如果將weak改為strong，也是沒有問題的，並不會造成強引用迴圈。當viewController的指標指向其他物件或者為nil，這個viewController銷燬，那麼對控制元件就少了一個強引用指標。然後它的view也隨之銷燬，那麼subViews也不存在了，那麼控制元件就又少了一個強引用指標，如果沒有其他強引用，那麼這個控制元件也會隨之銷燬。

不過，既然沒有必將Outlet屬性設定為strong，那麼用weak就好了;

一個控制元件可以在viewController裡面有多個Outlet屬性，就相當於一個物件，可以有多個指標指向它（多個引用）。

但是一個Outlet屬性只能對應一個控制元件，也就是說，如果有button1和button2，button1在viewController裡面有一個名為button的Outlet屬性，此時button指向button1，但是如果用button2給button重新賦值，那麼此時button指向button2。也就是說，後來的覆蓋原來的。

一個控制元件可以在viewController裡面觸發多個IBAction。比如有一個button控制元件，在viewController裡面有幾個方法，那麼點選button，會觸發所有的這些方法。

如果我有多個控制元件，比如button1,button2,button3，它們也可以同時繫結一個buttonClick方法，無論點選button1,button2還是button3，都會觸發這個buttonClick方法。

上面說了，button1,button2,button3有可能都觸發buttonClick方法，如果想在buttonClick方法裡面區分到底是哪個button觸發的可能有好幾種做法。

可以給這三個button各設定一個Outlet屬性，然後在buttonClick裡面判斷sender和哪個Outlet屬性是同一物件，這樣就可以區分了。但是很明顯，這樣並不合理，因為建立的三個屬性有些浪費。
我們可以給三個button各加一個tag，在buttonClick裡面通過switch(或者if…)判斷，sender的tag和給各個button加上的tag是否一致，如果一致則為同一物件。
要慎用tag。因為view有一個viewWithTag:方法，可以在view的子view裡面找到和我們傳入的tag相同的view，這樣哪怕不給這個控制元件建立Outlet屬性，也可以通過tag找到這個物件。但是很明顯，這個方法要遍歷子view，比較每個子view的tag，這樣效率並不高，所以儘量要避免這種情況。

10.nonatomic和atomic的區別？atomic是絕對的執行緒安全麼？為什麼？如果不是，那應該如何實現？
在預設情況下，由編譯器所合成的方法會通過鎖定機制確保其原子性(atomicity)。如果屬性具備nonatomic特質，則不需要同步鎖。

下面說一下atomic與nonatomic的區別:
具備atomic特質的獲取方法會通過鎖定機制來確保其操作的原子性。也就是說，如果兩個執行緒同時讀取一個屬性，那麼不論何時，總能看到有效的屬性值。

如果不加鎖的話（或者說使用nonatomic語義），那麼當其中一個執行緒正在改寫某屬性值的時候，另外一個執行緒也許會突然闖入，把尚未修改好的屬性值讀取出來。發證這種情況時，執行緒讀取道德屬性值肯能不對。

一般iOS程式中，所有屬性都宣告為nonatomic。這樣做的原因是：
在ios中使用同步鎖的開銷比較大， 這會帶來效能問題。一般情況下並不要求屬性必須是“原子的”，因為這並不能保證“執行緒安全”(thread safety)，若要實現“執行緒安全”的操作，還需採用更為深層的鎖定機制才行。

例如：一個執行緒在連續多次讀取某個屬性值的過程中有別的執行緒在同時改寫該值，那麼即便將屬性宣告為atomic，也還是會讀取到不同的屬性值。

因此，iOS程式一般都會使用nonatomic屬性。但是在Mac OS X程式時， 使用atomic屬性通常都不會有效能瓶頸;

然而atomic一定是執行緒安全的麼，回答是NO ：

nonatomic的記憶體管理語義是非原子性的，非原子性的操作本來就是執行緒不安全，而atomic的操作是原子性的，但並不意味著他就是執行緒安全的，它會增加正確的機率，能夠更好的避免執行緒錯誤，但仍舊是不安全的。

為了說atomic與nonatomic的本質區別其實也就是在setter方法上的操作不同：

nonatomic的實現:

- (void)setCurrentImage:(UIImage *)currentImage
{
    if (_currentImage != currentImage) {
        [_currentImage release];
        _currentImage = [currentImage retain];

        // do something
    }
}

- (UIImage *)currentImage
{
    return _currentImage;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

atomic的實現:

- (void)setCurrentImage:(UIImage *)currentImage
{
    @synchronized(self) {
        if (_currentImage != currentImage) {
            [_currentImage release];
            _currentImage = [currentImage retain];

            // do something
        }
    }
}

- (UIImage *)currentImage
{
    @synchronized(self) {
        return _currentImage;
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

Using the @synchronized Directive
The @synchronized directive is a convenient way to create mutex locks on the fly in Objective-C code. The @synchronized directive does what any other mutex lock would do—it prevents different threads from acquiring the same lock at the same time. In this case, however, you do not have to create the mutex or lock object directly. Instead, you simply use any Objective-C object as a lock token, as shown in the following example:

- (void)myMethod:(id)anObj
{
    @synchronized(anObj)
    {
        // Everything between the braces is protected by the @synchronized directive.
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7

• 1
• 2
• 3
• 4
• 5
• 6
• 7

The object passed to the @synchronized directive is a unique identifier used to distinguish the protected block. If you execute the preceding method in two different threads, passing a different object for the anObj parameter on each thread, each would take its lock and continue processing without being blocked by the other. If you pass the same object in both cases, however, one of the threads would acquire the lock first and the other would block until the first thread completed the critical section.

As a precautionary measure, the @synchronized block implicitly adds an exception handler to the protected code. This handler automatically releases the mutex in the event that an exception is thrown. This means that in order to use the @synchronized directive, you must also enable Objective-C exception handling in your code. If you do not want the additional overhead caused by the implicit exception handler, you should consider using the lock classes.

For more information about the @synchronized directive, see The Objective-C Programming Language.

當使用atomic時，雖然對屬性的讀和寫是原子性的，但是仍然可能出現執行緒錯誤：當執行緒A進行寫操作，這時其他執行緒的讀或者寫操作會因為等該操作而等待。當A執行緒的寫操作結束後，B執行緒進行寫操作，所有這些不同執行緒上的操作都將依次順序執行——也就是說，如果一個執行緒正在執行 getter/setter，其他執行緒就得等待。如果有執行緒C在A執行緒讀操作之前release了該屬性，那麼還會導致程式崩潰。所以僅僅使用atomic並不會使得執行緒安全，我們還要為執行緒新增lock來確保執行緒的安全。

更準確的說應該是讀寫安全，但並不是執行緒安全的，因為別的執行緒還能進行讀寫之外的其他操作。執行緒安全需要開發者自己來保證。

其實無論是否是原子性的只是針對於getter和setter而言，比如用atomic去操作一個NSMutableArray ，如果一個執行緒迴圈讀資料，一個執行緒迴圈寫資料，肯定會產生記憶體問題，這個就跟getter和setter就木有關係了。

12.用StoryBoard開發介面有什麼弊端？如何避免？
- 難以維護
Storyboard在某些角度上，是難以維護的。我所遇到過的實際情況是，公司一個專案的2.0版本，設計師希望替換原有字型。然而原來專案的每一個Label都是採用Storyboard來定義字型的，因此替換新字型需要在Storyboard中更改每一個Label。
幸虧我們知道Storyboard的原始檔是XML，最終寫了一個讀取-解析-替換指令碼來搞定這件事。

• 效能瓶頸
  當專案達到一定的規模，即使是高效能的MacBook Pro,在開啟Storyboard是也會有3-5秒的讀取時間。無論是隻有幾個Scene的小東西，還是幾十個Scene的龐然大物，都無法避免。Scene越多的檔案，開啟速度越慢(從另一個方面說明了分割大故事板的重要性)。
  讓人沮喪的是，這個造成卡頓的專案規模並不是太難達到。
  我猜想是由於每一次開啟都需要進行I/O操作造成的，Apple對這一塊的快取優化沒有做到位。可能是由於Storyboard佔用了太多記憶體，難以在記憶體中進行快取。Whatever,這個問題總是讓人困擾的。
  然而需要指出的是，採用Storyboard開發或採用純程式碼開發的App，在真機的執行效率上，並沒有太大的區別。

• 錯誤定位困難
  Storyboard的初學者應該對此深有體會。排除BAD_EXCUSE錯誤不說，單單是有提示的錯誤，就足以讓人在程式碼和Storyboard之間來回摸索，卻無法找到解決方案。
  一個典型的例子是，在程式碼中刪除了IBOUTLET屬性或者IBAction方法，但是卻忘了在Storyboard中刪除對應的連線，執行後crash。然而控制檯只會輸出一些模糊其詞的錯誤描述。

*** Terminating app due to uncaught exception 'NSUnknownKeyException', 
reason: '[ setValue:forUndefinedKey:]:  
this class is not key value coding-compliant for the key drawButton.'

• 1
• 2
• 3

• 1
• 2
• 3

最後
一方面是其提供的便利，另一方面是Apple對Storyboard的大力支援。這一點巨集觀上看，可以在以往對Storyboard的改進和增強上看出，微觀上看，幾乎所有iOS 8之後的simple code都或多或少採用了Storyboard作為介面開發工具;

13.程序和執行緒的區別？同步非同步的區別？並行和併發的區別？
程序和執行緒:
程序中所包含的一個或多個執行單元稱為執行緒（thread）。比如一個應用程式就是一個程序, 而它又包含了多個執行緒;主要差別在於它們是不同的作業系統資源管理方式。程序有獨立的地址空間，一個程序崩潰後，在保護模式下不會對其它程序產生影響，而執行緒只是一個程序中的不同執行路徑。執行緒有自己的堆疊和區域性變數，但執行緒之間沒有單獨的地址空間，一個執行緒死掉就等於整個程序死掉，所以多程序的程式要比多執行緒的程式健壯，但在程序切換時，耗費資源較大，效率要差一些。但對於一些要求同時進行並且又要共享某些變數的併發操作，只能用執行緒，不能用程序;

同步和非同步:
在進行網路程式設計時，我們通常會看到同步、非同步、阻塞、非阻塞四種呼叫方式以及他們的組合。
其中同步方式、非同步方式主要是由客戶端（client）控制的，具體如下：
同步（Sync）
所謂同步，就是發出一個功能呼叫時，在沒有得到結果之前，該呼叫就不返回或繼續執行後續操作。
根據這個定義，Java中所有方法都是同步呼叫，應為必須要等到結果後才會繼續執行。我們在說同步、非同步的時候，一般而言是特指那些需要其他端協作或者需要一定時間完成的任務。
簡單來說，同步就是必須一件一件事做，等前一件做完了才能做下一件事。
例如：B/S模式中的表單提交，具體過程是：客戶端提交請求->等待伺服器處理->處理完畢返回，在這個過程中客戶端瀏覽器不能做其他事。
非同步（Async）
非同步與同步相對，當一個非同步過程呼叫發出後，呼叫者在沒有得到結果之前，就可以繼續執行後續操作。當這個呼叫完成後，一般通過狀態、通知和回撥來通知呼叫者。對於非同步呼叫，呼叫的返回並不受呼叫者控制。
總結來說，同步和非同步的區別：請求發出後，是否需要等待結果，才能繼續執行其他操作。

並行(parallellism)和併發(concurrency)的區別:
並行是指兩個或者多個事件在同一時刻發生；而併發是指兩個或多個事件在同一時間間隔發生。

並行，是每個cpu執行一個程式;

併發，是在同一個cpu上同時（不是真正的同時，而是看來是同時，因為cpu要在多個程式間切換）執行多個程式;
併發和並行的區別

14.執行緒間通訊？
- 使用全域性變數主要由於多個執行緒可能更改全域性變數，因此全域性變數最好宣告為violate
- 使用訊息實現通訊在Windows程式設計中，每一個執行緒都可以擁有自己的訊息佇列（UI執行緒預設自帶訊息佇列和訊息迴圈，工作執行緒需要手動實現訊息迴圈），因此可以採用訊息進行執行緒間通訊sendMessage,postMessage。

1)定義訊息#define WM_THREAD_SENDMSG=WM_USER+20;  
2)新增訊息函式宣告afx_msg int OnTSendmsg(); 
3)新增訊息對映ON_MESSAGE(WM_THREAD_SENDMSG,OnTSM) 
4)新增OnTSM()的實現函式；
5)線上程函式中新增PostMessage訊息Post函式

• 1
• 2
• 3
• 4
• 5

• 1
• 2
• 3
• 4
• 5

• 使用事件CEvent類實現執行緒間通訊
  Event物件有兩種狀態：有訊號和無訊號，執行緒可以監視處於有訊號狀態的事件，以便在適當的時候執行對事件的操作。

1)建立一個CEvent類的物件：CEvent threadStart;它預設處在未通訊狀態； 
2)threadStart.SetEvent();使其處於通訊狀態； 
3)呼叫WaitForSingleObject()來監視CEvent物件

• 1
• 2
• 3

• 1
• 2
• 3

15.GCD的一些常用的函式？（group，barrier，訊號量，執行緒同步）
- dispatch_group
- dispatch_barrier
- dispatch_semaphore(訊號量)
附:
iOS GCD 執行緒同步方法

17.資料持久化的幾個方案（fmdb用沒用過)
- plist檔案（屬性列表）
- preference（偏好設定）
- NSKeyedArchiver（歸檔）
- SQLite 3
- CoreData
iOS中幾種資料持久化方案

18.說一下AppDelegate的幾個方法？從後臺到前臺呼叫了哪些方法？第一次啟動呼叫了哪些方法？從前臺到後臺呼叫了哪些方法？

1. – (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions NS_AVAILABLE_IOS(3_0);

• 1

• 1

當應用程式啟動時（不包括已在後臺的情況下轉到前臺），呼叫此回撥。launchOptions是啟動引數，假如使用者通過點選push通知啟動的應用，這個引數裡會儲存一些push通知的資訊。

2. – (void)applicationDidBecomeActive:(UIApplication *)application;
// Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.

• 1
• 2

• 1
• 2

當應用程式全新啟動，或者在後臺轉到前臺，完全啟用時，都會呼叫這個方法。如果應用程式是以前執行在後臺，這時可以選擇重新整理使用者介面。

3. – (void)applicationDidEnterBackground:(UIApplication *)application NS_AVAILABLE_IOS(4_0);
// Use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later.
// If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.

• 1
• 2
• 3

• 1
• 2
• 3

當用戶從前臺狀態轉入後臺時，呼叫此方法。使用此方法來釋放資源共享，儲存使用者資料，無效計時器，並儲存足夠的應用程式狀態資訊的情況下被終止後，將應用 程式恢復到目前的狀態。如果您的應用程式支援後臺執行，這種方法被呼叫，否則呼叫applicationWillTerminate：使用者退出。

4. – (void)applicationWillEnterForeground:(UIApplication *)application NS_AVAILABLE_IOS(4_0);
// Called as part of the transition from the background to the inactive state; here you can undo many of the changes made on entering the background.

• 1
• 2

• 1
• 2

當應用在後臺狀態，將要進行動前臺執行狀態時，會呼叫此方法。
如果應用不在後臺狀態，而是直接啟動，則不會回撥此方法。
從後臺到前臺2, 4; 第一次啟動1, 2; 從前臺到後臺3;

19.NSCache優於NSDictionary的幾點？
NSCache勝過NSDictionary之處在於，當系統資源將要耗盡時，它可以自動刪減快取。如果採用普通的字典，那麼就要自己編寫掛鉤，在系統發出“低記憶體”通知時手工刪減快取。

NSCache並不會“拷貝”鍵，而是會“保留”它。此行為用NSDictionary也可以實現，然而需要編寫相當複雜的程式碼。NSCache物件不拷貝鍵的原因在於：很多時候，鍵都是不支援拷貝操作的物件來充當的。因此，NSCache不會自動拷貝鍵，所以說，在鍵不支援拷貝操作的情況下，該類用起來比字典更方便。另外，NSCache是執行緒安全的，而NSDictionary則絕對不具備此優勢。

21.實現description方法能取到什麼效果？
一般情況下，我們在使用NSLog 和 %@ 輸出某個物件時，就會呼叫這個物件的 description 方法，它的返回值就是 NSString 字串型別，所以 description 預設實現返回的格式是 <類名: 物件的記憶體地址>
如圖:

以上輸出實現的具體步驟為：
①呼叫物件p的-description方法
②拿到-description方法的返回值（NSString*）顯示到螢幕上
③-description方法預設返回的是“類名+記憶體地址”

那麼，既然description方法的預設實現是返回類名和物件的記憶體地址，所以在必要情況下，我們需要重寫description方法以達到改變輸出結果目的，覆蓋description方法的預設實現，比如重寫上述程式碼 Person 類的 description方法，返回_age和_name成員變數的值：

重寫完description方法後，再呼叫NSLog(@”%@”,p)時輸出結果不再是<類名： 記憶體地址>，而是返回的字串：

22.objc使用什麼機制管理物件記憶體？
- MRC(manual retain-release)手動記憶體管理
- ARC(automatic reference counting)自動引用計數
- Garbage collection (垃圾回收)。但是iOS不支援垃圾回收, ARC作為LLVM3.0編譯器的一項特性, 在iOS5.0 (Xcode4) 版本後推出的。
- ARC的判斷準則, 只要沒有強指標指向物件, 物件就會被釋放.
iOS開發系列—Objective-C之記憶體管理