你是用什麼方法來持久保存數據的？這是在幾乎每一次關於iOS技術的交流或討論都會被提到的問題，而且大家對這個問題的熱情持續高漲。本文主要從概念上把“數據存儲”這個問題進行剖析，並且結合各自特點和適用場景給大家提供一個選擇的思路，並不詳細介紹某一種方式的技術細節。
談到數據儲存，首先要明確區分兩個概念，數據結構和儲存方式。所謂數據結構就是數據存在的形式。除了基本的NSDictionary、NSArray和NSSet這些對象，還有更復雜的如：關係模型、對象圖和屬性列表多種結構。而存儲方式則簡單的分爲兩種：內存與閃存。內存存儲是臨時的，運行時有效的，但效率高，而閃存則是一種持久化存儲，但產生I/O消耗，效率相對低。把內存數據轉移到閃存中進行持久化的操作稱成爲歸檔。
二者結合起來纔是完整的數據存儲方案，我們最常談起的那些：SQLite、CoreData、NSUserDefaults等都是數據存儲方案。當然在這些框架提供的方案之外，我們自己也可以按照個性化需求訂製方案。這些存儲方案側重不同，支持的形式和方式也各不相同，在不同的使用場景下表現也是各有優劣
以下將對四種存儲方式進行詳細的介紹：
相關廠商內容
AWS技術演講：如何在AWS構建千萬級用戶應用 馮宏華吳博領銜ArchSummit北京2014出品人。 白皮書介紹了幾種存儲使用案例，講解了如何同時使用多種 AWS 雲存儲選項。 QClub：走向海外——IT基礎設施運維、大數據與AWS實踐（10月12日 週日） 白皮書下載：發佈管理的痛點與最佳實踐
NSUserDefaults，用於存儲配置信息
SQLite，用於存儲查詢需求較多的數據
CoreData，用於規劃應用中的對象
使用基本對象類型定製的個性化緩存方案
用NSUserDefaults存儲配置信息
NSUserDefaults被設計用來存儲設備和應用的配置信息，它通過一個工廠方法返回默認的、也是最常用到的實例對象。這個對象中儲存了系統中用戶的配置信息，開發者可以通過這個實例對象對這些已有的信息進行修改，也可以按照自己的需求創建新的配置項。
NSUserDefaults把配置信息以字典的形式組織起來，支持字典的項包括：字符串或者是數組，除此之外還支持數字等基本格式。一句話概括就是：基礎類型的小數據的字典。操作方法幾乎與NSDictionary的操作方法無異，另外還可以通過指定返回類型的方法獲取到指定類型的返回值。
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的作用遠遠不止儲存數據這麼簡單，它可以把整個應用中的對象建模並進行自動化的管理。
MyDocument是一個對象實例，有兩個Collection：Employee和Department，存放各自的對象列表。MyDocument、Employee和Department三個對象以及他們之間的關係都通過CoreData建模，並可以通過save方法進行持久化。
從歸檔文件還原模型時CoreData並不是一次性把整個模型中的所有數據都載入內存，而是根據運行時狀態，把被調用到的對象實例載入內存。框架會自動控制這個過程，從而達到控制內存消耗，避免浪費。
無論從設計原理還是使用方法上看，CoreData都比較複雜。因此，如果僅僅是考慮緩存數據這個需求，CoreData絕對不是一個優選方案。CoreData的使用場景在於：整個應用使用CoreData規劃，把應用內的數據通過CoreData建模，完全基於CoreData架構應用。
使用基本對象類型定製的個性化緩存方案
之前提到的NSUserDefaults和SQLite適合存儲基礎類型的小數據，而CoreData則不適合存儲單一的數據，那麼對於類似圖片這種較大的數據要用什麼方式儲存呢？我給出的建議就是：自己實現一套存儲方案。說到訂製存儲方案大家非常容易質疑，這是不是又在重新發明輪子。我可以非常明確的告訴大家，這絕不是在重新發明輪子。首先要明確，這個所謂的定製方案適用於互聯網應用中對遠程數據的緩存，幾個限制條件缺一不可。
從需求出發分析緩存數據有哪些要求：按Key查找，快速讀取，寫入不影響正常操作，不浪費內存，支持歸檔。這些都是基本需求，那麼再進一步或許還需要固定緩存項數量，支持隊列緩存，緩存過期等。從這些需求入手設計一個緩存方案並不十分複雜，Kache是筆者根據開發應用的需求開發的一套緩存組件，通過分析Kache希望可以給大家一個思路。
Kache扮演的是一個典型緩存角色。應用加載遠程數據生成應用數據對象的同時，通過Kache把數據緩存起來，再次請求則直接通過Kache獲取數據。
緩存對象可以是NSDictionary、NSArray、NSSet或NSData這些可直接歸檔的類型，每個緩存對象對應一個Key。緩存對象包括數據和過期時間，內存中存放在一個單例字典中，閃存中每個對象存爲一個文件。Key空間按照各種順序存放緩存對象的Key集合，Pool爲固定大小的數組，當數量達到上限，最早過期的一個Key將被刪除，對應的緩存對象也被清除。Queue也是固定大小的數組，以先進先出的規則管理Key的增刪。 每一次有新的緩存對象存入，自動檢測Key空間中過期的集合並清除。
此外，控件提供save和load方法支持持久化和重新載入。
Kache最初設計爲存放圖片緩存，之後也曾用於緩存文本數據，由於使用了過期和歸檔相結合的邏輯，可以保證大部分命中的緩存對象都在內存中，從而獲取了較高的效率。讀者可以從Github上獲取Kache源碼瞭解更多。
以上介紹了幾種iOS開發中經常會遇到的儲存數據方法，從其存儲原理、使用方式和適用場景幾方面進行進了簡單的對比。事實上每一款應用都很難採用一種單一的方案完成整個應用的數據儲存任務，需要根據不同的數據類型，選擇最合適的方案，以便整個應用獲得良好的運行時性能。
