作者：seedante 授權本站轉載。

題目來自博客：面試百度的記錄，有些問題我能回答一下，不能回答的或有更好的回答我放個相關鏈接供參考。

唐巧前輩說這些都是 iOS 的基礎問題，應該對此深入的了解。當初看到時，大部分回答不上來，因為平時沒有好好思考整理過。這裡大部分的概念大多會在學習 OC 的過程中遇到過，但還是得經過寫代碼才能有更深的理解。反正我當初看那些設計模式是雲裡霧裡，每個字都認識，就是不知道說的什麼。即使現在，有些東西，我也不是很理解。

Objective-C 底層

Objective-C runtime library：Objective-C 的對象模型，Block 的底層實現結構，消息發送，消息轉發，category，method 實現，class load。

runtime 我在平時很少涉及到，沒有系統學習過，而且很多次看了不久就忘了，所以這裡給出一些不錯的文章的鏈接供參考。這幾個問題在《iOS 7 Programming Pushing the Limits》都有過深入的解讀（我有電子版，是盜版，這裡給出這本書在 Github 的地址，工作後我會把去年看過的盜版書全部補償買回，沒有 iOS 8 的版本，不知道是不是由於盜版太多導致的）。另外，唐巧前輩撰文討論過前兩者：

1.?《Objective-C 對象模型及應用》

唐巧在後記中也提到了 iOS 64-bit 帶來的變化：

那麼就來看看 Session 404 Advanced in Objective-C ，從36分起講相關的東西，喔，看不懂，那還是看看這個吧，在《iOS 7 Programming Pushing the Limits》的 Further Reading: objc_explain_Non-pointer_isa 部分談論了這個問題。

2. 《談 Objective-C Block 的實現》

內容非常翔實，特別是關於 Block 類型的部分，強烈建議做下文章開頭提到的測試：Objective-C Blocks Quiz。

3. 消息發送和消息轉發

消息發送比較好理解，先了解下 runtime 吧，可以查看官方文檔《Objective-C Runtime Guide》。之前學習其他語言的時候還沒有關注過調用函數的背後發生了什麼，在 Objective-C 中，在對象上調用方法稱為發送消息，比如[receiver message];這行代碼，編譯的時候編譯器將之轉換為對 底層 C 函數objc_msgSend 的調用：objc_msgSend(receiver, selector)；在運行時，調用哪個方法則完全由 runtime 決定，甚至在運行時可以替換調用的方法，這是 Objective-C 被稱為動態語言的根本原因。對於消息轉發，說實話我現在還不知道這個的應用場景，看到的大部分博客都是說消息轉發給了你補救措施來應對沒有沒有實現的方法防止 Crash 或者實現類似多繼承的機制，我有個疑惑，干嘛不實現那個方法，而要在代價很大的轉發機制裡處理呢。在《Effective Objective-C 2.0》一書第 12 條 tip 中用 @dynamic 演示了實現動態方法解析的例子來說明消息轉發的意義，老實說，我還是沒有理解這個的意義。這裡有個對官方文檔的中文翻譯和一些注解。

4. Implement of category and method

找到了來自這位比我厲害得多的90後：《刨根問底Objective－C Runtime（3）－ 消息 和 Category》（文章原來的鏈接放進來跟簡書的處理有沖突，這裡給的是博客地址，而不是這篇文章的具體地址，不過很好找）。

5. Class load

可以看這篇博客：《Objective-C Class Loading and Initialization》，看了下作者的 Github，原來是我以前 follow 過的國外程序員，看人家的 repo 和星星，質量有保障，再看博客文章列表，有很多深入底層的內容，一座寶礦啊。另外在《Effective Objective-C 2.0》書中第51節《精簡 initialize 與 load 的實現》中也討論了這個問題，當初看完一頭霧水，如今終於能看懂啦。

Core Data: 大量數據多線程同步

這個問題我已經單獨成篇放到這裡了，添加了更多的基礎知識和介紹。

第一步：搭建 Core Data 多線程環境

這個問題首先要解決的是搭建 Core Data 多線程環境。NSManagedObjectContext 不是線程安全的，你不能隨便地開啟一個後台線程訪問 managed object context 進行數據操作就管這叫支持多線程了。Core Data 對多線程的支持比較好，NSManagedObjectContext 在初始化時可以指定並發模式，有三種選項：

1.NSConfinementConcurrencyType

這種模式是用於向後兼容的，使用這種模式時你應該保證不能在其他線程使用 context，但這點很難保證，不推薦使用。此模式在 iOS 9中已經被廢棄。

2.NSPrivateQueueConcurrencyType

在一個私有隊列中創建並管理 context。

3.NSMainQueueConcurrencyType

