1. 埋点上报链路现状分析

在大型 Android 应用中，埋点上报链路通常横跨客户端、网络、后端多个子系统。本章从 链路拓扑、性能瓶颈、数据一致性挑战 三个维度分析现状，为后续的协程优化提供定量依据。

1.1 链路拓扑

典型埋点上报链路包含以下物理与逻辑层级（见下面 SVG 拓扑图）：

• App 客户端：业务代码调用埋点 SDK，产生事件对象。
• 埋点 SDK 缓存层：使用内存队列（如 LinkedBlockingQueue）或数据库（如 SQLite 或 MMKV）暂存事件。
• 上报通道：通过 HTTP（OkHttp）或 WebSocket 将批量事件发送给后端。
• 后端接收网关：负载均衡 + API 网关，初步校验并转发。
• 数据清洗与存储：消息队列（Kafka）缓冲，清洗后写入 HDFS / Clickhouse / Elasticsearch。

1.2 性能瓶颈

在传统回调/线程池方案下，埋点上报存在以下 可量化瓶颈：

1.3 数据一致性挑战

埋点数据不一致主要源于以下场景：

1. 进程异常退出：内存中的事件未持久化即丢失。
2. 重复上报：后端幂等设计不完善，重试导致同一事件多次入库。
3. 乱序到达：多条端点分属不同线程，到达后端时序反转。
4. 截断/合并：批量打包时因大小限制截断，造成事件属性不完整。

1.4 当前实现关键代码片段（优化前）

以下展示传统线程池 + 回调的埋点上报示意（仅用于对比，非本课程最终方案）：

// 传统线程池批量上报（简化版本）
class LegacyTracker {
    private val queue = ConcurrentLinkedQueue<Event>()
    private val executor = Executors.newScheduledThreadPool(2)

    fun track(event: Event) {
        queue.offer(event)
    }

    init {
        executor.scheduleWithFixedDelay({
            val batch = mutableListOf<Event>()
            while (queue.isNotEmpty() && batch.size < 20) {
                queue.poll()?.let { batch.add(it) }
            }
            if (batch.isNotEmpty()) {
                uploadBatch(batch) // 同步阻塞上传
            }
        }, 0, 5, TimeUnit.SECONDS)
    }
}