iOS資料存放區

標籤：

【reference】http://www.infoq.com/cn/articles/data-storage-in-ios

談到資料儲存，首先要明確區分兩個概念，資料結構和儲存方式。所謂資料結構就是資料存在的形式。除了基本的NSDictionary、NSArray和NSSet這些對象，還有更複雜的如：關聯式模式、對象圖和屬性列表多種結構。而儲存方式則簡單的分為兩種：記憶體與快閃記憶體。記憶體儲存是臨時的，運行時有效，但效率高，而快閃記憶體則是一種持久化儲存，但產生I/O消耗，效率相對低。把記憶體資料轉移到快閃記憶體中進行持久化的操作稱成為歸檔。

二者結合起來才是完整的資料存放區方案，我們最常談起的那些：SQLite、CoreData、NSUserDefaults等都是資料存放區方案。當然在這些架構提供的方案之外，我們自己也可以按照個人化需求訂製方案。這些儲存方案側重不同，支援的形式和方式也各不相同，在不同的使用情境下表現也是各有優劣。但萬變不離其宗，無論什麼方案都可以用來解釋。

 

圖1，儲存方案

以下將對四種儲存方式進行詳細的介紹：

• NSUserDefaults，用於儲存配置資訊
• SQLite，用於儲存查詢需求較多的資料
• CoreData，用於規劃應用中的對象
• 使用基本物件類型定製的個人化緩衝方案

用NSUserDefaults儲存配置資訊

NSUserDefaults被設計用來存放裝置和應用的配置資訊，它通過一個Factory 方法返回預設的、也是最常用到的執行個體對象。這個對象中儲存了系統中使用者的配置資訊，開發人員可以通過這個執行個體對象對這些已有的資訊進行修改，也可以按照自己的需求建立新的配置項。

圖2，筆者手機中[NSUserDefaults standardUserDefaults]內容

NSUserDefaults把配置資訊以字典的形式組織起來，支援字典的項包括：字串或者是數組，除此之外還支援數字等基本格式。一句話概括就是：基礎類型的小資料的字典。操作方法幾乎與NSDictionary的操作方法無異，另外還可以通過指定傳回型別的方法擷取到指定類型的傳回值。

圖3，NSUserDefaults提供的指定傳回型別的方法列表

NSUserDefaults的所有資料都放在記憶體裡，因此操作速度很快，並還提供一個歸檔方法：+ (void)synchronize。開發人員自訂的配置項（2中的最後一項 key:alkdjfkladsjfmm）會以plist格式的檔案歸檔在相應應用目錄的/Library/Preferences/[App_Bundle_Identifier].plist檔案。再次初始化獲得執行個體對象後，架構會把使用者自訂的這個配置和系統配置合并得到完整資料。

用SQLite儲存查詢需求較多的資料

iOS的SDK裡預置了SQLite的庫，開發人員可以自建SQLite資料庫。SQLite每次寫入資料都會產生IO消耗，把資料歸檔到相應的檔案。

SQLite擅長處理的資料類型其實與NSUserDefaults差不多，也是基礎類型的小資料，只是從組織形式上不同。開發人員可以以關係型資料庫的方式組織資料，使用SQL DML來管理資料。 一般來說應用中的格式化的文本類資料可以存放在資料庫中，尤其是類似聊天記錄、Timeline等這些具有條件查詢和排序需求的資料。

每一個資料庫的控制代碼都會在記憶體中都會被分配一段緩衝，用於提高查詢效率。另一個方面，由於查詢快取，當產生大量控制代碼或資料量較大時，會出現緩衝過大，造成記憶體浪費。

SQLite的使用起來要比NSUserDefaults複雜的多，因此建議開發人員使用SQLite要搭配一個操作控制項使用，可以簡化操作。筆者開發的SQLight是一款對SQLite操作的封裝，把相對複雜的SQLite命令封裝成對象和方法，可以供大家參考。大家可以在Github上擷取這個工程的代碼進一步瞭解。

