iOS进阶之fmdb程序员iOS程序猿

iOS数据持久化设计探讨（NSCache，PINCache，YY

2019-01-16  本文已影响12人  wentianen

一、目标

了解移动端的数据持久化方式和对应的使用场景，提供相关技术选型做技术储备。

二、数据持久化的目的

  1. 快速展示，提升体验
    • 已经加载过的数据，用户下次查看时，不需要再次从网络（磁盘）加载，直接展示给用户
  2. 节省用户流量（节省服务器资源）
    • 对于较大的资源数据进行缓存，下次展示无需下载消耗流量
    • 同时降低了服务器的访问次数，节约服务器资源。（图片）
  3. 离线使用。
    • 用户浏览过的数据无需联网，可以再次查看。
    • 部分功能使用解除对网络的依赖。（百度离线地图、图书阅读器）
    • 无网络时，允许用户进行操作，等到下次联网时同步到服务端。
  4. 记录用户操作
    • 草稿：对于用户需要花费较大成本进行的操作，对用户的每个步骤进行缓存，用户中断操作后，下次用户操作时直接继续上次的操作。
    • 已读内容标记缓存，帮助用户识别哪些已读。
    • 搜索记录缓存
      ...

三、数据持久化方式分类

在移动端的数据持久化方式总体可以分为以下两类：

1、内存缓存

2、磁盘缓存

四、缓存策略(常见缓存算法)

在缓存设计中，由于硬件设备的存储空间不是无限的，我们期望存储空间不要占用过多，仅能缓存有限的数据，但是我们希望获得更高的命中率。想达到这一目的。通常需要借助缓存算法来实现。

1、FIFO（First in First out）

实现原理：

FIFO 先进先出的核心思想如果一个数据最先进入缓存中，则应该最早淘汰掉。类似实现一个按照时间先后顺序的队列来管理缓存，将淘汰最早访问的数据缓存。

示意图：

image

问题：

没有考虑时间最近和访问频率对缓存命中率的影响。对于用户较高概率访问最近访问数据的情况，命中率会比较低。

2、LFU（Least Frequently Used）

实现原理:

LFU 最近最少使用算法是基于“如果一个数据在最近一段时间内使用次数很少，那么在将来一段时间内被使用的可能性也很小”的思路。记录用户对数据的访问次数，将访问次数多的数据降序排列在一个容器中，淘汰访问次数最少的数据。

image

问题:

LFU仅维护各项的被访问频率信息,对于某缓存项,如果该项在过去有着极高的访问频率而最近访问频率较低,当缓存空间已满时该项很难被从缓存中替换出来,进而导致命中率下降。

3、 LRU (LeastRecentlyUsed)

实现原理：

LRU 是一种应用广泛的缓存算法。该算法维护一个缓存项队列,队列中的缓存项按每项的最后被访问时间排序。当缓存空间已满时,将处于队尾,即删除最后一次被访问时间距现在最久的项,将新的区段放入队列首部。

示意图：

[图片上传失败...(image-4f390b-1547643827199)]

问题：

LRU算法仅维护了缓存块的访问时间信息，没有考虑被访问频率等因素，当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降。例如对于VoD（视频点播）系统，用户已经访问过的数据不会重复访问等场景。

4、 LRU-K (LeastRecentlyUsed)

实现原理：

相比LRU，其核心思想是将“最近使用过1次”的判断标准扩展为“最近使用过K次”。具体来说它多维护一个队列，记录所有缓存数据被访问的历史。仅当数据的访问次数达到K次的时候，才将数据放入缓存。当需要淘汰数据时，LRU-K会淘汰第K次访问时间距当前时间最大的数据。

示意图：

[图片上传失败...(image-3bf47d-1547643827199)]

问题：

需要额外的空间来存储访问历史，维护两个队列增加了算法的复杂度，提升了CPU等消耗。

5、2Q（Two queues）

实现原理：

2Q算法类似于LRU-2，不同点在于2Q将LRU-2算法中的访问历史队列（注意这不是缓存数据的）改为一个FIFO缓存队列，即：2Q算法有两个缓存队列，一个是FIFO队列，一个是LRU队列。

示意图：

[图片上传失败...(image-ae0de1-1547643827199)]

问题：

