3. SDK数据流基本原理：采集、缓存、上传机制
做SDK集成，数据丢失很多时候不是玄学，而是你对数据流了解得不透彻。说白了，数据就像水，管道接好了不会漏，但每个接口都可能成为漏水点。
我个人习惯，在排查数据丢失之前，先把SDK的数据流向理清楚。你想想看，数据从产生到到达服务器，总共有几个环节？每个环节发生了什么？搞清楚这些，问题就解决了一半。
3.1 数据采集：一切从这里开始
数据采集是管道的入口。这个环节出了问题，后面再怎么折腾也找不回来。所以，我习惯把数据采集称为“失防的第一道防线”。
采集方式一般分两种。
- 自动采集：SDK内部自动监听系统事件，如Activity生命周期、网络状态变化、屏幕旋转等。开发者通常不需要手动干预。
- 手动上报：SDK提供API给业务方，业务在关键节点调用。比如支付成功、登录、注册等。
经验之谈：我在项目中遇到过，业务方以为SDK会自动采集所有事件，结果漏掉了手动上报的支付回调。最后发现数据对不上，排查了两周。记住，自动采集和手动上报是互补的，不是替代关系。
3.2 数据缓存：给数据找个安全的家
采集到的数据不能马上发出去，因为有网络问题、高并发场景。需要先存起来。缓存策略直接决定了数据会不会在极端情况下丢失。
常见的缓存层级。
| 层级 | 载体 | 特点 | 丢失风险 |
|---|---|---|---|
| 第一级 | 内存队列 | 速度快、易丢失 | 高（App被杀即丢） |
| 第二级 | 数据库 | 可靠、持久化 | 低（除非数据库损坏） |
| 第三级 | 文件 | 跨App重启仍存 | 极低（磁盘写满时可能） |
为什么需要多级缓存？我从实际项目中举个例。有一次，用户App频繁被系统杀后台。如果数据只存在内存里，App一死，数据全丢。但如果我们已经落库了，下次启动就能续传。
核心原则：数据至少要在“内存 + 持久化”两级缓存中都存在，才能保证在App意外退出时不丢。
3.3 数据上传：最后一公里
数据从本地跑到服务器，这步最容易出幺蛾子。上传机制设计得好不好，直接影响数据到达率。
上传策略通常包括：
- 触发时机：定时、或者当数据量达到阈值时。
- 批量上传：把多条记录打包成一次请求，减少网络开销。
- 失败重试：网络超时、服务器返回500，必须重试。
- 去重：防止因为重试导致重复数据。
避坑指南：我曾经接手过一个案例，SDK在上传时用了同步网络请求。结果网络一卡，主线程被阻塞，App直接ANR。最后数据也丢了。记住，上传必须是异步的，最好用独立线程池。
3.4 关键排查点：数据卡在哪一步？
当你发现数据缺失，先定位是三个环节中的哪一个出了问题。
| 现象 | 可能的原因 | 排查方向 |
|---|---|---|
| 采集没数据 | 监听没注册、接口没调用 | 检查初始化代码、回调是否被覆盖 |
| 缓存里有，但不上传 | 上传线程挂死、网络策略限制 | 检查上传队列、重试次数 |
| 上传了但服务端没收到 | 请求格式错误、响应处理漏掉 | 抓包看请求体、比对SDK日志 |
| 数据库里找不到数据 | 写入前crash、数据库表结构变更 | 检查异常日志、表字段是否兼容 |
个人习惯：我每次对接新SDK，第一件事是在采集、缓存、上传这三个节点各加一个埋点日志。这样数据走到哪一步清清楚楚，排查效率翻倍。
3.5 版本兼容与数据结构
还有一个容易忽视的点：版本升级导致的数据格式变化。
举个例子，SDK从v1.0升级到v2.0，事件结构多了一个字段status。如果新版本SDK直接读旧版本的缓存数据，反序列化时就可能失败。数据直接丢了。
// 常见反序列化失败场景
// 旧版本数据
{
"event": "login",
"userId": 12345
}
// 新版本定义了强类型
EventData {
val userName: String? // 没有此字段 -> 解析异常
val userId: Long
}