用CoreData規劃應用中對象

官方給出的定義是，一個支援持久化的，對象圖和生命週期的自動化管理方案。嚴格意義上說CoreData是一個管理方案，他的持久化可以通過SQLite、XML或二進位檔案儲存。如官方定義所說，CoreData的作用遠遠不止儲存資料這麼簡單，它可以把整個應用中的對象建模並進行自動化的管理。

圖4，官方文檔中解釋CoreData給出的對象圖樣本

正如所示，MyDocument是一個對象執行個體，有兩個Collection：Employee和Department，存放各自的對象列表。MyDocument、Employee和Department三個對象以及他們之間的關係都通過CoreData建模，並可以通過save方法進行持久化。

從歸檔檔案還原模型時CoreData並不是一次性把整個模型中的所有資料都載入記憶體，而是根據運行時狀態，把被調用到的對象執行個體載入記憶體。架構會自動控制這個過程，從而達到控制記憶體消耗，避免浪費。

無論從設計原理還是使用方法上看，CoreData都比較複雜。因此，如果僅僅是考慮快取資料這個需求，CoreData絕對不是一個優選方案。CoreData的使用情境在於：整個應用使用CoreData規劃，把應用內的資料通過CoreData建模，完全基於CoreData架構應用。

蘋果官方給出的一個範例程式碼，結構相對簡單，可以協助大家入門CoreData。

使用基本物件類型定製的個人化緩衝方案

之前提到的NSUserDefaults和SQLite適合儲存基礎類型的小資料，而CoreData則不適合儲存單一的資料，那麼對於類似圖片這種較大的資料要用什麼方式儲存呢？我給出的建議就是：自己實現一套儲存方案。說到訂製儲存方案大家非常容易質疑，這是不是又在重新發明輪子。我可以非常明確的告訴大家，這絕不是在重新發明輪子。首先要明確，這個所謂的定製方案適用於互連網應用中對遠端資料的緩衝，幾個限制條件缺一不可。

從需求出發分析快取資料有哪些要求：按Key尋找，快速讀取，寫入不影響正常操作，不浪費記憶體，支援歸檔。這些都是基本需求，那麼再進一步或許還需要固定快取項目數量，支援隊列緩衝，緩衝到期等。從這些需求入手設計一個緩衝方案並不十分複雜，Kache是筆者根據開發應用的需求開發的一套緩衝組件，通過分析Kache希望可以給大家一個思路。

圖5，Kache架構圖

如所示，Kache扮演的是一個典型緩衝角色。應用載入遠端資料產生應用資料對象的同時，通過Kache把資料緩衝起來，再次請求則直接通過Kache擷取資料。

緩衝對象可以是NSDictionary、NSArray、NSSet或NSData這些可直接歸檔的類型，每個緩衝對象對應一個Key。緩衝對象包括資料和到期時間，記憶體中存放在一個單例字典中，快閃記憶體中每個對象存為一個檔案。Key空間按照各種順序存放緩衝對象的Key集合，Pool為固定大小的數組，當數量達到上限，最早到期的一個Key將被刪除，對應的緩衝對象也被清除。Queue也是固定大小的數組，以先進先出的規則管理Key的增刪。 每一次有新的緩衝對象存入，自動檢測Key空間中到期的集合并清除。

此外，控制項提供save和load方法支援持久化和重新載入。

Kache最初設計為存放圖片緩衝，之後也曾用於緩衝文本資料，由於使用了到期和歸檔相結合的邏輯，可以保證大部分命中的緩衝對象都在記憶體中，從而擷取了較高的效率。讀者可以從Github上擷取Kache源碼瞭解更多。

以上介紹了幾種iOS開發中經常會遇到的儲存資料方法，從其儲存原理、使用方式和適用情境幾方面進行進了簡單的對比。事實上每一款應用都很難採用一種單一的方案完成整個應用的資料儲存任務，需要根據不同的資料類型，選擇最合適的方案，以便整個應用獲得良好的運行時效能。

 

iOS資料存放區