1. 前言

为了最大限度地保证事件数据的准确性、完整性和及时性，数据采集 SDK 需要及时地将事件数据同步到服务端。但在某些情况下，比如手机处于断网环境，或者根据实际需求只能在 Wi-Fi 环境下才能同步数据等，可能会导致事件数据同步失败或者无法进行同步。因此，数据采集 SDK 需要先把事件数据缓存在本地，待符合一定的策略（条件）之后，再去同步数据[1]。

2. 数据存储方式

在 iOS 应用程序中，从 “数据缓存在哪里” 这个维度看，缓存一般分为两种类型：

  • 内存缓存
  • 磁盘缓存

内存缓存是将数据缓存在内存中，供应用程序直接读取和使用。优点是读写速度极快。缺点是由于内存资源有限，应用程序在系统中申请的内存，会随着应用程序生命周期的结束而被释放。这就意味着，如果应用程序在运行的过程中被用户强杀或者出现崩溃的情况，都有可能导致内存中缓存的数据丢失。因此，将事件数据缓存在内存中不是最佳选择。

磁盘缓存是将数据缓存在磁盘空间中，其特点正好与内存缓存相反。磁盘缓存容量大，但是读写速度相对于内存缓存来说要慢一些。不过磁盘缓存是持久化存储，不受应用程序生命周期的影响。一般情况下，一旦数据成功保存在磁盘中，丢失的风险就非常低。因此，即使磁盘缓存数据读写速度较慢，但综合考虑下，磁盘缓存是缓存事件数据的最优选择。

由于磁盘缓存是一种可以持久化存储的方案，对于存储事件数据是一种最优的选择。在 iOS 中有多种持久化存储的方案，比如 KeyChain、NSUserDefaults、文件存储、数据库存储等都可以做持久化存储。那我们的事件数据使用哪种方案比较好呢？

我们知道 KeyChain、NSUserDefaults 是一种轻量级的存储方案，比如登录用户的用户名、登录状态等，使用 KeyChain 或者 NSUserDefaults 是一种不错的选择。但是对于大量的事件数据而言，这两种存储方案就无能为力了。

文件存储可以满足存储大量数据的需求，因此可以使用文件来存储采集的事件数据。其实，在 SDK 的一些前期版本，我们就是使用文件来存储事件数据的。文件存储相对来说还是比较简单的，主要操作就是写文件和读文件。我们每次都是将所有的数据写入同一个文件，写入的数据量越大，文件缓存性能越好。当然，文件存储还是不够灵活的，我们很难使用更细的粒度去操作数据，比如，很难对其中的某一条数据进行读和写的操作。

有没有其他的方式，可以满足对数据灵活操作的需求呢？答案是肯定的，数据库就满足这个需求。在 iOS 应用程序中，使用的数据库一般是 SQLite 数据库。SQLite 是一个轻量级的数据库，数据存储简单高效，使用也非常简单。相对于文件存储来说，数据库存储更加灵活，可以实现对单条数据的插入、查询和删除操作，同时调试也更容易[1]。

3. 事件数据存储

3.1. 存储策略

实现 SDK 中的数据库时，为了保证数据的完整性和准确性，采用了较为完善的存储策略：

  1. 开发者在初始化 SDK 时，可以根据需要通过 – setMaxCacheSize: 方法设置本地缓存事件的最大条数。本地缓存事件的默认值是 10000 条。当开发者设置的最大缓存事件条数小于 10000 时，则使用默认值；
  2. 执行数据采集任务时，采集的数据首先缓存到本地数据库。数据写入时，会判断数据库里缓存的事件条数是否超过设定的最大值；如果超过设定的最大缓存事件条数，则删除最先入库的 100 条数据，然后执行入库操作；
  3. SDK 会定时检查是否满足上报策略，满足上报策略时，会把数据库里的数据打包上报到服务端，上报成功后会删除已上报的数据，上报失败则不删除。

3.2. 数据库表的设计

SDK 采集的事件数据中，会有很多字段，比如事件名称、预置公共属性和用户自定义属性等。虽然事件数据中包含的属性比较多，但是存储数据无需关心具体的细节，可以将一个事件数据当做整体存储到数据表的一个字段中，从而提高数据的操作效率。

具体的结构如表 3-1 所示：

字段名称
类型
作用
id integer 主键，自增长
type text 数据上报的请求方式，采用的是 POST 方式
content text 事件数据对象的 JSON 字符串
status integer 事件数据的状态，标记这条数据是否已上报

表 3-1 事件数据的存储结构

3.3. 具体实现

SDK 采集数据过程中，会频繁的执行缓存数据、上报数据和删除数据等耗时操作。为了保证 SDK 的数据采集不影响用户的 App 性能，这些耗时的操作全部在子线程中完成。SDK 在执行数据存储和数据上报会涉及到 SAEventStore 、SAEventFlush、SAHTTPSession、SAEventTracker 等几个关键类：

  • SAEventStore:  负责事件数据的存储操作；
  • SAEventFlush: 负责数据的上报；
  • SAHTTPSession: 负责将上报数据的任务添加到队列，等待执行；
  • SAEventTracker: 负责 track 事件和检查是否达到上报条件。

3.3.1. 初始化工具类

  1. 在初始化 SDK 时，会对 SAEventTracker 工具类进行初始化：

    _eventTracker = [[SAEventTracker alloc] initWithQueue:_serialQueue];

  2. 在 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;
    }

  3. 初始化 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;
    }

  4. 在方法 – 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. 数据入库

  1. 对于校验成功的数据，会尝试把数据存入到数据库，如果数据库打开失败，会把数据先保存在内存中的一个数组中：

    - (BOOL)insertRecord:(SAEventRecord *)record {
        BOOL success = [self.database insertRecord:record];
        if (!success) {
            [self.recordCaches addObject:record];
        }
        return success;
    }

  2. 在监听到数据库创建成功时，会尝试把缓存在内存中的数据插入数据库，如果插入失败，会重试 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;
            }
        }
    }

  3. 插入事件数据是比较频繁的操作，如果每次都做 “预解析 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. 数据删除

  1. 在达到上报条件时，会触发数据上报。默认情况下是每 15 秒上报一次，或者缓存的数据达到 100 条时进行一次上报。在非 Debug 模式下，每次上报 50 条数据：

    - (void)flushAllEventRecords {
        if (![self canFlush]) {
            return;
        }
        BOOL isFlushed = [self flushRecordsWithSize:self.isDebugMode ? 1 : 50];
        if (isFlushed) {
            SALogInfo(@"Events flushed!");
        }
    }

  2. 对于已经上报成功的数据，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 数据采集流程图

4. 总结

本文介绍了神策 iOS SDK[2] 中使用到的存储方式和具体使用流程。希望通过这篇文章的介绍，大家能够对神策 iOS SDK 存储模块有一个较为全面的了解。

5. 参考文献

[1]王灼洲.iOS全埋点解决方案[M].北京:机械工业出版社,2020:162-197.

[2]https://github.com/sensorsdata/sa-sdk-ios

6. 本文作者

神策数据 | iOS SDK 技术支持工程师

我是孙强强，神策数据 iOS SDK 技术支持工程师。希望与大家多多交流，通过我们让您更了解神策。