在文章開(kāi)始之前，我們先明確兩個(gè)基本點(diǎn)：
1.CoreData不是線程安全的，NSManagedObject和NSManagedObjectContext只能在自身的線程中使用。
2.NSPersistentStoreCoordinator（PSC）是可以多線程共享，因此一般CoreData Stack中只使用一個(gè)。
本篇旨在討論一種合理的CoreData Stack，下面列出4種常用CoreData Stack，我們將分別討論它們的優(yōu)劣以及展示一些基本的測(cè)試數(shù)據(jù)，測(cè)試過(guò)程或者由此推斷的結(jié)論若有不妥，歡迎討論。
Stack A
如圖所示，這是最基本的CoreData Stack的形式，也是默認(rèn)勾選“Use CoreData”后系統(tǒng)默認(rèn)生成的結(jié)構(gòu)。
關(guān)于CoreData入門的文章一般采取這種結(jié)構(gòu)，然后會(huì)告訴你“一般的”應(yīng)用只要這樣就夠用了。但我們輕易發(fā)現(xiàn)，增刪改查都在主線程，數(shù)據(jù)量一大，主線程肯定是要被阻塞的。帶來(lái)的唯一結(jié)果就是用戶覺(jué)得你的應(yīng)用很卡，不流暢。
那么問(wèn)題來(lái)了，什么才是“一般的”應(yīng)用，數(shù)據(jù)量要多大才算大？
我們不妨從“流暢”的角度來(lái)反推，以每秒60幀來(lái)算，每幀保持17毫秒左右。
當(dāng)UI的刷新率低于60Hz，那么就會(huì)出現(xiàn)不流暢。
所以我們要保證耗時(shí)操作要么限制在17毫秒以內(nèi)，要么到其他線程去處理。
我做了一些簡(jiǎn)單的測(cè)試，模型的屬性保持10個(gè)左右，在沒(méi)有任何優(yōu)化的情況下，增查兩種操作數(shù)據(jù)量和耗時(shí)的關(guān)系如下表所示。（iPhone 6s真機(jī)測(cè)試）
| 數(shù)據(jù)量 | 查詢耗時(shí)（毫秒） | 插入耗時(shí)（毫秒） |
|---|---|---|
| 100 | 2.6~3.6 | 14~18 |
| 1000 | 5~21.6 | 26~65 |
| 10000 | 56~112 | 302~573 |
| 100000 | 498~539 | 3400~3500 |
以上測(cè)試大致可以知道什么是“一般的”應(yīng)用：
1.單次查詢限制在1000條以內(nèi)
2.單次插入限制在100條以內(nèi)
3.結(jié)合業(yè)務(wù)場(chǎng)景、老機(jī)型處理能力不同等因素，實(shí)際應(yīng)用中以上兩個(gè)數(shù)字必須更小。
優(yōu)點(diǎn)：易上手，適合學(xué)習(xí)和demo演示
缺點(diǎn)：一言不合就阻塞主線程
注意NSFetchedResultsController(FRC)performFetch:調(diào)用時(shí)機(jī)。調(diào)用performFetch:之前insert數(shù)據(jù)不會(huì)觸發(fā)代理方法。
Stack B
Stack B是CoreData多線程的經(jīng)典結(jié)構(gòu)，采用獨(dú)立的主線程MOC和后臺(tái)MOC。
這種結(jié)構(gòu)可以讓你靈活的運(yùn)用其它線程來(lái)做增刪改查，而且Background MOC可以有多個(gè)。
Background MOC可以是臨時(shí)的，創(chuàng)建MOC非常快，不需要考慮性能問(wèn)題。
我們需要考慮的是，由于NSManagedObject只能在該線程使用，因此后臺(tái)MOC查詢到的數(shù)據(jù)模型不能在主線程使用。需要根據(jù)objectID在主線程MOC中用objectWithID:方法重新獲取數(shù)據(jù)模型。
下面是StackA和StackB的比較結(jié)果，同樣是查詢了70萬(wàn)條數(shù)據(jù)并轉(zhuǎn)化成主線程可用的模型：
1.StackA用了1.35秒（直接在主線程查詢，不需要轉(zhuǎn)換）
2.StackB用了1.92秒（在后臺(tái)線程查詢，需要根據(jù)查詢到的objectID，在主線程MOC用objectWithID:方法獲取數(shù)據(jù)）
其實(shí)查詢的耗時(shí)是一樣的，但是StackB需要根據(jù)objectID重新獲取數(shù)據(jù)，因此多用了0.55秒的時(shí)間。
（這次是用模擬器測(cè)試的，切勿和上面真機(jī)的測(cè)試數(shù)據(jù)對(duì)比）
2016-07-01 16:33:24.172 CoreDataTest[4317:171189] StackA:本次查詢740300條數(shù)據(jù)耗時(shí)：1.353634秒
2016-07-01 16:33:30.400 CoreDataTest[4317:171189] StackB:本次查詢740300條數(shù)據(jù)耗時(shí)：1.919627秒 在主線程耗時(shí):0.555359秒
這里有個(gè)問(wèn)題：“轉(zhuǎn)換耗時(shí)”？
主線程MOC調(diào)用objectWithID:獲取NSManagedObject的時(shí)間（就叫做“轉(zhuǎn)換耗時(shí)”吧）能不能省掉？
雖然70萬(wàn)條數(shù)據(jù)的轉(zhuǎn)換耗時(shí)只有0.55秒，但是能不能把這個(gè)做到極致，在主線程一點(diǎn)不卡？
希望看到這里的朋友思考一下，在評(píng)論區(qū)提出您的想法，萬(wàn)分感謝??
另外有個(gè)問(wèn)題：NSFetchedResultsController？
我們?cè)赟tack A中使用FRC來(lái)管理數(shù)據(jù)，那么在Stack B中如何使用FRC？這是官方文檔中的典型應(yīng)用，但沒(méi)有多線程的說(shuō)明。
按照上面的結(jié)構(gòu)圖，F(xiàn)RC只放在主線程MOC，因?yàn)镕RC與UI關(guān)系密切，這點(diǎn)似乎理所當(dāng)然。
細(xì)心的朋友應(yīng)該發(fā)現(xiàn)，圖中各種關(guān)系僅包含Insert、Update和Delete三種操作，這三種操作可以通過(guò)NSManagedObjectContextDidSaveNotification來(lái)跨線程合并，那么查詢操作呢？
由于NSFetchRequest沒(méi)有提供objectID相關(guān)方法，我們無(wú)法將后臺(tái)MOC獲取的objectID轉(zhuǎn)化為FRC中的fetchedObjects。
一次嘗試
這里有個(gè)哥們提出在NSFetchRequest的predicate中加入@"self IN(%@)", objectIDs來(lái)查詢。
我按照他的方法做了測(cè)試，步驟：
1.在后臺(tái)MOC中查詢
2.遍歷查詢結(jié)果，得到objectID數(shù)組
3.切換到主線程，F(xiàn)RC修改predicate，調(diào)用performFetch:獲取數(shù)據(jù)
以下是測(cè)試結(jié)果，看到結(jié)果就覺(jué)得這方法可行但并不靠譜。
StackB單單在主線程的耗時(shí)就比StackA的耗時(shí)長(zhǎng)，還不如直接在主線程查詢。
2016-07-02 10:08:14.423 CoreDataTest[924:41114] StackA:本次查詢19766條數(shù)據(jù)耗時(shí)：0.051086秒
2016-07-02 10:08:18.750 CoreDataTest[924:41114] StackB:本次查詢19766條數(shù)據(jù)耗時(shí)：0.101769秒 在主線程耗時(shí):0.058902秒
2016-07-02 10:16:20.797 CoreDataTest[967:45523] StackA:本次查詢119766條數(shù)據(jù)耗時(shí)：0.231401秒
2016-07-02 10:16:23.882 CoreDataTest[967:45523] StackB:本次查詢119766條數(shù)據(jù)耗時(shí)：0.613336秒 在主線程耗時(shí):0.377715秒
小插曲：
測(cè)試過(guò)程中遇到一個(gè)問(wèn)題，在添加@"self IN(%@)", objectIDspredicate之后，insert操作無(wú)法正常觸發(fā)FRC的代理方法，我的猜想是predicate約束了FRC的監(jiān)聽(tīng)范圍，它只管理滿足這個(gè)predicate的對(duì)象。
于是我又做了一個(gè)小實(shí)驗(yàn)，將predicate改成@"title CONTAINS %@",@"1",也就是獲取名字包含“1”的數(shù)據(jù)。接著不斷insert數(shù)據(jù)，title是隨機(jī)5位數(shù)字，當(dāng)隨機(jī)到名字包含“1”，可以成功insert，而名字不包含“1”則失敗。驗(yàn)證猜想。
另一次嘗試
這里又有個(gè)哥們提出在后臺(tái)MOC中使用FRC，這樣FRC的代理方法都在后臺(tái)線程調(diào)用，如果需要在代理方法中更新UI，切換到主線程更新就可以了。
這樣的做法看上去其實(shí)挺美好的，但稍有不慎可能就出錯(cuò)了。例如在主線程中修改了屬性，甚至讀取了屬性，都是跨線程使用NSManagedObject。參考文章
目前看來(lái)，如果要使用FRC，還是老老實(shí)實(shí)在主線程查詢比較妥當(dāng)，如果您有更好的方案，求大神指點(diǎn)一二。
優(yōu)點(diǎn)：獨(dú)立的MOC可以讓你靈活的使用后臺(tái)線程完成數(shù)據(jù)庫(kù)的耗時(shí)操作。
缺點(diǎn)：轉(zhuǎn)換耗時(shí)問(wèn)題、FRC的使用問(wèn)題。
Stack C
Stack C是iOS 5之后的方案，context之間存在父子關(guān)系。主線程MOC有了幾個(gè)后臺(tái)MOC兒子。
從結(jié)構(gòu)圖中可以發(fā)現(xiàn)，子context調(diào)用save以后，數(shù)據(jù)不會(huì)保存到數(shù)據(jù)庫(kù)，而是上交給父context處理（合并到父context）。
子contex解決了查詢耗時(shí)問(wèn)題，但是需要增刪改大量數(shù)據(jù)時(shí)，最后還是由主線程來(lái)操作數(shù)據(jù)庫(kù)，會(huì)阻塞。
這篇文章給出一個(gè)典型的應(yīng)用場(chǎng)景：一個(gè)存在save和cancel按鈕的頁(yè)面，當(dāng)你修改了某些數(shù)據(jù)，點(diǎn)擊save即提交到父MOC處理，點(diǎn)擊cancel則不需要做任何回滾的操作，因?yàn)檫@個(gè)臨時(shí)工MOC跟你的修改數(shù)據(jù)可以一起丟棄。
另外，父MOC的修改不會(huì)自動(dòng)通知子MOC，而且大多數(shù)情況下子MOC只是臨時(shí)的，也沒(méi)有必要通知。
優(yōu)點(diǎn)：不需要寫(xiě)通知合并的邏輯。
缺點(diǎn)：通過(guò)主線程增刪改會(huì)阻塞。
Stack D
Stack D是Stack C的一種改進(jìn)。它解決了增刪改時(shí)阻塞主線程的問(wèn)題。
Temporary Background MOC秉承Stack C的優(yōu)點(diǎn)，解決查詢耗時(shí)問(wèn)題，取消修改也不需要任何回滾操作。
Main MOC的增刪改會(huì)合并到Writer MOC，不需要我們通過(guò)objectID跨線程傳遞，也不需要寫(xiě)任何合并的邏輯。
對(duì)開(kāi)發(fā)者而言，Stack D相當(dāng)優(yōu)雅。
但這里有篇文章關(guān)于Stack BCD三種結(jié)構(gòu)的性能討論。有興趣的朋友可以了解一下，大致的結(jié)論是Stack B的性能最優(yōu)異，Stack D性能最差。
簡(jiǎn)單總結(jié)
- 數(shù)據(jù)量小，或者可以分批處理的情況，可以使用Stack A
- Stack C基本上沒(méi)有存在意義，當(dāng)然如果你的應(yīng)用查詢?nèi)蝿?wù)較重、增刪改任務(wù)非常輕，也可以嘗試Stack C
- Stack B和Stack D之間如何選擇，前者性能更優(yōu)，后者代碼復(fù)雜度低
