4、埋点数据采集框架设计：采集层、存储层、上报层的分层架构设计思想
做埋点框架，最怕什么？
我早期参与过一个项目，所有埋点逻辑都揉在一个大Manager类里。采集、缓存、上报混在一起，改个上报间隔要动核心代码，想加个新采集源得小心翼翼。上线后崩溃率飙升，排查半天才发现是埋点代码阻塞了UI线程。
那次经历让我彻底明白——埋点框架必须分层。只有把采集、存储、上报拆开，每个层各司其职，才能扛住AMS启动阶段的高并发压力，也才能让团队并行开发不打架。
今天聊聊我心中的三层架构，以及每个层该怎么设计。
4.1 三层架构总览
说白了，就是把埋点数据流切成三段：
- 采集层 — 负责从各个AMS组件抓取原始数据，组装成统一格式
- 存储层 — 负责临时缓存，保证数据不丢、不重复
- 上报层 — 负责按策略把数据安全送到服务端
每一层只关心自己的事儿，层与层之间通过接口契约通信。这样哪怕换存储方案，采集层和上报层不用动一行代码。
下面这张图是我当前项目里的分层设计，你看一眼就明白数据是怎么流动的了。
4.2 采集层 — 快、准、稳
采集层是框架的入口。AMS启动阶段，各种组件狂发消息，采集点可能被频繁触发。这时候最忌讳的就是做耗时操作。
我来说说采集层里几个关键模块：
- AMS组件采集点 — 就是在系统关键流程里埋的钩子。比如ActivityManagerService里的某个方法执行完，立刻调用采集接口传入原始数据。这里只收集最朴素的参数，不做任何加工。
- 数据组装器 — 把原始参数拼成一个标准Event对象。字段包括eventName、timestamp、traceId、payload、extras等。组装过程要快，我通常用预创建的ObjectPool来减少GC。
- 过滤与去重 — 比如同一个事件在500ms内连续来了10次，只保留第一条。还有采样率控制：Debug版本全采，Release版本按1%采样。
- 初始化校验 — 采集器启动前检查SDK是否初始化、必要权限是否拿齐。如果不满足，直接返回空操作，不往存储层塞数据。
举个例子，我遇到过AMS启动时一个回调被重复注册导致采集点被调了两次。后来我在采集层里加了一个幂等校验——同一个traceId + eventName的组合，200ms内只允许入队一次。
4.3 存储层 — 既要快又要稳
采集层塞过来的数据，需要先暂存起来。为什么？因为上报是异步的，网络可能还没好。如果数据直接丢内存里，App一杀进程就全没了。
我在项目中用了两级缓冲：
| 级别 | 介质 | 特点 | 适用场景 |
|---|---|---|---|
| 一级缓存 | 内存环形缓冲区 | 无锁写入，延迟纳秒级 | 高频突发写入 |
| 二级缓存 | SQLite / 文件 | 持久化，进程被杀不丢失 | 兜底 & 后台保活 |
存储层还负责数据分桶。比如按事件优先级分紧急桶、普通桶、低优桶。上报时可以优先发送紧急桶。另外还要定期清理过期数据，避免磁盘被埋点日志撑爆。
4.4 上报层 — 可靠与节制的平衡
上报层从存储层拉数据，然后发往服务端。这里的设计要点：
- 上报策略引擎 — 支持定时上报（比如每30秒）、阈值触发（比如攒够50条）、以及App从后台切到前台时的兜底上报。你想想看，如果用户一直停留在前台，每30秒上报一次就够了；但如果用户突然锁屏，就要立刻触发一次，防止数据积压。
- 数据压缩 — 批量数据一定要压缩。我习惯用GZip，压缩比大概5~10倍，能省不少流量。
- 网络发送器 — 用独立的线程池，避免阻塞主线程。连接超时和读超时都要设短一些，比如5秒和10秒。
- 重试与退避 — 遇到网络错误，不能疯了似的重试。我一般用指数退避：第一次间隔2秒，第二次4秒，第三次8秒……最多重试5次。如果连续5次都失败，说明网络确实不行，那就静默丢弃，同时记录一个本地日志给开发者。
我记得有一次线上环境，用户WiFi信号弱，重试逻辑写成了死循环，导致CPU飙升。后来加了最大重试次数和降级兜底，才稳定下来。
4.5 为什么一定要分层？
说实话，如果不分层，功能也能跑。但后期维护的成本会指数级上升。你想，如果哪天要换磁盘存储方案，从SQLite换成MMKV，采集层和上报层需要动吗？不需要。只要存储层重新实现接口就行。
分层的另一个好处是可测试性：每层都能单独写单元测试。我习惯在每个层都定义一个MockProvider，跑UT时把实际实现替换掉，就能快速验证逻辑。
嗯，讲到这里，相信你对采集层的快、存储层的稳、上报层的节，已经有感觉了。下一实际操作时，记得先从接口定义开始，把每一层的契约敲死，再逐层填充实现。这样不容易翻车。