正確使用Core Data多線程的3種方式

在 #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，所以你最好 做好准備 。

查看英文原文： Three Ways to Get Core Data Multithreading Right