在 #Pragma Conference 2015 會議上，Marcus Zarra，撰寫過關于 Core Data 和 Core Animation 的書， 敘述 了三種在多線程環境下使用 Core Data 的方法并且設法解決在2015年應如何使用Core Data的問題。實際上，Zarras說道，當用一個擁有十一年歷史的技術比如Core Data工作時，你所面臨的問題之一是有大量的信息是可用的，不過查明哪一份信息依舊精確以及哪一份不精確并不是一件簡單的事。

根據Zarras所言，當我們知道我們仍舊有空余的CPU時我們應該使用多線程，那樣我們可以預先處理用戶接下來要使用的數據。多線程另外一個很 重要的用例是通過允許用戶不必等待一個冗長的操作來完成，來改進一個app的靈敏程度，比如網絡操作。多線程幾乎從來不是解決性能問題的辦法并且它是一種 基礎設計決策，而不是一個事后的想法。

最初的方法

最初的方法是在iOS 6推出之前唯一可用的方法。這個方法現在依然可以使用，盡管Zarra建議除了在某些極端情況以外不要使用它。它基于四個主要的原則：

一個 NSPersistentStoreCoordinator (PSC)處理所有磁盤之間的相互影響。

NSManagedObjectContext s (MOCs)與PSC對話并且不知道對方的任何情況。

其中一個MOCs負責UI的更新并且在單一可信來源上起作用。

一個MOC開始意識到另一個MOC的變化的唯一方法是通過 merging 合并處理一個 NSNotification 。

這個設計有一些不足之處，比如需要寫很多公式化的代碼，線程規則不明確會導致不定時發生崩潰以及意外線程阻塞。隨著推出了iOS 8，這些問題改善了一些。并且多虧了一個 debug flag 調試標志，Yosemite才能在它違反Core Data并發模型的時候讓應用程序崩潰。

艱難的方法

Zarras稱之為艱難的方法的是一個依賴于用于多進程訪問SQLite的方法。這就意味著我們可以擁有多個PSC，讓每個MOC都可以擁有自己 的PSC。這會對擺脫任何鎖定問題起到很好的作用并且啟用幾乎所有異步訪問——除非你沒有寫相同的表以及同時把兩個PSC排成一行。

即使有了這個設計，只用一個MOC來把數據反饋到UI是可取的。這個方法會讓用PSC來同步數據變得艱難，因為它們不知道對方的任何情況。此外，線程和可維護性也會被損害。這個方法有趣的一面在于，這就是iCloud如何運作的真實寫照。

最好的方法

根據Zarra所言，最好的辦法并不是速度最快的，但它是到目前為止最簡單和最可持續的方法。它依靠蘋果和iOS 6一起推出的 new APIs ，new APIs允許定義子MOC并且詳細描述一個MOC的并發類型。Zarra呈現的這個設計是基于 NSManagedDocument 如何運作和使用的：

一個單獨的持久性數據協調器。

唯一能實際訪問PSC的一個私有的MOC。

一個主要的MOC聯合UI，它是私有的MOC的子設備。

多個子MOC具體到輔助線程。

這個設計的好處是子MOC所有的變化會自動傳送到其主MOC上，因此消除了合并的需求。

這個設計的主要缺陷是它速度緩慢，盡管只是慢了百分之幾，Zarra說道。它有一個很棘手的問題就是如果進行太多的異步操作，有可能會在UI上起連鎖反應，因為其相關的MOC會受到序列的多重變化，這可能與另一個并不相干。

這個設計一個很重要的細節就是最好不要重復使用很便宜就能創造的子MOC。另一方面，能用很久的子MOC應該與主MOC手動保持同步，因為變化僅僅是從子MOC到主MOC而反之則不行。

Zarra的最后評論是使用 NSManagedDocument 會鎖定UI，所以你最好 做好準備 。

總結

以上是生活随笔為你收集整理的linux单个core的线程,正确使用Core Data多线程的3种方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。