其實這種模式與第 2 種模式比較相似，只不過 context 與主隊列綁定，也因此與應用的 event loop 很親密。當 context 與 UI 更新相關的話就使用這種模式。

搭建多線程 Core Data 環境的方案一般如下，創建一個 NSMainQueueConcurrencyType 的 context 用於響應 UI 事件，其他涉及大量數據操作可能會阻塞 UI 的就使用 NSPrivateQueueConcurrencyType 的 context。環境搭建好了，如何實現多線程操作？官方文檔《Using a Private Queue to Support Concurrency》為我們做了示范，在 private queue 的 context 中進行操作時，應該使用以下方法：

?func?performBlock(_?block:?()?->?Void)//在私有隊列中異步地執行?Blcok
?func?performBlockAndWait(_?block:?()?->?Void)//在私有隊列中執行?Block?直至操作結束才返回

要在不同線程中使用 managed object context 時，不需要我們創建後台線程然後訪問 managed object context 進行操作，而是交給 context 自身綁定的私有隊列去處理，我們只需要在上述兩個方法的 Block 中執行操作即可。而且，在 NSMainQueueConcurrencyType 的 context 中也應該使用這種方法執行操作，這樣可以確保 context 本身在主線程中進行操作。

第二步：數據的同步操作

多 context 同步最簡單的方案如下：

NSNotificationCenter.defaultCenter().addObserver(self,?
?????????????????????????????????????????????selector:?"backgroundContextDidSave:",?
?????????????????????????????????????????????????name:?NSManagedObjectContextDidSaveNotification,?
???????????????????????????????????????????????object:?backgroundContext)
func?backgroundContextDidSave(notification:?NSNotification){
????mainContext.performBlock(){
????????mainContext.mergeChangesFromContextDidSaveNotification(notification)
????}
}

NSManagedObjectContext 在執行保存操作後會發出 NSManagedObjectContextDidSaveNotification，包含了 context 所有的變化信息，包括新增的、更新的以及刪除的對象的信息；而 mergeChangesFromContextDidSaveNotification(_ notification) 方法則用於合並其他 context 中發生的變化。

如果 context 並未觀察其他 context 的 NSManagedObjectContextDidSaveNotification通知，且保存時，persistent store 已經被其他 context 更改過，那麼很可能存在差異，此時同步就有了以下幾種選擇：選擇保存 context 中的版本或者使用 persistent store 的版本替換 context 的版本，又或是將兩者的版本融合。這種同步方式由 NSManagedObjectContext 的 mergePolicy屬性決定。

1.NSErrorMergePolicy

默認策略，有沖突時保存失敗，persistent store 和 context 都維持原樣，並返回錯誤信息，是唯一反饋錯誤信息的合並策略。

2.NSMergeByPropertyStoreTrumpMergePolicy

當 persistent store 和 context 裡的版本有沖突，persistent store 裡的版本有優先權， context 裡使用 persistent store 裡的版本替換，但是 context 裡沒有沖突的變化則不會受到影響。

3.NSMergeByPropertyObjectTrumpMergePolicy

與上面相反，context 裡的版本有優先權，persistent store 裡使用 context 裡的版本替換，但是 persistent store 裡沒有沖突的變化不受影響。

4.NSOverwriteMergePolicy

用 context 裡的版本強制覆蓋 persistent store 裡的版本。

5.NSRollbackMergePolicy

放棄 context 中的所有變化並使用 persistent store 中的版本進行替換。

同步是件很復雜的事情，實際上還是需要根據實際需要來選擇同步方案。上面兩種方案中第一種概念簡單實現容易，第二種比較復雜相對危險，需要謹慎選擇同步策略。還有一點需要注意，如果需要跨線程使用 managed object，那麼不要直接在其他 context 裡使用該 managed object，而應該通過該對象的 objectID 將該對象 fetch 到 context 裡。

最後，搞定大量數據

多線程和同步問題解決，最後的難點：大量數據。大量數據意味著需要我們關注內存占用和性能，寫代碼時需要記得以下規則：

1.盡可能緩存需要的數據，不相關的數據保持 faults狀態。

2.fetch 時盡可能精准，少引入不相關的數據。

3.構建多 context 時盡量將同類 managed object 集中，最大限度減少合並需求。

4.提升操作效率，對Asynchronous Fetch, Batch Update，Batch Delete 等新特性盡可能利用。

多線程編程