需要两个队列，但两个队列本身都比较简单，2Q算法和LRU-2算法命中率、内存消耗都比较接近，但对于最后缓存的数据来说，2Q会减少一次从原始存储读取数据或者计算数据的操作。

6、MQ（Multi Queue）

实现原理：

MQ算法根据优先级（访问频率）将数据划分为多个LRU队列，其核心思想是：优先缓存访问次数多的数据。

示意图：

[图片上传失败...(image-45908b-1547643827199)]

问题：

多个队列需要额外的空间来存储缓存，维护多个队列增加了算法的复杂度，提升了CPU等消耗。

五、iOS端可供选择的数据持久化方案

1. 内存缓存

实现内存缓存的技术手段包括苹果官方提供的NSURLCache，NSCache，还有性能和API上比较有优势的开源缓存库YYCache、PINCache等。

2. 磁盘缓存

3. 应该用哪种缓存方案

根据需求选择：

六、内存、磁盘数据持久化方案对比

1、可选方案详解

1.1、NSCache

苹果提供的一个简单的内存缓存，它有着和 NSDictionary 类似的 API，不同点是它是线程安全的，并且不会 retain key，内部实现了内存警告处理（仅应用在后台时，会移除一部分缓存）。

1.1.1、特性

1.1.2、实现

1.2、TMCache

TMCache 最初由 Tumblr 开发，但现在已经不再维护了。TMMemoryCache 实现了很多 NSCache 并没有提供的功能，比如数量限制、总容量限制、存活时间限制、内存警告或应用退到后台时清空缓存等。TMMemoryCache 在设计时，主要目标是线程安全，它把所有读写操作都放到了同一个 concurrent queue 中，然后用 dispatch_barrier_async 来保证任务能顺序执行。它错误的用了大量异步 block 回调来实现存取功能，以至于产生了很大的性能和死锁问题。
由于该库很久不再维护，不做详细对比。

1.3、PINCache

Tumblr 宣布不在维护 TMCache 后，由 Pinterest 维护和改进的一个缓存SDK。它的功能和接口基本和 TMCache 一样，但修复了性能和死锁的问题。它同样也用 dispatch_semaphore 来保证线程安全，但去掉了dispatch_barrier_async，避免了线程切换带来的巨大开销，也避免了可能的死锁。

1.3.1、特性：

1.3.2、实现

1.4、YYCache

郭耀源开发的一个内存缓存，相对于 PINMemoryCache 来说，我去掉了异步访问的接口，尽量优化了同步访问的性能，用 OSSpinLock 来保证线程安全。另外，缓存内部用双向链表和 NSDictionary 实现了 LRU 淘汰算法，相对于上面几个算是一点进步吧。

1.4.1、特性：

1.4.2、实现

2、内存缓存方案对比

2.1、性能

YYCache的读写性能均较为优秀。NSCache和PINCache各有优劣。

内存缓存性能测

性能测试说明：

在YYCache Demo基础上进行的性能测试，使用的debug包，并不代表真实使用性能情况。
我的内存缓存性能测试

2.1、对比

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策略，性能高；但未抽象相关协议，内存和磁盘缓存重复度高 作者已不在维护

3、磁盘缓存方案对比

3.1、性能

小数据存取YYCache完胜。20KB以上文件存取YYCache较快。

内存缓存性能测试

性能测试说明：
在YYCache Demo基础上进行的性能测试，使用的debug包，并不代表真实使用性能情况。

image image

3.2、对比

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策略，性能高；实现文件不同存储策略更高效；但未抽象相关协议，内存和磁盘缓存重复度高 作者已不在维护

4、数据库缓存

4.1、背景

原生的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数据存储：

4.2、对比

sqlite数据库的使用包括增、删、改、查等基本操作，同时在项目中运用，还需要数据转模型、数据库通过增删表、字段和数据迁移完成版本升级等操作，下文通过对这些操作在各个流行库中的使用示例来对比各个库的易用性。

4.2.1、FMDB

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];
    }
}];

4.2.2、WCDB

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()];

4.2.3、Realm

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];
    }
});

4.3 数据库存取性能测试

性能测试说明：

测试数据见下方。由于样本比较少（仅1种数据），只进行了部分写入和读取操作，并不能完全反应某个SDK的综合性能，仅作为参考。

测试数据和测试结果见下图：

测试数据

