android-compose-state-effects

Android Compose 状态与副作用

适用场景

• 当请求涉及以下内容时使用此技能：Compose 副作用问题、remember 与 derivedstateof 的区别、在 Compose 屏幕中收集 Flow。
• 主要目标：管理 Compose 状态、remember API、副作用、快照和生命周期感知的收集，避免泄漏或循环。
• 当问题发生在 composable 或 Compose 运行时原语内部时使用此技能；如果要重新设计应用级状态持有者或 reducer，则不适用。
• 此技能关注 Compose 内部的运行时原语。如果问题涉及 reducer 设计、屏幕契约或 ViewModel 归属，请移交给 android-state-management。
• 当范围扩大时，移交给以下技能：
• android-state-management
• android-compose-performance

工作流

1. 首先对问题进行分类：本地记忆状态、已保存状态、派生状态、生命周期感知的收集，或一次性副作用。
2. 选择与问题匹配的最精简 Compose 原语：remember、rememberSaveable、derivedStateOf、produceState、collectAsStateWithLifecycle、LaunchedEffect、DisposableEffect、SideEffect 或 snapshotFlow。
3. 将持久的 UI 状态与 Snackbar、导航和分析等临时事件分开。
4. 稳定副作用键和回调引用，避免重组重新启动工作或捕获过时的 lambda。
5. 只有在隔离出 Compose 运行时问题后，才将更广泛的状态持有者设计移交给 android-state-management。

守则

• 对面向 UI 的 Flow，优先使用 collectAsStateWithLifecycle 等生命周期感知的收集方式。
• 如果副作用需要获取最新的 lambda 或值，但不应重新启动，请使用 rememberUpdatedState。
• 如果一次性副作用实际上属于事件，请勿将其放入不可变的屏幕状态。
• 不要在 composable 函数体中直接启动协程或触发导航，应使用适当的副作用 API。

反模式

• 副作用应该在真实依赖项发生变化时重新启动，却使用 LaunchedEffect(Unit) 或不稳定的键。
• 在多个位置收集 Flow，导致事件重复。
• 将临时事件存储为屏幕状态中持久的布尔值，然后手动重置。
• 在直接读取状态更简单、开销更低时使用 derivedStateOf 或 snapshotFlow。

审查重点

• 哪个运行时原语负责此行为？
• 重组和副作用重启是否符合预期？
• 状态通道和事件通道是否分开建模？
• 收集是否具备生命周期感知能力，并且可安全取消？

示例

正常流程

• 场景：在 Compose 中收集任务状态和 Snackbar 事件，避免重复启动。
• 命令：cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

边界情况

• 场景：处理权限状态和同步状态同时变化时的重组。
• 命令：cd examples/orbittasks-compose && ./gradlew :app:assembleDebug

故障恢复

• 场景：区分状态/副作用问题与一般 Compose 布局或状态管理请求。
• 命令：python3 scripts/eval_triggers.py --skill android-compose-state-effects

完成检查清单

• 所选 Compose 原语与实际运行时问题相匹配。
• 副作用具有稳定的键，不会因重组而重复执行。
• 状态与事件已清晰分离。
• 更广泛的应用状态架构工作已移交，而不是混入 composable 修复中。

官方参考资料

• https://developer.android.com/develop/ui/compose/state
• https://developer.android.com/develop/ui/compose/side-effects
• https://developer.android.com/reference/kotlin/androidx/lifecycle/compose/package-summary
• https://developer.android.com/topic/architecture/ui-layer/state-production