在 iOS 編程中，這幾種情況下需要處理多線程：UI 事件必須在主線程裡進行，其他的可以放在後台進行；而進行一些耗時長或阻塞線程的任務，最後放進後台線程裡進行。iOS 的多線程技術有這麼幾種：線程，GCD 和 NSOperationQueue。線程這種技術比較復雜，而多線程編程向來是「復雜必死」，推薦盡可能使用後二者，但線程有個後二者沒有的優勢：能夠精確保證任務執行的時間。GCD 全稱是 Grand Central Dispatch, 是 libdispatch 這個庫的外部代號，基於 C 的底層來實現；而NSOperationQueue，通稱操作隊列，是基於 GCD 實現的。GCD 能做的 NSOperationQueue 基本上都能做，而且還有些 GCD 中不易實現的特性，如掛起、取消任務，雖然在 iOS 8 中，GCD 也提供了取消任務的功能，但在 GCD 中任務的掛起和取消都有較大的局限性；雖然大多數情況下應該使用抽象級別更高的 API，也就是 NSOperationQueue，但處理一般的後台任務我偏愛 GCD，主要是 GCD 搭配 Blcok 使用簡單，非常方便。如何選擇，下面兩個鏈接對此問題的討論值得一看：

StackOverflow: NSOperation vs. Grand Central Dispatch

Blog: When to use NSOperation vs. GCD

另外，還推薦這些文章：objc 的並發編程專題《Concurrent Programming》 及中文翻譯版本；雷純鋒的博客《iOS 並發編程之 Operation Queues》；NSHipster 的《NSOperation》。

設計模式

評價 Delegate, Notification, KVO 幾種設計模式的優缺點

我不覺得這個問題是個好問題，與其比較這幾個設計模式的優缺點，不如談它們各自的特點比較好，因為它們是為了解決某類問題才設計出來的，有各自適合的使用場景。另外，給個 iOS 中設計模式的介紹：iOS Design Patterns。

為什麼出題目都喜歡把這三個設計模式拿來對比呢？Notification 和 KVO都是用於協助對象間的通信：某個對象監聽某個事件的發生，當某個事件發生時，該對象會得到通知然後做出響應。這幾句話大概是以前看過的書本上說的。如果你以前沒接觸過設計模式，第一次學習時總是能夠看到事件、響應這類模糊的詞匯，看得你雲裡霧裡，好吧，我說的是我。 但 delegate，應該說沒有監聽的功能，而是當事件發生或時機到了，要求 delegate 對象做點什麼。剛開始學習 OC 的時候，一本書中將 delegate比喻為助手，那時候不怎麼理解，現在覺得這個比喻十分恰當。雖然delegate 模式在 OC 中隨處可見，在UIViewController 類中廣泛存在，但在開發 FaceAlbum 的過程中只遇到過一次自定義 protocol/delegate 的情況，後來還是用 KVO 取代了。相對於 Notification 和 KVO 模式，使用 delegate 模式你會明確知道對象的 delegate 能干什麼，因為要成為 某個對象的delegate，該對象得遵守指定的 protocol，protocol 指定了 delegate 對象需要實現的方法。

Notification和 KVO兩者都需要監聽事件的對象(早期看見事件就犯暈，如今寫來覺得用這個詞挺順手的)去注冊，delegate則需要 delegate 對象遵守指定的 protocol；Notification 中監聽者向一個單例對象NSNotificationCenter注冊，NSNotificationCenter類似一個廣播中心，接受任何對象的注冊，後者則向要監聽的對象注冊，一對一，這兩者都不需要對象之間有聯系，而 delegate 則需要通信的對象通過變量聯系；NSNotification模式裡監聽的對象與被監聽的對象通信是通過 NSNotificationCenter 這個中介，而KVO 裡，不能說兩者是直接通信的，我沒有了解過過 KVO 是如何實現通信的，從表面上看兩者就那麼心靈感應一般，這是系統替我們實現的，而delegate，由於通過變量連接，直接向 delegate 發送消息即可，在這點上，NSNotification不需要通信雙方知道對方，而後兩者則不然；在響應事件時，NSNotification和 KVO 模式裡都是在注冊時指定響應方法，而 delegate 則在 protocol 裡預定義了響應方法。

說了這麼多，不直觀，說個實際場景，比如在 UICollectionView 裡選擇 cell 的時候，希望 title 能夠跟蹤選中 cell 的數量。這裡用NSNotification和 KVO 都能實現，但是我更喜歡 KVO，感覺更優雅，因為使用NSNotification模式的話，選中一個 cell 的時候要在選擇的方法裡手動發布通知，而 KVO，只要對觀察的屬性實現 KVO 兼容的方法就可以了；而delegate，自己做自己的 delegate，呃。而面對一些系統裡的事件，比如鍵盤的出現與消失，圖片庫的變化，使用NSNotification更加自然，因為 KVO 限於對對象屬性的跟蹤。

暫時寫這麼多，推薦博客《When to use Delegation, Notification, or Observation in iOS》，可能需要翻牆。