顺序插入1W条数据：

image

使用事务插入1W条数据：

image

读取1W条数据：

image

多线程（2条）插入共2W条数据：

image

4.4、数据库方案对比

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等属性绑定 是

性能数据:

七、持久化在项目中的应用（小结）

1、 图片缓存

以SDWebImage（KingFisher）为代表的图片缓存库基本都实现了二级缓存、队列下载、异步解压、Category拓展等能力，常用的图片加载展示需求都可以使用它们来完成。

2、 简单key-value存取

系统的如NSCache、NSKeyedArchive等缓存功能能满足基本的存取需求，但是并不易用。
PINCache 和 YYCache 等这些三方库拓展了相当多的能力来满足大部分的使用场景，并且内部通过LRU等策略来提升效率，同时内部实现了二级缓存来加快加载速度，可以考率直接使用。
其中PINCache虽然在一些测试数据上性能并不如YYCache，但是可以看到github的PINCache最近依然有更新，而YYCache已经两年没有代码提交了，issue没有处理，遇到问题需要自己处理。
如果考虑维护成本的比例高一些，不妨使用PINCache，反之使用YYCache。

3、 数据库

Core Data （本人未使用过）由于入门门槛高、坑多等原因导致口碑并不太好，这里就不推荐尝试了。
FMDB可以说经过了大量iOS App的验证，它虽然在一些扩展能力上并不尽人意，但是其稳定性久经考验，基于sqlite实现，不改变表结构数据的情况下，便于直接迁移到如WCDB等实现。
WCDB和Realm同样都是支持ORM的，基本不需要写sql语句就能完成增删改查，都跨平台，扩展了如加密、数据升级等很多便捷的封装，用起来都比FMDB更爽。
但两者相较，假如你真的想使用ORM，我更推荐WCDB，因为Realm的搜索引擎暂不支持关联表查询是硬伤，而WCDB是基于sqlite的，支持直接使用sql语句查询，如果业务中遇到类似场景无法解决，还需要从Realm迁移到sqlite花费的力气就大了。
除此之外，微信团队本身就在使用WCDB，他们在数亿用户量的情况下遇到的性能、数据损坏等问题比我们要多得多，他们做的优化也就更多，而这些优化，你使用WCDB就可以体验到。

4、 其它

  1. 封装
    无论你使用哪个三方库进行缓存实现，最好做一层封装，这样便于你在想要切换别的实现时，直接内部做好数据迁移，对于使用方完全无感知迁移，或者仅需要其做极少的工作，而不是全量的替换
  2. 区分用户目录存储
    每个用户都使用单独的文件夹来存储他的数据，对数据库也一样，这样做的好处在于，用户数据不会相互污染（比如数据库中存在复杂的多表关联关系时，会使你的sql语句变得很复杂，提升了你区分用户出错的概率），也便于进行数据诊断。
  3. 单例
    建议对于某个时间段的数据操作都交给一个对象去做，内部来保证多线程读写安全，降低出错的概率。
  4. 用户切换的处理
    由于区分用户存储目录，切换登录用户时，需要我们切换数据存取的实例，此时，不要马上销毁上个实例，上个实例可能还有未完成的读写任务，等待完成或中断其操作后再销毁。

参考

  1. iOS架构师之路：本地持久化方案
  2. IOS（数据持久化1）
  3. iOS应用架构谈 本地持久化方案及动态部署
  4. 常见缓存算法和缓存策略
  5. 缓存淘汰算法--LRU算法
  6. iOS缓存框架－PINCache解读
  7. IOS 缓存管理之 PINCache 使用
  8. YYCache 设计思路
  9. Sqlite学习笔记(四)&&SQLite-WAL原理
  10. 微信iOS SQLite源码优化实践
  11. 微信移动端数据库组件WCDB系列（二） — 数据库修复三板斧
  12. 数据库的设计：深入理解 Realm 的多线程处理机制
  13. Realm 核心数据库引擎探秘
  14. Realm数据库 从入门到“放弃”
  15. 使用Realm的一些总结
  16. Realm、WCDB与SQLite移动数据库性能对比测试
  17. Realm、WCDB与SQLite移动数据库性能测试
  1. wcdb
  2. realm
  3. PINCache
  4. YYCache
上一篇 下一篇

猜你喜欢

热点阅读