自 CoreData 首先在 OS X 10.4 Tiger 上登陸以來，經(jīng)過那么多版本的發(fā)展，現(xiàn)在各方面已經(jīng)相當(dāng)?shù)耐晟屏?，因而在這次 iOS 8/OS X 10.10 上，CoreData 的特性變化不多，只有幾項，但是都是著眼于性能及體驗
看了好多集 WWDC 了，感覺再不做點筆記又要忘記光了，所以從和我關(guān)系***的 CoreData 開始吧。
自 CoreData 首先在 OS X 10.4 Tiger 上登陸以來，經(jīng)過那么多版本的發(fā)展現(xiàn)在各方面已經(jīng)相當(dāng)?shù)耐晟屏?，因而在這次 iOS 8/OS X 10.10 上，CoreData 的特性變化不多，只有幾項，但是都是著眼于性能及體驗方面的，非常值得一用。
這些分別是：
Batch Updates
說起來，這可能是不用 CoreData 的人***個質(zhì)疑的理由：什么？我竟然不能寫一句簡單的 SQL 把我所有的 Entry 的某個字段給更新或刪除掉，這樣的數(shù)據(jù)庫還算是數(shù)據(jù)庫嗎？
事實就是 CoreData 本來就不是個數(shù)據(jù)庫，不過在發(fā)展了那么多年后，這個 Batch Updates 終于讓它更加「數(shù)據(jù)庫友好」了。
通過新增的 NSBatchUpdateReuqest 和 NSBatchUpdateResult 來完成批量更新數(shù)據(jù)的操作，你終于能非常快速的通過類 SQL 語言更新數(shù)據(jù)庫那樣的操作來對整個數(shù)據(jù)庫進行修改了，而不用像以前一樣，要針對每個 Object 進行更新，又慢又消耗內(nèi)存。它會返回成功或失敗，改變的行數(shù)，被改變的 ID 數(shù)組，簡直就和查詢數(shù)據(jù)庫一樣。
當(dāng)然，這個 Batch Updates 會有一點副作用——即更新后 Context 不會有對應(yīng)的反應(yīng)，因此你需要手動去刷新 Context，以免造成界面和數(shù)據(jù)不一致。其他如限定在 NSManagedObject 上的 validation 也就此失效，所以——就像操作傳統(tǒng)數(shù)據(jù)庫一樣，也要小心使用 CoreData 的 Batch Updates。
Asynchronous Fetching
這算是體驗上的一個很好的改進了，終于有內(nèi)置的設(shè)計優(yōu)良的「異步獲取」方法了，更棒的是，它還能和 NSProgress 這個一起協(xié)作，因此「異步」+「進度更新」可以非常簡單地得到支持。
這個主要由新增的 NSAsynchronousFetchResult 類來完成，這是一個非常典型的立即返回+結(jié)果回調(diào)的東西，你需要在 Private 或 Main 的 Context 來做這個操作，其他的使用就非常簡單。
當(dāng)你有非常多的條目需要一次性載入時，Asynchronous Fetching 就是必用的。
其他
Incremental store 這節(jié)沒怎么看懂，需要再看一遍。此外，在并發(fā)方面，CoreData 除了在以前 NSManagedContext 上對 performBlock 的支持外，還對 NSPersistentStoreCoordinator 也增加了這個的支持。關(guān)于這個我還沒有什么體會，畢竟沒有用到多個 StoreCoordinator。
此外，iOS 也和 OS X 一樣，針對 Concurrecy 也支持這樣的 debug 了：com.apple.CoreData.ConcurrencyDebug 1
***，就是關(guān)于 Swift 對 CoreData 的支持，基本上和 Objective-C 無異，主要是 NSManagedObject 需要用 @NSManaged 來修飾變量，還有 Model 那里需要把 class 的 namespace 也寫進去。
根據(jù)官方演示的例子，同樣的數(shù)據(jù)庫，用 Swift 寫的 CoreData 程序還比 Objective-C 的性能要高…我已經(jīng)迫不及待要用 Swift 來寫我的 iOS App 了。
本文鏈接：http://www.cocoachina.com/applenews/devnews/2014/0724/9235.html
