瞭解移動端的數據持久化方式和對應的使用場景,提供相關技術選型作技術儲備。html
在移動端的數據持久化方式整體能夠分爲如下兩類:ios
定義c++
對於使用頻率比較高的數據,從網絡或者磁盤加載數據到內存之後,使用後並不立刻銷燬,下次使用時直接從內存加載。git
案例github
定義算法
將從網絡加載的、用戶操做產生的數據寫入到磁盤,用戶下次查看、繼續操做時,直接從磁盤加載使用。sql
案例數據庫
在緩存設計中,因爲硬件設備的存儲空間不是無限的,咱們指望存儲空間不要佔用過多,僅能緩存有限的數據,可是咱們但願得到更高的命中率。想達到這一目的。一般須要藉助緩存算法來實現。vim
實現原理:數組
FIFO 先進先出的核心思想若是一個數據最早進入緩存中,則應該最先淘汰掉。相似實現一個按照時間前後順序的隊列來管理緩存,將淘汰最先訪問的數據緩存。
示意圖:
問題:
沒有考慮時間最近和訪問頻率對緩存命中率的影響。對於用戶較高几率訪問最近訪問數據的狀況,命中率會比較低。
實現原理:
LFU 最近最少使用算法是基於「若是一個數據在最近一段時間內使用次數不多,那麼在未來一段時間內被使用的可能性也很小」的思路。記錄用戶對數據的訪問次數,將訪問次數多的數據降序排列在一個容器中,淘汰訪問次數最少的數據。
問題:
LFU僅維護各項的被訪問頻率信息,對於某緩存項,若是該項在過去有着極高的訪問頻率而最近訪問頻率較低,當緩存空間已滿時該項很難被從緩存中替換出來,進而致使命中率降低。
實現原理:
LRU 是一種應用普遍的緩存算法。該算法維護一個緩存項隊列,隊列中的緩存項按每項的最後被訪問時間排序。當緩存空間已滿時,將處於隊尾,即刪除最後一次被訪問時間距如今最久的項,將新的區段放入隊列首部。
示意圖:
問題:
LRU算法僅維護了緩存塊的訪問時間信息,沒有考慮被訪問頻率等因素,當存在熱點數據時,LRU的效率很好,但偶發性的、週期性的批量操做會致使LRU命中率急劇降低。例如對於VoD(視頻點播)系統,用戶已經訪問過的數據不會重複訪問等場景。
實現原理:
相比LRU,其核心思想是將「最近使用過1次」的判斷標準擴展爲「最近使用過K次」。具體來講它多維護一個隊列,記錄全部緩存數據被訪問的歷史。僅當數據的訪問次數達到K次的時候,纔將數據放入緩存。當須要淘汰數據時,LRU-K會淘汰第K次訪問時間距當前時間最大的數據。
示意圖:
問題:
須要額外的空間來存儲訪問歷史,維護兩個隊列增長了算法的複雜度,提高了CPU等消耗。
實現原理:
2Q算法相似於LRU-2,不一樣點在於2Q將LRU-2算法中的訪問歷史隊列(注意這不是緩存數據的)改成一個FIFO緩存隊列,即:2Q算法有兩個緩存隊列,一個是FIFO隊列,一個是LRU隊列。
示意圖:
問題:
須要兩個隊列,但兩個隊列自己都比較簡單,2Q算法和LRU-2算法命中率、內存消耗都比較接近,但對於最後緩存的數據來講,2Q會減小一次從原始存儲讀取數據或者計算數據的操做。
實現原理:
MQ算法根據優先級(訪問頻率)將數據劃分爲多個LRU隊列,其核心思想是:優先緩存訪問次數多的數據。
示意圖:
問題:
多個隊列須要額外的空間來存儲緩存,維護多個隊列增長了算法的複雜度,提高了CPU等消耗。
實現內存緩存的技術手段包括蘋果官方提供的NSURLCache,NSCache,還有性能和API上比較有優點的開源緩存庫YYCache、PINCache等。
NSUserDefault
適合小規模數據,弱業務相關數據的緩存。
keychain
Keychain是蘋果提供的帶有可逆加密的存儲機制,廣泛用在各類存用戶名、密碼的需求上。另外,Keychain是系統級存儲,還能夠被iCloud同步,即便App被刪除,Keychain數據依然保留,用戶下次安裝App,能夠直接讀取,一般會用來存儲用戶惟一標識串。因此須要加密、同步iCloud的敏感小數據,通常使用Keychain存取。
文件存儲
數據庫存儲
數據庫適合存取一些關係型的數據;能夠在有大量的條件查詢排序類需求時使用。
根據需求選擇:
蘋果提供的一個簡單的內存緩存,它有着和 NSDictionary 相似的 API,不一樣點是它是線程安全的,而且不會 retain key,內部實現了內存警告處理(僅應用在後臺時,會移除一部分緩存)。
TMCache 最初由 Tumblr 開發,但如今已經再也不維護了。TMMemoryCache 實現了不少 NSCache 並無提供的功能,好比數量限制、總容量限制、存活時間限制、內存警告或應用退到後臺時清空緩存等。TMMemoryCache 在設計時,主要目標是線程安全,它把全部讀寫操做都放到了同一個 concurrent queue 中,而後用 dispatch_barrier_async 來保證任務能順序執行。它錯誤的用了大量異步 block 回調來實現存取功能,以致於產生了很大的性能和死鎖問題。 因爲該庫好久再也不維護,不作詳細對比。
Tumblr 宣佈不在維護 TMCache 後,由 Pinterest 維護和改進的一個緩存SDK。它的功能和接口基本和 TMCache 同樣,但修復了性能和死鎖的問題。它一樣也用 dispatch_semaphore 來保證線程安全,但去掉了dispatch_barrier_async,避免了線程切換帶來的巨大開銷,也避免了可能的死鎖。
PINCaching(protocal)
PINMemoryCache
PINDiskCache
.:/%
)PINCache
pthread_mutex_lock
互斥🔐PINOperationQueue
實現多線程隊列任務大神郭曜源開源的一個內存緩存實現,YYCache是對標PINCache實現的,實現了PINCache大部分的能力,同時作了一些針對性性能優化。 內存緩存相對於 PINMemoryCache 來講,去掉了異步訪問的接口,儘可能優化了同步訪問的性能,用 OSSpinLock pthread_mutex_t互斥鎖來保證線程安全。另外,緩存內部用雙向鏈表和 NSDictionary 實現了 LRU 淘汰算法。 磁盤緩存支持設置文件尺寸閾值來控制寫磁盤仍是存數據庫。
YYMemoryCache
YYDiskCache
YYCache
pthread_mutex_lock
互斥🔐 實現內存緩存線程安全YYCache的讀寫性能均較爲優秀。NSCache和PINCache各有優劣。
性能測試說明:
在YYCache Demo基礎上進行的性能測試,使用的debug包,並不表明真實使用性能狀況。
複製代碼
SDK | API能力 | 易用性 | 實現 | 優缺點 | 是否維護 |
---|---|---|---|---|---|
NSCache | 同步存、取、刪,設置costLimit,countLimit、delegate(僅觸發trim刪除時通知) | 中 | NSLock實現線程安全,內部將key-value信息轉換爲鏈表對象實體,使用NSDictionary存取實體,觸發trim時使用鏈表按cost降序刪除;應用後臺狀態觸發內存警告清除部分存儲 | 官方較可靠,但缺少拓展,功能不完善,性能通常 | apple維護中 |
PINMemoryCache | 同步/異步存、取、刪、判存、執行trim、遍歷全部已存儲數據;設置costLimit、ageLimit、ttlCache(超時數據不返回,清除)、removeAllObjectsOnMemoryWarning、removeAllObjectsOnEnteringBackground;添加刪除key-value block回調;應用進後臺、內存警告block回調; | 高 | 使用pthread_mutex_t互斥鎖實現線程安全,使用NSDictionary存取實體,使用額外的NSDictionary存取實體的建立時間、更新時間、cost、ageLimit等信息,來實現相關能力,使用GCDtimer來定時trim | 功能完善,易用性高,面向協議實現,總體架構清晰,根據存儲的更新時間實現了LRU策略,但內部存儲拆分了多個NSDictionary,致使性能降低 | Pinterest維護中 |
YYMemoryCache | 同步存、取、刪、判存、trim;設置countLimit、costLimit、ageLimit、autoTrimInterval、shouldRemoveAllObjectsOnMemoryWarning、shouldRemoveAllObjectsWhenEnteringBackground、應用進入後臺/接收內存警告block監聽 | 高 | 使用pthread_mutex_t互斥鎖實現線程安全,使用_YYLinkedMapNode內部類實體存儲鍵值對信息來實現雙向列表存儲結構,數據按訪問時間降序排序,基於此實現LRU cache | 功能完善,易用性高,實現了LRU策略,性能高;但未抽象相關協議,內存和磁盤緩存重複度高 | 做者已不在維護 |
小數據存取YYCache完勝。20KB以上文件存取YYCache較快。
性能測試說明: 在YYCache Demo基礎上進行的性能測試,使用的debug包,並不表明真實使用性能狀況。
SDK | API能力 | 易用性 | 實現 | 優缺點 | 是否維護 |
---|---|---|---|---|---|
PINDiskCache | 同步/異步存、取、刪、判斷存在、執行trim date/size/sizeByDate;設置byteLimit、ageLimit、ttlCache(超時數據不返回,清除)、NSDataWritingOptions(文件寫入模式),設置data自定義序列化block、key的自定義編解碼block;添加刪除key-value block回調;刪除全部數據回調;獲取緩存url、空間佔用大小,單個文件的存儲fileUrl;執行指定操做等待文件寫入鎖定打開;遍歷全部的已存儲文件 | 高 | 使用pthread_mutex_t互斥鎖實現讀寫線程安全,使用pthread_cond_t實現文件讀寫保護,使用PINDiskCacheMetadata將文件信息保存在內存中方便快速讀取,使用NSDictionary用key存取實體,,使用GCDtimer來定時trim,使用dispatch_semaphore_t控制併發實現自定義OperationQueue,按順序執行緩存隊列任務 | 功能完善,易用性高,面向協議實現,總體架構清晰,trim操做根據存儲的更新時間實現了LRU策略 | Pinterest維護中 |
YYDiskCache | 同步/異步存、取、刪、判斷存在、執行trim count/cost/age、獲取totalCost、totalCount;設置inlineThreshold、countLimit、costLimit、ageLimit、freeDiskSpaceLimit、autoTrimInterval;設置data自定義序列化block、fileName自定義的block | 高 | 使用dispatch_semaphore_t信號量實現線程安全;使用YYKVStorageItem內部類實體存儲鍵值對key、value、filename、size、modTime、accessTime、extendedData等信息;由YYKVStorage實現具體文件存取,根據sqlite存取小空間數據速度優於直接文件讀寫的特性,設置存取方式閾值,空間小於閾值數據直接存sqlite,超過的閾值的數據索引信息存sqlite,數據存文件,基於此小數據存取性能較PINDiskCache提高數倍 | 功能完善,易用性高,實現了LRU策略,性能高;實現文件不一樣存儲策略更高效;但未抽象相關協議,內存和磁盤緩存重複度高 | 做者已不在維護 |
原生的sqlite使用十分繁瑣,須要大量的代碼來完成一項sql操做,而且是c語言的API,對OC或者其它語言開發者並不友好,假如你想執行一個sql,須要作相似下面的操做:
- (void)example {
sqlite3 *conn = NULL;
//1. 打開數據庫
NSString *path = [NSSearchPathForDirectoriesInDomains(NSDocumentationDirectory, NSUserDomainMask, YES).firstObject stringByAppendingPathComponent:@"MyDatabase.db"];
int result = sqlite3_open(path.UTF8String, &conn);
if (result != SQLITE_OK) {
sqlite3_close(conn);
return;
}
const char *createTableSQL =
"CREATE TABLE t_test_table (int_col INT, float_col REAL, string_col TEXT)";
sqlite3_stmt* stmt = NULL;
int len = strlen(createTableSQL);
//2. 準備建立數據表,若是建立失敗,須要用sqlite3_finalize釋放sqlite3_stmt對象,以防止內存泄露。
if (sqlite3_prepare_v2(conn,createTableSQL,len,&stmt,NULL) != SQLITE_OK) {
if (stmt)
sqlite3_finalize(stmt);
sqlite3_close(conn);
return;
}
//3. 經過sqlite3_step命令執行建立表的語句。對於DDL和DML語句而言,sqlite3_step執行正確的返回值只有SQLITE_DONE。
//對於SELECT查詢而言,若是有數據返回SQLITE_ROW,當到達結果集末尾時則返回SQLITE_DONE。
if (sqlite3_step(stmt) != SQLITE_DONE) {
sqlite3_finalize(stmt);
sqlite3_close(conn);
return;
}
//4. 釋放建立表語句對象的資源。
sqlite3_finalize(stmt);
printf("Succeed to create test table now.\n");
//5. 構造查詢表數據的sqlite3_stmt對象。
const char* selectSQL = "SELECT * FROM TESTTABLE WHERE 1 = 0";
sqlite3_stmt* stmt2 = NULL;
if (sqlite3_prepare_v2(conn,selectSQL,strlen(selectSQL),&stmt2,NULL) != SQLITE_OK) {
if (stmt2)
sqlite3_finalize(stmt2);
sqlite3_close(conn);
return;
}
//6. 根據select語句的對象,獲取結果集中的字段數量。
int fieldCount = sqlite3_column_count(stmt2);
printf("The column count is %d.\n",fieldCount);
//7. 遍歷結果集中每一個字段meta信息,並獲取其聲明時的類型。
for (int i = 0; i < fieldCount; ++i) {
//因爲此時Table中並不存在數據,再有就是SQLite中的數據類型自己是動態的,因此在沒有數據時沒法經過sqlite3_column_type函數獲取,此時sqlite3_column_type只會返回SQLITE_NULL,
//直到有數據時才能返回具體的類型,所以這裏使用了sqlite3_column_decltype函數來獲取表聲明時給出的聲明類型。
string stype = sqlite3_column_decltype(stmt2,i);
stype = strlwr((char*)stype.c_str());
//數據類型以決定字段親緣性的規則解析
if (stype.find("int") != string::npos) {
printf("The type of %dth column is INTEGER.\n",i);
} else if (stype.find("char") != string::npos
|| stype.find("text") != string::npos) {
printf("The type of %dth column is TEXT.\n",i);
} else if (stype.find("real") != string::npos
|| stype.find("floa") != string::npos
|| stype.find("doub") != string::npos ) {
printf("The type of %dth column is DOUBLE.\n",i);
}
}
sqlite3_finalize(stmt2);
sqlite3_close(conn);
}
複製代碼
因爲sqlite在移動端不易直接使用,因此衍生出了許多對seqlite的封裝,包括如下被你們所熟知的流行庫,它們的最終實現都指向sqlite:
有一個特例,它經過自建搜索引擎實現了一套ORM數據存儲:
sqlite數據庫的使用包括增、刪、改、查等基本操做,同時在項目中運用,還須要數據轉模型、數據庫經過增刪表、字段和數據遷移完成版本升級等操做,下文經過對這些操做在各個流行庫中的使用示例來對比各個庫的易用性。
FMDB是對sqlite的面向OC的封裝,把c語言對sql的操做封裝成OC風格代碼。主要有如下特色:
FMDB基本操做示例:
// 建表
NSString *sql = [NSString stringWithFormat:@"CREATE TABLE IF NOT EXISTS t_test_1 ('%@' INTEGER PRIMARY KEY AUTOINCREMENT,'%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' TEXT NOT NULL, '%@' INTEGER NOT NULL, '%@' FLOAT NOT NULL)", KEY_ID, KEY_MODEL_ID, KEY_MODEL_NAME, KEY_SERIES_ID, KEY_SERIES_NAME, KEY_TITLE, KEY_PRICE, KEY_DEALER_PRICE, KEY_SALES_STATUS, KEY_IS_SELECTED, KEY_DATE];
FMDatabaseQueue *_dbQueue = [FMDatabaseQueue databaseQueueWithPath:@"path"];
[_dbQueue inDatabase:^(FMDatabase *db) {
BOOL result = [db executeUpdate:sql];
if (result) {
//
}
}];
// 插入一條數據
NSString *insertSql = [NSString stringWithFormat:@"INSERT INTO 't_test_1'(%@,%@,%@,%@,%@,%@,%@,%@,%@,%@) VALUES(\"%@\",\"%@\",\"%@\",\"%@\",\"%@\",\"%@\",\"%@\",\"%@\",%d,%.2f)", KEY_MODEL_ID, KEY_MODEL_NAME, KEY_SERIES_ID, KEY_SERIES_NAME, KEY_TITLE, KEY_PRICE, KEY_DEALER_PRICE, KEY_SALES_STATUS, KEY_IS_SELECTED, KEY_DATE, model.model_id, model.model_name, model.Id, model.Name, model.title, model.price, model.dealer_price, model.sales_status, isSelected,time];
[_dbQueue inDatabase:^(FMDatabase *db) {
BOOL result = [db executeUpdate:sql];
if (result) {
//
}
}];
// 更新
NSString *sql = @"UPDATE t_userData SET userName = ? , userAge = ? WHERE id = ?";
[_dbQueue inDatabase:^(FMDatabase *db) {
BOOL res = [db executeUpdate:sql,_nameTxteField.text,_ageTxteField.text,_userId];
if (result) {
//
}
}];
// 刪除
NSString *str = [NSString stringWithFormat:@"DELETE FROM t_userData WHERE id = %ld",userid];
[_dbQueue inDatabase:^(FMDatabase *db) {
BOOL res = [db executeUpdate:str];
if (res) {
//
}
}];
// 查找
[_dbQueue inDatabase:^(FMDatabase *db) {
FMResultSet *resultSet = [db executeQuery:@"SELECT * FROM message"];
NSMutableArray<Message *> *messages = [[NSMutableArray alloc] init];
while ([resultSet next]) {
Message *message = [[Message alloc] init];
message.localID = [resultSet intForColumnIndex:0];
message.content = [resultSet stringForColumnIndex:1];
message.createTime = [NSDate dateWithTimeIntervalSince1970:[resultSet doubleForColumnIndex:2]];
message.modifiedTime = [NSDate dateWithTimeIntervalSince1970:[resultSet doubleForColumnIndex:3]];
[messages addObject:message];
}
}];
複製代碼
WCDB是微信技術團隊內部在微信app sqlite使用實踐抽取的一套開源封裝,主要具備如下特色:
提供了其它較多場景的解決方案:
在WCDB內,ORM(Object Relational Mapping)是指
這一過程。經過ORM,能夠達到直接經過Object進行數據庫操做,省去拼裝過程的目的。
WCDB基本操做示例:
//Message.h
@interface Message : NSObject
@property int localID;
@property(retain) NSString *content;
@property(retain) NSDate *createTime;
@property(retain) NSDate *modifiedTime;
@property(assign) int unused; //You can only define the properties you need
@end
//Message.mm
#import "Message.h"
@implementation Message
WCDB_IMPLEMENTATION(Message)
WCDB_SYNTHESIZE(Message, localID)
WCDB_SYNTHESIZE(Message, content)
WCDB_SYNTHESIZE(Message, createTime)
WCDB_SYNTHESIZE(Message, modifiedTime)
WCDB_PRIMARY(Message, localID)
WCDB_INDEX(Message, "_index", createTime)
@end
//Message+WCTTableCoding.h
#import "Message.h"
#import <WCDB/WCDB.h>
@interface Message (WCTTableCoding) <WCTTableCoding>
WCDB_PROPERTY(localID)
WCDB_PROPERTY(content)
WCDB_PROPERTY(createTime)
WCDB_PROPERTY(modifiedTime)
@end
複製代碼
// 建表
WCTDatabase *database = [[WCTDatabase alloc] initWithPath:path];
/*
CREATE TABLE messsage (localID INTEGER PRIMARY KEY,
content TEXT,
createTime BLOB,
modifiedTime BLOB)
*/
BOOL result = [database createTableAndIndexesOfName:@"message"
withClass:Message.class];
//插入
Message *message = [[Message alloc] init];
message.localID = 1;
message.content = @"Hello, WCDB!";
message.createTime = [NSDate date];
message.modifiedTime = [NSDate date];
/*
INSERT INTO message(localID, content, createTime, modifiedTime)
VALUES(1, "Hello, WCDB!", 1496396165, 1496396165);
*/
BOOL result = [database insertObject:message
into:@"message"];
//刪除
//DELETE FROM message WHERE localID>0;
BOOL result = [database deleteObjectsFromTable:@"message"
where:Message.localID > 0];
//修改
//UPDATE message SET content="Hello, Wechat!";
Message *message = [[Message alloc] init];
message.content = @"Hello, Wechat!";
BOOL result = [database updateRowsInTable:@"message"
onProperties:Message.content
withObject:message];
//查詢
//SELECT * FROM message ORDER BY localID
NSArray<Message *> *message = [database getObjectsOfClass:Message.class
fromTable:@"message"
orderBy:Message.localID.order()];
複製代碼
Realm團隊 基於sqlite封裝 自建搜索引擎實現的一套ORM數據庫操做模式,它是MVCC 數據庫,主要具備如下特色:
限制:
Realm基本操做示例:
// 定義模型的作法和定義常規 Objective‑C 類的作法相似
@interface Dog : RLMObject
@property NSString *name;
@property NSData *picture;
@property NSInteger age;
@end
@implementation Dog
@end
RLM_ARRAY_TYPE(Dog)
Dog *mydog = [[Dog alloc] init];
mydog.name = @"Rex";
mydog.age = 1;
mydog.picture = nil; // 該屬性是可空的
NSLog(@"Name of dog: %@", mydog.name);
RLMRealm *realm = [RLMRealm defaultRealm];
[Dog createOrUpdateInRealm:realm withValue:mydog];
// 查找;找到小於2歲名叫Rex的全部狗
RLMResults<Dog *> *puppies = [Dog objectsWhere:@"age < 2 ADN name = 'Rex'"];
puppies.count; // => 0 由於目前尚未任何狗狗被添加到了 Realm 數據庫中
// 存儲
[realm transactionWithBlock:^{
[realm addObject:mydog];
}];
// 檢索結果會實時更新
puppies.count; // => 1
/// 刪除數據
[realm transactionWithBlock:^{
[realm deleteObject:mydog];
}];
//修改數據
[realm transactionWithBlock:^{
theDog.age = 1;
}];
// 能夠在任何一個線程中執行檢索、更新操做
dispatch_async(dispatch_queue_create("background", 0), ^{
@autoreleasepool {
Dog *theDog = [[Dog objectsWhere:@"age == 1"] firstObject];
RLMRealm *realm = [RLMRealm defaultRealm];
[realm beginWriteTransaction];
theDog.age = 3;
[realm commitWriteTransaction];
}
});
複製代碼
性能測試說明:
測試數據見下方。因爲樣本比較少(僅1種數據),只進行了部分寫入和讀取操做,並不能徹底反應某個SDK的綜合性能,僅做爲參考。
測試數據和測試結果見下圖:
順序插入1W條數據:
使用事務插入1W條數據:
讀取1W條數據:
多線程(2條)插入共2W條數據:
SDK | 優勢 | 缺點 | 是否維護 |
---|---|---|---|
FMDB | 較爲輕量級的sqlite封裝,API較原生使用方便許多,對SDK本省的學習成本較低,基本支持sqlite的全部能力,如事務、FTS等 | 不支持ORM,須要每一個編碼人員寫具體的sql語句,沒有較多的性能優化,數據庫操做相對複雜,關於數據加密、數據庫升級等操做須要用戶本身實現 | 是 |
WCDB | 跨平臺;sqlite的深度封裝,支持ORM,基類支持本身繼承,不須要用戶直接寫sql,上手成本低,基本支持sqlite的全部能力;內部較多的性能優化;文檔較完善;拓展實現了錯誤統計、性能統計、損壞修復、反注入、加密等諸多能力,用戶須要作的事情較少 | 內部基於c++實現,基類須要.mm後綴(或者經過category解決),須要額外的宏來標記model和數據庫的映射關係 | 是 |
REALM | 跨平臺;支持ORM;文檔十分完善;MVCC的實現;零拷貝提高性能;API十分友好;提供了配套可視化工具 | 不是基於sqlite的關係型數據庫,不能或很難創建表之間的關聯關係,項目中遇到相似場景可能較難解決; 基類只能繼承自RLMObject,不能自由繼承,不方便實現相似JsonModel等屬性綁定 | 是 |
性能數據:
以SDWebImage(KingFisher)爲表明的圖片緩存庫基本都實現了二級緩存、隊列下載、異步解壓、Category拓展等能力,經常使用的圖片加載展現需求均可以使用它們來完成。
系統的如NSCache、NSKeyedArchive等緩存功能能知足基本的存取需求,可是並不易用。 PINCache 和 YYCache 等這些三方庫拓展了至關多的能力來知足大部分的使用場景,而且內部經過LRU等策略來提高效率,同時內部實現了二級緩存來加快加載速度,能夠考率直接使用。 其中PINCache雖然在一些測試數據上性能並不如YYCache,可是能夠看到github的PINCache最近依然有更新,而YYCache已經兩年沒有代碼提交了,issue沒有處理,遇到問題須要本身處理。 若是考慮維護成本的比例高一些,不妨使用PINCache,反之使用YYCache。
Core Data (本人未使用過)因爲入門門檻高、坑多等緣由致使口碑並不太好,這裏就不推薦嘗試了。 FMDB能夠說通過了大量iOS App的驗證,它雖然在一些擴展能力上並不盡人意,可是其穩定性久經考驗,基於sqlite實現,不改變表結構數據的狀況下,便於直接遷移到如WCDB等實現。 WCDB和Realm一樣都是支持ORM的,基本不須要寫sql語句就能完成增刪改查,都跨平臺,擴展瞭如加密、數據升級等不少便捷的封裝,用起來都比FMDB更爽。 但二者相較,假如你真的想使用ORM,我更推薦WCDB,由於Realm的搜索引擎暫不支持關聯表查詢是硬傷,而WCDB是基於sqlite的,支持直接使用sql語句查詢,若是業務中遇到相似場景沒法解決,還須要從Realm遷移到sqlite花費的力氣就大了。 除此以外,微信團隊自己就在使用WCDB,他們在數億用戶量的狀況下遇到的性能、數據損壞等問題比咱們要多得多,他們作的優化也就更多,而這些優化,你使用WCDB就能夠體驗到。
#參考