唐巧前輩說這些都是 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 限于對對象屬性的跟蹤。