📚 课程目录第1章协程基础与埋点场景

1. 协程基础与埋点场景

埋点上报链路中，网络请求、文件写入、数据聚合等操作必须在后台线程执行，避免阻塞主线程。Kotlin 协程通过轻量级挂起机制和内置调度器，为埋点链路提供了一套 非阻塞、可取消、线程安全 的异步方案。本章从协程调度器、挂起函数、非阻塞延迟三个核心概念出发，分析埋点上报的线程模型痛点，为后续链路优化奠定基础。

1.1 协程调度器

调度器决定协程在哪个线程或线程池上执行。Kotlin 内置四种标准调度器，各自适用不同场景：

调度器	线程模型	适用场景
`Dispatchers.Main`	Android 主线程（单线程）	UI 更新、界面交互
`Dispatchers.IO`	动态线程池，专为 IO 操作优化	网络请求、文件读写、数据库操作
`Dispatchers.Default`	CPU 密集型任务线程池（大小 = 核心数 + 1）	数据加权、聚合计算、JSON 解析
`Dispatchers.Unconfined`	非固定，随调用线程变化	极少使用，仅用于临时测试

选型建议：埋点上报中网络请求使用 Dispatchers.IO；若数据需要聚合计算（如生成上报内容摘要），可用 withContext(Dispatchers.Default) 隔离计算逻辑。

1.2 挂起函数与非阻塞延迟

挂起函数是协程的核心抽象：函数执行到 suspend 点时暂停协程，释放线程资源；待条件满足后在指定调度器上恢复执行。非阻塞延迟 delay() 是典型的挂起函数，底层不占用线程，而是将协程挂起一段时间后由调度器重新调度。

以下代码展示埋点上报链路中挂起函数与调度器的配合：

// 挂起函数：模拟网络上报
suspend fun reportEvent(event: Event): Boolean {
    // 自动切换到 IO 线程执行网络请求
    return withContext(Dispatchers.IO) {
        // 实际网络调用（如 OkHttp）
        val response = httpClient.post("https://api.example.com/track", event.toJson())
        response.isSuccessful
    }
}

// 调用方（主线程）
lifecycleScope.launch {
    // 非阻塞延迟 200ms，用于批量合并事件
    delay(200L)
    val success = reportEvent(lastEvent)
    if (success) {
        log("上报成功")
    }
}

  关键理解：withContext(Dispatchers.IO) 不会阻塞主线程，而是挂起当前协程，将执行上下文切换到 IO 线程池；delay() 同样不阻塞线程，而是挂起协程，200ms 后自动恢复。

1.3 埋点上报线程模型痛点

传统基于回调的回调地狱、竞态条件和线程泄漏问题，在协程下得到根本缓解。但如果不正确使用调度器，仍会出现：

主线程阻塞：在 Dispatchers.Main 中执行了陷入式 IO 或 CPU 密集操作
线程爆发：大量并发协程同时使用 Dispatchers.IO 且不做限流，导致线程池膨胀
上下文泄漏：协程在 Activity/Fragment 销毁后仍在执行，导致内存泄漏或崩溃
重复上报：延迟期间任务被取消但底层网络请求仍继续，造成冗余流量

下图梳理了协程调度、挂起恢复与埋点上报线程模型的关系：

1.4 常见错误与优化方向

错误模式	现象	优化方案
主线程直接使用 `runBlocking`	ANR、界面卡顿	改用 `launch` 或 `async`，避免阻塞主线程
未取消协程导致泄漏	内存泄漏、异常崩溃	使用 `viewModelScope` 或 `lifecycleScope`，绑定生命周期
过多并发 IO 协程	线程池膨胀，CPU 负载升高	使用 `limitedParallelism` 或信号量限制并发数
`delay` 与 `Thread.sleep` 混用	阻塞线程，降低吞吐	全程使用挂起函数 `delay`

埋点性能红线：单次上报链路中，调度器切换次数应控制在 2～3 次以内。每多一次 withContext 就多一次线程上下文切换开销，高频埋点场景下可能拖累 UI 帧率。

掌握协程调度器、挂起函数与非阻塞延迟，是构建高效埋点上报链路的基石。下一环节将深入探讨埋点数据的分片聚合与批量提交策略。