各个 SDK 介绍

答：各个 SDK 依赖介绍：

// SDK 国内版主依赖：二选一即可
// lite 无法使用全埋点、圈选、h5 打通，如果仅需要自定义埋点使用 lite 即可，反之可以选择 all
implementation 'com.bytedance.applog:RangersAppLog-All-cn:6.17.1'
implementation 'com.bytedance.applog:RangersAppLog-Lite-cn:6.17.1'
// SDK 海外版主依赖：二选一即可
// global 与 cn 的区别在于去掉了部分敏感字段采集，功能上无差别
implementation 'com.bytedance.applog:RangersAppLog-All-global:6.17.1'
implementation 'com.bytedance.applog:RangersAppLog-Lite-global:6.17.1'

// 本地调试工具（可选），用于本地可视化调试
debugImplementation 'com.bytedance.applog:RangersAppLog-DevTools:3.4.7'

// 圈选/实时埋点配置（可选），内部没有代码仅有一个清单文档声明，方便扫码时按照唤醒协议跳转
implementation 'com.bytedance.applog:RangersAppLog-All-scheme:6.17.1'

// SDK 插件（可选），用于做全埋点、h5 打通、隐私字段采集代码移除的插桩功能
// agp8 以下版本依赖
classpath 'com.bytedance.applog:RangersAppLog-All-plugin:6.17.1'
// agp8 以上版本依赖
classpath 'com.bytedance.applog:RangersAppLog-All-plugin-agp8:6.17.1'

数据上报前提

数据上报前置条件为完成SDK初始化，上报前会检查SDK初始化的 config 中是否配置了setAutoStart(false) ：

• 如果没有配置过， init 之后就会定时上报数据。
• 如果配置过，会等待开发者调用 start 之后开始定时上报数据。

数据上报流程与逻辑

1. SDK 初始化：

SDK初始化之后会检测当前进程，如果是主进程则开始创建定时上报任务，子进程不会处理。

2. 触发时机：
   • 启动定时发送任务，默认上报间隔为 1min，每隔 5s 检测一次是否触发下次上报，私有化支持云控配置缩短上报间隔。
   • 如果检测已经到了上报时间，就会触发上报，否则延迟 5s 下次检测。
3. 上报前检测：
   • 检测设备是否注册成功，因为前置上报需要设备注册返回的 did 与 ssid（事件需要正确绑定 ssid 所以针对产生时没有 ssid 的事件，会在上报前做 ssid 补充），如果已成功则继续。
   • 上报前还会检测是否满足频控限制，如果当前没有触发频控则继续走上报流程，如果触发了频控则按照频控判断当前是否能够上报。
   1. 频控的目的主要是为了在服务端不可用时限制端上上报请求频次，避免在服务端不可用时带来更多压力。
4. 数据打包与上报：
   • 首先先查询已存储至APP数据库中的数据进行打包，用于上报数据（上报数据单位为 pack，pack 是数据包，每个数据包最多包含 200 事件，将查询到事件整体打包成一个 pack 进行上报），来源分成两部分：
     • 上次失败的 pack
     • 本地事件聚合成的新 pack
   • 按照不同版本的查询策略查询到需要发送的 pack 后，针对每个 pack 单独上报。
     • 6.15.0 之后，每次最多查询 8 个 pack（可粗略理解每分钟最多上报 200 * 8 = 1600 条事件）。
     • 6.15.0 之前，每次最多查询 1 个 pack（可粗略理解每分钟最多上报 200 * 1 = 200 条事件）。
5. 数据上报后处理：

每个 pack 上报后，都会做以下处理：

• 上报成功，删除上报对应 pack，并对频控做升级处理。
• 上报失败，将失败信息记录到对应 pack 中，等待下次重新发送，如果本次服务端返回的错误为 5xx 则进行频控降级处理。

6. 发送完查询到的 pack 后，本次发送结束，回到第 2 步，等待下次触发上报。