3. 埋点采集SDK架构：SDK分层设计、核心模块划分、初始化流程
好，我们直接进入正题。
埋点采集SDK，说白了就是风控系统的“眼睛”。你后端规则写得再牛，数据采集不上来，一切都是白搭。我见过太多团队，风控模型跑得飞起，结果发现埋点数据丢了30%，那感觉就像开车蒙着眼——太危险了。
今天我就把SDK的骨架拆给你看。怎么分层、怎么划模块、启动时该做什么。这些是我在几个项目里踩坑踩出来的经验，希望能帮你少走弯路。
3.1 SDK分层设计：为什么必须分层？
先问个问题：你写SDK时，是不是把所有代码都塞到一个类里？
我以前也这么干过。结果呢？业务方要加个新事件，我得改核心逻辑；要换个网络库，我得动整个SDK。维护成本高得吓人。
所以，分层是必须的。我个人习惯分三层：
- 接入层（API层）：给业务方调用的接口。简单、稳定、不轻易变。
- 核心层（Core层）：处理数据采集、缓存、压缩、序列化。这是SDK的大脑。
- 基础层（Foundation层）：网络请求、本地存储、设备信息获取。说白了就是干苦力活的。
你想想看，这样分层后，业务方只跟接入层打交道。核心层出了问题，我改内部逻辑，接口不变，业务方完全无感知。这才是好的SDK设计。
核心原则：上层依赖下层，下层绝不能反向依赖上层。这是铁律。
3.2 核心模块划分：每个模块负责什么？
分层是骨架，模块是器官。我一般把SDK拆成这几个核心模块：
| 模块名称 | 职责 | 避坑点（我踩过的） |
|---|---|---|
| 事件采集器 | 接收业务方的事件调用，做初步校验和格式化 | 曾经有个同事没做参数校验，结果空指针崩了线上App |
| 数据缓存器 | 将事件暂存到内存或本地数据库，防止丢失 | 缓存策略要谨慎，我见过内存撑爆的案例 |
| 数据处理器 | 做数据清洗、去重、压缩、加密 | 压缩率不是越高越好，要考虑手机CPU开销 |
| 网络发送器 | 将数据上报到服务端，支持重试和流量控制 | 重试机制要有指数退避，否则会把服务器打挂 |
| 配置管理器 | 拉取远程配置，控制采样率、上报频率等 | 配置下发要有版本号，防止旧配置覆盖新配置 |
嗯，这里要注意：模块之间通信要定义好接口。我习惯用事件总线或者回调的方式，避免模块间直接耦合。
3.3 初始化流程：SDK启动时到底做了什么？
初始化是SDK的“第一口气”。搞不好，后面全白费。
我画了一张流程图，帮你理清初始化顺序：
具体每一步做什么？我拆开来讲：
3.3.1 配置加载
SDK启动后第一件事，就是读配置。配置来源有三个：本地默认配置、上次缓存的配置、远程下发的配置。优先级是：远程 > 本地缓存 > 默认。
我曾经遇到过一个坑：远程配置下发失败时，SDK直接罢工了。后来我加了个降级策略——用本地默认配置兜底，至少保证能采集数据。
3.3.2 初始化核心模块
这一步是按顺序初始化各个模块。顺序很重要：先初始化缓存器，再初始化处理器，最后初始化发送器。为什么？因为发送器依赖缓存器提供数据，处理器依赖缓存器暂存中间结果。
小技巧：初始化时加一个超时机制。如果某个模块初始化超过3秒，直接跳过，不要阻塞主线程。我见过因为网络模块初始化慢，导致App启动卡顿的惨案。
3.3.3 启动数据采集
核心模块就绪后，开始监听事件。这里要注意：启动采集不等于立即上报。数据先入缓存，等达到阈值或者定时器触发，再批量上报。
嗯，我习惯在启动采集时，先检查本地有没有未上报的旧数据。如果有，优先处理旧数据，再接收新事件。这样可以防止数据堆积。
3.3.4 建立网络连接
这一步是异步的。SDK尝试跟服务端建立长连接或者短连接。我个人推荐用长连接，减少频繁建连的开销。但要注意心跳保活，我见过因为心跳间隔太短，把服务器打爆的案例。
3.3.5 上报启动事件
最后一步，上报一个“SDK启动成功”的事件。这个事件很重要，它告诉服务端：这个设备的风控SDK已经活了。服务端可以根据这个事件，决定是否下发特殊配置。
警告：启动事件不要包含敏感信息。我曾经见过有人把设备全部信息都塞进启动事件里，结果被中间人抓包，用户隐私全泄露了。启动事件只上报：SDK版本号、设备ID、时间戳。够了。
3.4 代码示例：初始化流程的核心逻辑
光说不练假把式。我写一段伪代码，展示初始化流程的核心逻辑：
class RiskSDK {
fun init(context: Context, config: SDKConfig) {
// 1. 配置加载
val mergedConfig = ConfigLoader.load(context, config)
// 2. 初始化核心模块（按顺序）
val cacheManager = CacheManager.init(mergedConfig)
val processor = DataProcessor.init(mergedConfig, cacheManager)
val sender = NetworkSender.init(mergedConfig, cacheManager)
// 3. 启动数据采集
val collector = EventCollector.init(mergedConfig, processor)
collector.start()
// 4. 建立网络连接（异步）
Thread {
sender.connect()
// 5. 上报启动事件
sender.send(StartupEvent(version = mergedConfig.version))
}.start()
// 记录初始化完成
Log.d("RiskSDK", "初始化完成，版本: ${mergedConfig.version}")
}
}你看，代码逻辑跟流程图完全对应。每一步都有明确的输入输出，模块之间通过接口交互，互不干扰。
3.5 避坑指南：初始化时最容易犯的错
最后，我分享几个我亲身踩过的坑：
- 不要在初始化时做耗时操作：比如网络请求、数据库迁移。这些应该异步做。否则用户会骂你App启动慢。
- 初始化失败要有重试机制：但重试次数不要超过3次，间隔至少5秒。我曾经设了10次重试，结果用户手机电量哗哗掉。
- 多线程安全问题：初始化时多个模块可能同时访问共享资源。记得加锁，或者用单线程池。我见过因为并发问题，导致缓存数据错乱的案例。
- 版本兼容性：SDK升级时，初始化逻辑可能变了。要兼容旧版本的缓存数据。我习惯在初始化时检查缓存数据的版本号，如果不兼容，直接清空重建。
好了，这一章的内容就到这里。SDK分层设计、核心模块划分、初始化流程，这三个点你吃透了，埋点采集SDK的骨架就算搭起来了。下一章我们会深入数据采集的具体实现，到时候再聊。