前置说明
因为这篇文章和 APM 是属于姊妹篇，所以看这篇文章的时候有些东西不知道活着好奇的时候可以看「带你打造一套 APM 监控系统」。
另外看到我在下面的代码段，有些命名风格、简写、分类、方法的命名等，我简单做个说明。
- 数据上报 SDK 叫 PrismClient，我们规定类的命名一般用 SDK 的名字缩写，当前情况下缩写为 PCT
- 给 Category 命名，规则为 类名 + SDK 前缀缩写的小写格式 + 下划线 + 驼峰命名格式的功能描述。比如给 NSDate 增加一个获取毫秒时间戳的分类，那么类名为 NSDate+pct_TimeStamp
- 给 Category 的方法命名，规则为 SDK 前缀缩写的小写格式 + 下划线 + 驼峰命名格式的功能描述。比如给 NSDate 增加一个根据当前时间获取毫秒时间戳的方法，那么方法名为 + (long long)pct_currentTimestamp;
一、 首先定义需要做什么
我们要做的是「一个通用可配置、多句柄的数据上报 SDK」，也就是说这个 SDK 具有这么几个功能：
- 具有从服务端拉取配置信息的能力，这些配置用来控制 SDK 的上报行为（需不需要默认行为？）
- SDK 具有多句柄特性，也就是拥有多个对象，每个对象具有自己的控制行为，彼此之间的运行、操作互相隔离
- APM 监控作为非常特殊的能力存在，它也使用数据上报 SDK。它的能力是 App 质量监控的保障，所以针对 APM 的数据上报通道是需要特殊处理的。
- 数据先根据配置决定要不要存，存下来之后再根据配置决定如何上报
明白我们需要做什么，接下来的步骤就是分析设计怎么做。
二、 拉取配置信息
1. 需要哪些配置信息
首先明确几个原则：
- 因为监控数据上报作为数据上报的一个特殊 case，那么监控的配置信息也应该特殊处理。
- 监控能力包含很多，比如卡顿、网络、奔溃、内存、电量、启动时间、CPU 使用率。每个监控能力都需要一份配置信息，比如监控类型、是否仅 WI-FI 环境下上报、是否实时上报、是否需要携带 Payload 数据。（注：Payload 其实就是经过 gZip 压缩、AES-CBC 加密后的数据）
- 多句柄，所以需要一个字段标识每份配置信息，也就是一个 namespace 的概念
- 每个 namespace 下都有自己的配置，比如数据上传后的服务器地址、上报开关、App 升级后是否需要清除掉之前版本保存的数据、单次上传数据包的最大体积限制、数据记录的最大条数、在非 WI-FI 环境下每天上报的最大流量、数据过期天数、上报开关等
- 针对 APM 的数据配置，还需要一个是否需要采集的开关。
所以数据字段基本如下
因为数据需要持久化保存，所以需要实现 NSCoding 协议。
一个小窍门，每个属性写 encode、decode 会很麻烦，可以借助于宏来实现快速编写。
抛出一个问题：既然监控很重要，那别要配置了，直接全部上传。
我们想一想这个问题，监控数据都是不直接上传的，监控 SDK 的责任就是收集监控数据，而且监控后的数据非常多，App 运行期间的网络请求可能都有 n 次，App 启动时间、卡顿、奔溃、内存等可能不多，但是这些数据直接上传后期拓展性非常差，比如根据 APM 监控大盘分析出某个监控能力暂时先关闭掉。这时候就无力回天了，必须等下次 SDK 发布新版本。监控数据必须先存储，假如 crash 了，则必须保存了数据等下次启动再去组装数据、上传。而且数据在消费、新数据在不断生产，假如上传失败了还需要对失败数据的处理，所以这些逻辑还是挺多的，对于监控 SDK 来做这个事情，不是很合适。答案就显而易见了，必须要配置（监控开关的配置、数据上报的行为配置）。
2. 默认配置
因为监控真的很特殊，App 一启动就需要去收集 App 的性能、质量相关数据，所以需要一份默认的配置信息。
上面的例子是一份默认配置信息
3. 拉取策略
网络拉取使用了基础 SDK （非网络 SDK）的能力 mGet，根据 key 注册网络服务。这些 key 一般是 SDK 内部的定义好的，比如统跳路由表等。
这类 key 的共性是 App 在打包阶段会内置一份默认配置，App 启动后会去拉取最新数据，然后完成数据的缓存，缓存会在 NSDocumentDirectory 目录下按照 SDK 名称、 App 版本号、打包平台上分配的打包任务 id、 key 建立缓存文件夹。
此外它的特点是等 App 启动完成后才去请求网络，获取数据，不会影响 App 的启动。
流程图如下
下面是一个截取代码，对比上面图看看。
三、数据存储
1. 数据存储技术选型
记得在做数据上报技术的评审会议上，Android 同事说用 WCDB，特色是 ORM、多线程安全、高性能。然后就被质疑了。因为上个版本使用的技术是基于系统自带的 sqlite2，单纯为了 ORM、多线程问题就额外引入一个三方库，是不太能说服人的。有这样几个疑问
- ORM 并不是核心诉求，利用 Runtime 可以在基础上进行修改，也可支持 ORM 功能
- 线程安全。WCDB 在线程安全的实现主要是基于 Handle，HandlePool 和 Database 三个类完成的。Handle 是 sqlite3 指针，HandlePool 用来处理连接。
所以 WCDB 连接池通过读写锁保证线程安全。所以之前版本的地方要实现线程安全修改下缺陷就可以。增加了 sqlite3，虽然看起来就是几兆大小，但是这对于公共团队是致命的。业务线开发者每次接入 SDK 会注意App 包体积的变化，为了数据上报增加好几兆，这是不可以接受的。
- 高性能的背后是 WCDB 自带的 sqlite3 开启了 WAL模式 (Write-Ahead Logging)。当 WAL 文件超过 1000 个页大小时，SQLite3 会将 WAL 文件写会数据库文件。也就是 checkpointing。当大批量的数据写入场景时，如果不停提交文件到数据库事务，效率肯定低下，WCDB 的策略就是在触发 checkpoint 时，通过延时队列去处理，避免不停的触发 WalCheckpoint 调用。通过 TimedQueue 将同个数据库的 WalCheckpoint 合并延迟到2秒后执行
一般来说公共组做事情，SDK 命名、接口名称、接口个数、参数个数、参数名称、参数数据类型是严格一致的，差异是语言而已。实在万不得已，能力不能堆砌的情况下是可以不一致的，但是需要在技术评审会议上说明原因，需要在发布文档、接入文档都有所体现。
所以最后的结论是在之前的版本基础上进行修改，之前的版本是 FMDB。
2. 数据库维护队列
1. FMDB 队列
FMDB 使用主要是通过 FMDatabaseQueue的 - (void)inTransaction:(__attribute__((noescape)) void (^)(FMDatabase *db, BOOL *rollback))block 和 - (void)inDatabase:(__attribute__((noescape)) void (^)(FMDatabase *db))block。这2个方法的实现如下
上面的 _queue 其实是一个串行队列，通过 _queue = dispatch_queue_create([[NSString stringWithFormat:@"fmdb.%@", self] UTF8String], NULL); 创建。所以，FMDB 的核心就是以同步的形式向串行队列提交任务，来保证多线程操作下的读写问题（比每个操作加锁效率高很多）。只有一个任务执行完毕，才可以执行下一个任务。
上一个版本的数据上报 SDK 功能比较简单，就是上报 APM 监控后的数据，所以数据量不会很大，之前的人封装超级简单，仅以事务的形式封装了一层 FMDB 的增删改查操作。那么就会有一个问题。假如 SDK 被业务线接入，业务线开发者不知道数据上报 SDK 的内部实现，直接调用接口去写入大量数据，结果 App 发生了卡顿，那不得反馈你这个 SDK 超级难用啊。
2. 针对 FMDB 的改进
改法也比较简单，我们先弄清楚 FMDB 这样设计的原因。数据库操作的环境可能是主线程、子线程等不同环境去修改数据，主线程、子线程去读取数据，所以创建了一个串行队列去执行真正的数据增删改查。
目的就是让不同线程去使用 FMDB 的时候不会阻塞当前线程。既然 FMDB 内部维护了一个串行队列去处理多线程情况下的数据操作，那么改法也比较简单，那就是创建一个并发队列，然后以异步的方式提交任务到 FMDB 中去，FMDB 内部的串行队列去执行真正的任务。
小实验模拟下流程
3. 数据表设计
通用的数据上报 SDK 的功能是数据的保存和上报。从数据的角度来划分，数据可以分为 APM 监控数据和业务线的业务数据。
数据各有什么特点呢？APM 监控数据一般可以划分为：基本信息、异常信息、线程信息，也就是最大程度的还原案发线程的数据。业务线数据基本上不会有所谓的大量数据，最多就是数据条数非常多。鉴于此现状，可以将数据表设计为 meta 表、payload 表。meta 表用来存放 APM 的基础数据和业务线的数据，payload 表用来存放 APM 的线程堆栈数据。
数据表的设计是基于业务情况的。那有这样几个背景
- APM 监控数据需要报警（具体可以查看 APM 文章，地址在开头 ），所以数据上报 SDK 上报后的数据需要实时解析
- 产品侧比如监控大盘可以慢，所以符号化系统是异步的
- 监控数据实在太大了，如果同步解析会因为压力较大造成性能瓶颈
所以把监控数据拆分为2块，即 meta 表、payload 表。meta 表相当于记录索引信息，服务端只需要关心这个。而 payload 数据在服务端是不会处理的，会有一个异步服务单独处理。
meta 表、payload 表结构如下：
四、数据上报机制
1. 数据上报流程和机制设计
数据上报机制需要结合数据特点进行设计，数据分为 APM 监控数据和业务线上传数据。先分析下2部分数据的特点。
- 业务线数据可能会要求实时上报，需要有根据上报配置数据控制的能力
- 整个数据聚合上报过程需要有根据上报配置数据控制的能力定时器周期的能力，隔一段时间去触发上报
- 整个数据（业务数据、APM 监控数据）的上报与否需要有通过配置数据控制的能力
- 因为 App 在某个版本下收集的数据可能会对下个版本的时候无效，所以上报 SDK 启动后需要有删除之前版本数据的能力（上报配置数据中删除开关打开的情况下）
- 同样，需要删除过期数据的能力（删除距今多少个自然天前的数据，同样走下发而来的上报配置项）
- 因为 APM 监控数据非常大，且数据上报 SDK 肯定数据比较大，所以一个网络通信方式的设计好坏会影响 SDK 的质量，为了网络性能不采用传统的 key/value 传输。采用自定义报文结构
- 数据的上报流程触发方式有3种：App 启动后触发（APM 监控到 crash 的时候写入本地，启动后处理上次 crash 的数据，是一个特殊 case ）；定时器触发；数据调用数据上报 SDK 接口后命中实时上报逻辑
- 数据落库后会触发一次完整的上报流程
- 上报流程的第一步会先判断该数据的 type 能否名字上报配置的 type，命中后如果实时上报配置项为 true，则马上执行后续真正的数据聚合过程；否则中断（只落库，不触发上报）
- 由于频率会比较高，所以需要做节流的逻辑
很多人会搞不清楚防抖和节流的区别。一言以蔽之：“函数防抖关注一定时间连续触发的事件只在最后执行一次，而函数节流侧重于一段时间内只执行一次”。此处不是本文重点，感兴趣的的可以查看这篇文章
- 上报流程会首先判断（为了节约用户流量）
- 判断当前网络环境为 WI-FI 则实时上报
- 判断当前网络环境不可用，则实时中断后续
- 判断当前网络环境为蜂窝网络， 则做是否超过1个自然天内使用流量是否超标的判断
- T(当前时间戳) - T(上次保存时间戳) > 24h，则清零已使用的流量，记录当前时间戳到上次上报时间的变量中
- T(当前时间戳) - T(上次保存时间戳) <= 24h，则判断一个自然天内已使用流量大小是否超过下发的数据上报配置中的流量上限字段，超过则 exit；否则执行后续流程
- 数据聚合分表进行，且会有一定的规则
- 优先获取 crash 数据
- 单次网络上报中，整体数据条数不能数据上报配置中的条数限制；数据大小不能超过数据配置中的数据大小
- 数据取出后将这批数据标记为 dirty 状态
- meta 表数据需要先 `gZip` 压缩，再使用 `AES 128` 加密
- payload 表数据需组装自定义格式的报文。格式如下
Header 部分：
- 发起数据上报网络请求
- 成功回调：删除标记为`dirty` 的数据。判断为流量环境，则将该批数据大小叠加到1个自然天内已使用流量大小的变量中。
- 失败回调：更新标记为`dirty` 的数据为正常状态。判断为流量环境，则将该批数据大小叠加到1个自然天内已使用流量大小的变量中。
整个上报流程图如下：
2. 踩过的坑 && 做得好的地方
之前做针对网络接口基本上都是使用现有协议的 `key/value` 协议上开发的，它的优点是使用简单，缺点是协议体太大。在设计方案的时候分析道数据上报 SDK 网络上报肯定是非常高频的所以我们需要设计自定义的报文协议，这部分的设计上可以参考 TCP 报文头结构。
当时和后端对接接口的时候发现数据上报过去，服务端解析不了。断点调试发现数据聚合后的大小、条数、压缩、加密都是正常的，在本地 Mock 后完全可以反向解析出来。但为什么到服务端就解析不了，联调后发现是 字节端序（Big-Endian）的问题。简单介绍如下，关于大小端序的详细介绍请查看我的 这篇文章
主机字节顺序 HBO（Host Byte Order）：与 CPU 类型有关。Big-Endian: PowerPC、IBM、Sun。Little-Endian:x86、DEC
网络字节顺序 NBO（Network Byte Order）：网络默认为大端序。
上面的逻辑有一步是当网络上报成功后需要删除标记为 dirty 的数据。但是测试了一下发现，大量数据删除后数据库文件的大小不变，理论上需要腾出内存数据大小的空间。
sqlite 采用的是变长记录存储，当数据被删除后，未使用的磁盘空间被添加到一个内在的“空闲列表”中，用于下次插入数据，这属于优化机制之一，sqlite 提供 `vacuum` 命令来释放。
这个问题类似于 Linux 中的文件引用计数的意思，虽然不一样，但是提出来做一下参考。实验是这样的
1. 先看一下当前各个挂载目录的空间大小：`df -h`
2. 首先我们产生一个50M大小的文件
3. 写一段代码读取文件
```c++
#include<stdio.h>
#include<unistd.h>
int main(void)
{ FILE *fp = NULL;
fp = fopen("/boot/test.txt", "rw+");
if(NULL == fp){
perror("open file failed");
return -1;
}
while(1){
//do nothing sleep(1);
}
fclose(fp);
return 0;
}
```
4. 命令行模式下使用 `rm` 删除文件
5. 查看文件大小： `df -h`，发现文件被删除了，但是该目录下的可用空间并未变多
解释：实际上，只有当一个文件的引用计数为0（包括硬链接数）的时候，才可能调用 unlink 删除，只要它不是0，那么就不会被删除。所谓的删除，也不过是文件名到 inode 的链接删除，只要不被重新写入新的数据，磁盘上的 block 数据块不会被删除，因此，你会看到，即便删库跑路了，某些数据还是可以恢复的。换句话说，当一个程序打开一个文件的时候（获取到文件描述符），它的引用计数会被+1，rm虽然看似删除了文件，实际上只是会将引用计数减1，但由于引用计数不为0，因此文件不会被删除。
在数据聚合的时候优先获取 crash 数据，总数据条数需要小于上报配置数据的条数限制、总数据大小需要小于上报配置数据的大小限制。这里的处理使用了递归，改变了函数参数
整个 SDK 的 Unit Test 通过率 100%，代码分支覆盖率为 93%。测试基于 TDD 和 BDD。测试框架：系统自带的 `XCTest`，第三方的 `OCMock`、`Kiwi`、`Expecta`、`Specta`。测试使用了基础类，后续每个文件都设计继承自测试基类的类。
Xcode 可以看到整个 SDK 的测试覆盖率和单个文件的测试覆盖率
也可以使用 slather。在项目终端环境下新建 .slather.yml 配置文件，然后执行语句 slather coverage -s --scheme prism-client-Example --workspace prism-client.xcworkspace prism-client.xcodeproj 。
关于质量保证的最基础、可靠的方案之一软件测试，在各个端都有一些需要注意的地方，还需要结合工程化，我会写专门的文章谈谈经验心得。
五、 接口设计及核心实现
1. 接口设计
2. 核心实现
真正处理逻辑的是 `PCTService` 类。
六、 总结与思考
1. 技术方面
多线程技术很强大，但是很容易出问题。普通做业务的时候用一些简单的 GCD、NSOperation 等就可以满足基本需求了，但是做 SDK 就不一样，你需要考虑各种场景。比如 FMDB 在多线程读写的时候，设计了 FMDatabaseQueue 以串行队列的方式同步执行任务。但是这样一来假如使用者在主线程插入 n 次数据到数据库，这样会发生 ANR，所以我们还得维护一个任务派发队列，用来维护业务方提交的任务，是一个并发队列，以异步任务的方式提交给 FMDB 以同步任务的方式在串行队列上执行。
AFNetworking 2.0 使用了 NSURLConnection，同时维护了一个常驻线程，去处理网络成功后的回调。AF 存在一个常驻线程，假如其他 n 个 SDK 的其中 m 个 SDK 也开启了常驻线程，那你的 App 集成后就有 1+m 个常驻线程。
AFNetworking 3.0 使用 NSURLSession 替换 NSURLConnection，取消了常驻线程。为什么换了？ 😂 逼不得已呀，Apple 官方出了 NSURLSession，那就不需要 NSURLConnection，并为之创建常驻线程了。至于为什么 NSURLSession 不需要常驻线程？它比 NSURLConnecction 多做了什么，以后再聊
创建线程的过程，需要用到物理内存，CPU 也会消耗时间。新建一个线程，系统会在该进程空间分配一定的内存作为线程堆栈。堆栈大小是 4KB 的倍数。在 iOS 主线程堆栈大小是 1MB，新创建的子线程堆栈大小是 512KB。此外线程创建得多了，CPU 在切换线程上下文时，还会更新寄存器，更新寄存器的时候需要寻址，而寻址的过程有 CPU 消耗。线程过多时内存、CPU 都会有大量的消耗，出现 ANR 甚至被强杀。
举了 🌰 是 FMDB 和 AFNetworking 的作者那么厉害，设计的 FMDB 不包装会 ANR，AFNetworking 必须使用常驻线程，为什么？正是由于多线程太强大、灵活了，开发者骚操作太多，所以 FMDB 设计最简单保证数据库操作线程安全，具体使用可以自己维护队列去包一层。AFNetworking 内的多线程也严格基于系统特点来设计。
所以有必要再研究下多线程，建议读 GCD 源码，也就是 libdispatch
2. 规范方面
很多开发都不做测试，我们公司都严格约定测试。写基础 SDK 更是如此，一个 App 基础功能必须质量稳定，所以测试是保证手段之一。一定要写好 Unit Test。这样子不断版本迭代，对于 UT，输入恒定，输出恒定，这样内部实现如何变动不需要关心，只需要判断恒定输入，恒定输出就足够了。（针对每个函数单一原则的基础上也是满足 UT）。还有一个好处就是当和别人讨论的的时候，你画个技术流程图、技术架构图、测试的 case、测试输入、输出表述清楚，听的人再看看边界情况是否都考虑全，基本上很快沟通完毕，效率考高。
在做 SDK 的接口设计的时候，方法名、参数个数、参数类型、参数名称、返回值名称、类型、数据结构，尽量要做到 iOS 和 Android 端一致，除非某些特殊情况，无法保证一致的输出。别问为什么？好处太多了，成熟 SDK 都这么做。
比如一个数据上报 SDK。需要考虑数据来源是什么，我设计的接口需要暴露什么信息，数据如何高效存储、数据如何校验、数据如何高效及时上报。 假如我做的数据上报 SDK 可以上报 APM 监控数据、同时也开放能力给业务线使用，业务线自己将感兴趣的数据并写入保存，保证不丢失的情况下如何高效上报。因为数据实时上报，所以需要考虑上传的网络环境、Wi-Fi 环境和 4G 环境下的逻辑不一样的、数据聚合组装成自定义报文并上报、一个自然天内数据上传需要做流量限制等等、App 版本升级一些数据可能会失去意义、当然存储的数据也存在时效性。种种这些东西就是在开发前需要考虑清楚的。所以基础平台做事情基本是 设计思考时间：编码时间 = 7:3。
为什么？假设你一个需求，预期10天时间；前期架构设计、类的设计、Uint Test 设计估计7天，到时候编码开发2天完成。 这么做的好处很多，比如：
1. 除非是非常优秀，不然脑子想的再前面到真正开发的时候发现有出入，coding 完发现和前期方案设计不一样。所以建议用流程图、UML图、技术架构图、UT 也一样，设计个表格，这样等到时候编码也就是 coding 的工作了，将图翻译成代码
2. 后期和别人讨论或者沟通或者 CTO 进行 code review 的时候不需要一行行看代码。你将相关的架构图、流程图、UML 图给他看看。他再看看一些关键逻辑的 UT，保证输入输出正确，一般来说这样就够了
3. 质量保证
UT 是质量保证的一个方面，另一个就是 MR 机制。我们团队 MR 采用 `+1` 机制。每个 merge request 必须有团队内至少3个人 +1，且其中一人必须为同技术栈且比你资深一些的同事 +1，一人为和你参加同一个项目的同事。
当有人评论或者有疑问时，你必须解答清楚，别人提出的修改点要么修改好，要么解释清楚，才可以 +1。当 +1 数大于3，则合并分支代码。
连带责任制。当你的线上代码存在 bug 时，为你该次 MR +1 的同事具有连带责任。
参考资料
