1. 埋点状态管理的核心问题

1.1 状态驱动与事件上报的冲突

Compose 的声明式 UI 以状态为单一驱动源：状态变化触发重组，重组更新界面。但埋点天然是事件驱动行为——用户点击、页面曝光、业务结果都需要在确定的时机上报一次。这两种模型在以下场景产生直接冲突：

• 重组不确定性：同一状态变化可能触发多次重组，若在重组中直接上报事件，会导致重复埋点。
• 副作用的执行时机：LaunchedEffect / SideEffect 的协程作用域受 Composable 生命周期约束，无法精确映射业务事件的生命周期。
• 状态衍生的"假曝光"：列表快速滑动时，不可见 Item 也可能因缓存状态被短暂重组，产生无意义曝光事件。

1.2 传统埋点方案在 Compose 中的局限性

Android 传统埋点方案（AOP 打点、基类拦截、手动埋点）依赖 View 系统的事件分发和生命周期回调，迁移到 Compose 后出现系统性失效：

1.3 状态管理对埋点准确性的影响

Compose 的状态管理策略（StateFlow / MutableState / SnapshotStateList）直接影响埋点事件的时机和完整性：

• StateFlow 的 collect 时机：LaunchedEffect 中 collect 首次是冷的，需要等到挂起，可能错过初始状态埋点。
• MutableState 的快照系统：同一 recomposition 中多次读取 MutableState 可能合并为一次 snapshots，导致埋点丢失中间态。
• 瞬时状态 vs 持久状态：UI 级别的局部状态（如滚动偏移）变化极快，如果每帧检查并上报，会引发性能问题和无效埋点风暴。

// 错误示例：重组时直接上报
@Composable
fun BadTrackingExample(count: Int) {
    // 每次重组都调用——严重错误！
    Tracking.report("count_changed", mapOf("value" to count))
    Text("Count: $count")
}

// 正确示例：使用 LaunchedEffect 精确控制时机
@Composable
fun GoodTrackingExample(count: Int) {
    LaunchedEffect(count) {
        // 仅在 count 真实变化时上报
        Tracking.report("count_changed", mapOf("value" to count))
    }
    Text("Count: $count")
}

1.4 核心问题归纳：埋点数据流冲突

下图直观展示 Compose 中状态驱动和事件上报两条数据流在 Composable 层产生的冲突：

1.5 章节小结

Compose 埋点状态管理的三个核心问题互为因果：状态驱动与事件上报的冲突 根源于声明式范式，传统方案失效 加剧了迁移成本，而 状态管理策略不当 会直接破坏埋点准确性。后续章节将逐一给出可落地的解耦模式、Effect 防护策略和状态分支管理方案。