一、前言
为了最大限度地保证事件数据的准确性、完整性和及时性，数据采集 SDK 需要及时地将事件数据同步到服务端。但在某些情况下，比如手机处于断网环境，或者根据实际需求只能在 Wi-Fi 环境下才能同步数据等，可能会导致事件数据同步失败或者无法进行同步。因此，数据采集 SDK 需要先把事件数据缓存在本地，待符合一定的策略（条件）之后，再去同步数据[1]。
二、数据存储方式
在 iOS 应用程序中，从 “数据缓存在哪里” 这个维度看，缓存一般分为两种类型：
内存缓存是将数据缓存在内存中，供应用程序直接读取和使用。优点是读写速度极快。缺点是由于内存资源有限，应用程序在系统中申请的内存，会随着应用程序生命周期的结束而被释放。这就意味着，如果应用程序在运行的过程中被用户强杀或者出现崩溃的情况，都有可能导致内存中缓存的数据丢失。因此，将事件数据缓存在内存中不是最佳选择。
磁盘缓存是将数据缓存在磁盘空间中，其特点正好与内存缓存相反。磁盘缓存容量大，但是读写速度相对于内存缓存来说要慢一些。不过磁盘缓存是持久化存储，不受应用程序生命周期的影响。一般情况下，一旦数据成功保存在磁盘中，丢失的风险就非常低。因此，即使磁盘缓存数据读写速度较慢，但综合考虑下，磁盘缓存是缓存事件数据的最优选择。
由于磁盘缓存是一种可以持久化存储的方案，对于存储事件数据是一种最优的选择。在 iOS 中有多种持久化存储的方案，比如 KeyChain、NSUserDefaults、文件存储、数据库存储等都可以做持久化存储。那我们的事件数据使用哪种方案比较好呢？
我们知道 KeyChain、NSUserDefaults 是一种轻量级的存储方案，比如登录用户的用户名、登录状态等，使用 KeyChain 或者 NSUserDefaults 是一种不错的选择。但是对于大量的事件数据而言，这两种存储方案就无能为力了。
文件存储可以满足存储大量数据的需求，因此可以使用文件来存储采集的事件数据。其实，在 SDK 的一些前期版本，我们就是使用文件来存储事件数据的。文件存储相对来说还是比较简单的，主要操作就是写文件和读文件。我们每次都是将所有的数据写入同一个文件，写入的数据量越大，文件缓存性能越好。当然，文件存储还是不够灵活的，我们很难使用更细的粒度去操作数据，比如，很难对其中的某一条数据进行读和写的操作。
有没有其他的方式，可以满足对数据灵活操作的需求呢？答案是肯定的，数据库就满足这个需求。在 iOS 应用程序中，使用的数据库一般是 SQLite 数据库。SQLite 是一个轻量级的数据库，数据存储简单高效，使用也非常简单。相对于文件存储来说，数据库存储更加灵活，可以实现对单条数据的插入、查询和删除操作，同时调试也更容易[1]。
三、事件数据存储
3.1 存储策略
实现 SDK 中的数据库时，为了保证数据的完整性和准确性，采用了较为完善的存储策略：
开发者在初始化 SDK 时，可以根据需要通过 - setMaxCacheSize: 方法设置本地缓存事件的最大条数。本地缓存事件的默认值是 10000 条。当开发者设置的最大缓存事件条数小于 10000 时，则使用默认值；
执行数据采集任务时，采集的数据首先缓存到本地数据库。数据写入时，会判断数据库里缓存的事件条数是否超过设定的最大值；如果超过设定的最大缓存事件条数，则删除最先入库的 100 条数据，然后执行入库操作；
SDK 会定时检查是否满足上报策略，满足上报策略时，会把数据库里的数据打包上报到服务端，上报成功后会删除已上报的数据，上报失败则不删除。
3.2 数据库表的设计
SDK 采集的事件数据中，会有很多字段，比如事件名称、预置公共属性和用户自定义属性等。虽然事件数据中包含的属性比较多，但是存储数据无需关心具体的细节，可以将一个事件数据当做整体存储到数据表的一个字段中，从而提高数据的操作效率。
具体的结构如表 3-1 所示：
表 3-1 事件数据的存储结构
3.3 具体实现
SDK 采集数据过程中，会频繁的执行缓存数据、上报数据和删除数据等耗时操作。为了保证 SDK 的数据采集不影响用户的 App 性能，这些耗时的操作全部在子线程中完成。SDK 在执行数据存储和数据上报会涉及到 SAEventStore 、SAEventFlush、SAHTTPSession、SAEventTracker 等几个关键类：
3.3.1. 初始化工具类
在初始化 SDK 时，会对 SAEventTracker 工具类进行初始化：
_eventTracker = [[SAEventTracker alloc] initWithQueue:_serialQueue];
复制代码
在 SAEventTracker 的初始化方法里对 SAEventStore 和 SAEventFlush 两个工具类进行初始化：
- (instancetype)initWithQueue:(dispatch_queue_t)queue { self = [super init]; if (self) { _queue = queue; dispatch_async(self.queue, ^{ self.eventStore = [[SAEventStore alloc] initWithFilePath:[SAFileStore filePath:@"message-v2"]]; self.eventFlush = [[SAEventFlush alloc] init]; }); } return self;}
复制代码
初始化 SAEventStore 时，传入的 filePath 参数是用于创建数据库的路径。SAEventStore 的初始化如下：
- (instancetype)initWithFilePath:(NSString *)filePath { self = [super init]; if (self) { NSString *label = [NSString stringWithFormat:@"cn.sensorsdata.SAEventStore.%p", self]; _serialQueue = dispatch_queue_create(label.UTF8String, DISPATCH_QUEUE_SERIAL); // 直接初始化，防止数据库文件，意外删除等问题 _recordCaches = [NSMutableArray array]; [self setupDatabase:filePath]; } return self;}
复制代码
在方法 - setupDatabase: 里对封装了数据库的工具类 SADatabase 初始化，在 SADatabase 创建了数据库文件和表：
- (instancetype)initWithFilePath:(NSString *)filePath { self = [super init]; if (self) { _filePath = filePath; _serialQueue = dispatch_queue_create("cn.sensorsdata.SADatabaseSerialQueue", DISPATCH_QUEUE_SERIAL); [self createStmtCache]; [self open]; [self createTable]; } return self;}
复制代码
3.3.2. 数据入库
对于校验成功的数据，会尝试把数据存入到数据库，如果数据库打开失败，会把数据先保存在内存中的一个数组中：
- (BOOL)insertRecord:(SAEventRecord *)record { BOOL success = [self.database insertRecord:record]; if (!success) { [self.recordCaches addObject:record]; } return success;}
复制代码
在监听到数据库创建成功时，会尝试把缓存在内存中的数据插入数据库，如果插入失败，会重试 3 次：
#pragma mark - observe - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { if (context != SAEventStoreContext) { return [super observeValueForKeyPath:keyPath ofObject:object change:change context:context]; } if (![keyPath isEqualToString:SAEventStoreObserverKeyPath]) { return; } if (![change[NSKeyValueChangeNewKey] boolValue] || self.recordCaches.count == 0) { return; } // 对于内存中的数据，重试 3 次插入数据库中。 for (NSInteger i = 0; i < 3; i++) { if ([self.database insertRecords:self.recordCaches]) { [self.recordCaches removeAllObjects]; return; } }}
复制代码
插入事件数据是比较频繁的操作，如果每次都做 “预解析 SQL 语句” 的操作，将会造成资源的大量浪费。对于插入数据来说，每次操作的 SQL 语句都是相同的，因此 “预解析 SQL 语句” 只需执行一次即可。由于每次需要绑定不同的数据，我们只需要重置一下之前的 sqlite3_stmt，然后重新绑定新的数据即可[1]。插入数据的逻辑如下：
- (BOOL)insertRecord:(SAEventRecord *)record { if (![record isValid]) { SALogError(@"%@ input parameter is invalid for addObjectToDatabase", self); return NO; } if (![self databaseCheck]) { return NO; } if (![self preCheckForInsertRecords:1]) { return NO; } NSString *query = @"INSERT INTO dataCache(type, content) values(?, ?)"; sqlite3_stmt *insertStatement = [self dbCacheStmt:query]; int rc; if (insertStatement) { sqlite3_bind_text(insertStatement, 1, [record.type UTF8String], -1, SQLITE_TRANSIENT); sqlite3_bind_text(insertStatement, 2, [record.content UTF8String], -1, SQLITE_TRANSIENT); rc = sqlite3_step(insertStatement); if (rc != SQLITE_DONE) { SALogError(@"insert into dataCache table of sqlite fail, rc is %d", rc); return NO; } self.count++; SALogDebug(@"insert into dataCache table of sqlite success, current count is %lu", self.count); return YES; } else { SALogError(@"insert into dataCache table of sqlite error"); return NO; }}
复制代码
3.3.3. 数据删除
在达到上报条件时，会触发数据上报。默认情况下是每 15 秒上报一次，或者缓存的数据达到 100 条时进行一次上报。在非 Debug 模式下，每次上报 50 条数据：
- (void)flushAllEventRecords { if (![self canFlush]) { return; } BOOL isFlushed = [self flushRecordsWithSize:self.isDebugMode ? 1 : 50]; if (isFlushed) { SALogInfo(@"Events flushed!"); }}
复制代码
对于已经上报成功的数据，SDK 会将其从数据库中移除，防止数据的重复上报：
......// flush__weak typeof(self) weakSelf = self;[self.eventFlush flushEventRecords:encryptRecords completion:^(BOOL success) {__strong typeof(weakSelf) strongSelf = weakSelf;void(^block)(void) = ^ {if (!success) {[strongSelf.eventStore updateRecords:recordIDs status:SAEventRecordStatusNone];return;}// 5. 删除数据if ([strongSelf.eventStore deleteRecords:recordIDs]) {[strongSelf flushRecordsWithSize:size];}};if (sensorsdata_is_same_queue(strongSelf.queue)) {block();} else {dispatch_sync(strongSelf.queue, block);}}];......
复制代码
3.4 数据流程
当 SDK 调用 track 相关方法时，首先是 SDK 会对事件数据的各项属性进行合法性校验，校验通过后将事件数据存储到数据库。在 SDK 初始化时启动的定时器会定时检查是否满足上报条件，当符合上报时，再将数据上报到服务端，最后再把上报成功的数据从数据库中删除。工作流程如图 3-1 所示：
图 3-1 数据采集流程
四、总结
本文介绍了神策 iOS SDK[2] 中使用到的存储方式和具体使用流程。希望通过这篇文章的介绍，大家能够对神策 iOS SDK 存储模块有一个较为全面的了解。
参考文献：
[1]王灼洲.iOS 全埋点解决方案[M].北京:机械工业出版社,2020:162-197.
[2]https://github.com/sensorsdata/sa-sdk-ios
更多信息，可关注公众号：神策技术社区
评论