飞翔的十号1. Compose 中的 Side-effects 深度解析
在 Jetpack Compose 的世界里，Side-effects（副作用）是个既让人爱又让人恨的概念。作为声明式 UI 框架的核心挑战之一，它直接关系到我们能否写出正确、高效的 Compose 代码。我在多个大型项目中踩过的坑告诉我：不理解 Side-effects，就等于没真正掌握 Compose。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 什么是 Side-effects
2.1 基本定义
在 Compose 中，Side-effects 指的是发生在可组合函数之外的状态变化。典型的例子包括：
- 修改共享对象的状态
- 更新 ViewModel 中的属性
- 发起网络请求
- 操作 SharedPreferences
这些操作之所以危险，是因为它们可能在不该执行的时候执行，或者执行太多次。我曾在项目中遇到一个 bug：用户每旋转一次屏幕，就会重复提交订单，后来发现正是 Side-effect 处理不当导致的。
2.2 与纯函数的对比
纯函数的特点是：
- 相同输入总是产生相同输出
- 不修改外部状态
- 不依赖外部状态
而 Compose 的理想状态是让所有 @Composable 函数尽可能接近纯函数。但现实需求迫使我们不得不处理 Side-effects，这就需要特定的 API 来管理它们。
3. Compose 提供的 Side-effect API
3.1 LaunchedEffect
这是处理协程作用域内副作用的首选方案。我在实际项目中最常用的模式是：
kotlin复制LaunchedEffect(key1 = viewModel.state) {
if (viewModel.state.shouldLoad) {
viewModel.loadData()
}
}
关键点：
- 当 key1 变化时，会取消之前的协程并启动新的
- 适合一次性或有限次数的异步操作
- 永远不要在 block 外部捕获变量
3.2 rememberCoroutineScope
当需要在组合外启动协程时使用，比如响应用户点击：
kotlin复制val scope = rememberCoroutineScope()
Button(onClick = {
scope.launch {
viewModel.submitData()
}
}) {
Text("Submit")
}
经验法则：优先使用 LaunchedEffect，只有需要在回调中启动协程时才用 rememberCoroutineScope。
3.3 DisposableEffect
用于需要清理的资源，比如监听器：
kotlin复制DisposableEffect(key1 = lifecycleOwner) {
val observer = LifecycleEventObserver { _, event ->
// 处理生命周期事件
}
lifecycleOwner.lifecycle.addObserver(observer)
onDispose {
lifecycleOwner.lifecycle.removeObserver(observer)
}
}
我在实现视频播放器组件时，这个 API 帮我避免了严重的内存泄漏问题。
3.4 SideEffect
用于将 Compose 状态发布到非 Compose 管理的对象：
kotlin复制SideEffect {
analytics.setUserProperty("dark_mode", isDarkMode.toString())
}
与其它 Effect 不同，SideEffect 在每次重组后都会运行，所以要确保其中的操作是幂等的。
4. 常见陷阱与解决方案
4.1 无限重组循环
最危险的错误模式：
kotlin复制var count by remember { mutableStateOf(0) }
LaunchedEffect(Unit) {
count++ // 这会导致无限重组！
}
解决方案：永远不要在 Effect 中直接修改触发该 Effect 的状态。
4.2 过早取消协程
当 key 变化太快时，协程可能在被完成前就被取消。我的应对策略是：
kotlin复制LaunchedEffect(key1 = userId) {
val data = async { repo.loadUser(userId) }.await()
// 检查是否仍然是当前的 userId
if (userId == latestUserId) {
_userData.value = data
}
}
4.3 遗漏清理操作
特别是在 Android 生命周期场景中：
kotlin复制DisposableEffect(key1 = view) {
val listener = MyListener()
view.addListener(listener)
onDispose {
// 我经常在这里加日志确认清理确实发生了
Log.d("Effects", "Cleaning up listener")
view.removeListener(listener)
}
}
5. 高级模式与实践
5.1 自定义 Effect API
对于复杂场景，可以创建自己的 Effect 封装：
kotlin复制@Composable
fun PermissionEffect(
permission: String,
onGranted: () -> Unit,
onDenied: () -> Unit
) {
val context = LocalContext.current
LaunchedEffect(permission) {
val status = rememberPermissionState(permission)
when {
status.hasPermission -> onGranted()
status.shouldShowRationale -> onDenied()
else -> status.launchPermissionRequest()
}
}
}
5.2 测试策略
测试 Side-effects 需要特殊处理：
kotlin复制@Test
fun testMyEffect() = runTest {
composeTestRule.setContent {
var clicked by remember { mutableStateOf(false) }
MyComponent(
onClick = { clicked = true }
)
if (clicked) {
LaunchedEffect(Unit) {
viewModel.doSomething()
}
}
}
// 验证效果
composeTestRule.onNodeWithText("Click me").performClick()
advanceUntilIdle()
verify(viewModel).doSomething()
}
5.3 性能优化
对于高频变化的状态，使用 derivedStateOf 减少不必要的 Effect 触发：
kotlin复制val scrollState = rememberScrollState()
val isAtBottom by remember {
derivedStateOf {
scrollState.value == scrollState.maxValue
}
}
LaunchedEffect(isAtBottom) {
if (isAtBottom) loadMore()
}
6. 架构整合模式
6.1 与 MVI 配合
在 MVI 架构中，Effects 通常对应 "单次事件"：
kotlin复制// ViewModel
private val _effects = Channel<UiEffect>()
val effects = _effects.receiveAsFlow()
fun submitForm() {
viewModelScope.launch {
_effects.send(UiEffect.ShowToast("Submitted!"))
}
}
// Composable
LaunchedEffect(Unit) {
viewModel.effects.collect { effect ->
when (effect) {
is UiEffect.ShowToast -> toast(effect.message)
}
}
}
6.2 与 Retrofit 协同
处理网络请求时的最佳实践：
kotlin复制LaunchedEffect(key1 = userId) {
try {
_state.value = State.Loading
val data = repository.fetchUser(userId)
_state.value = State.Success(data)
} catch (e: Exception) {
_state.value = State.Error(e)
_effects.send(UiEffect.ShowError(e))
}
}
关键点：
- 在 Effect 内处理异常
- 通过 State 和 Effect 两个通道分离 UI 状态和单次事件
7. 调试技巧
当 Side-effects 行为异常时，我的调试三板斧：
- 添加调试日志：
kotlin复制LaunchedEffect(key1 = dep) {
println("Effect triggered with $dep")
// ...
}
- 使用 Android Studio 的 Composition 调试工具：
- 查看重组次数
- 检查 Effect 的存活状态
- 临时添加 key 强制重置：
kotlin复制LaunchedEffect(key1 = Unit) { // 临时改为 Unit 测试是否效果符合预期
// ...
}
8. 跨平台注意事项
在 Compose Multiplatform 中，有些 Effect 行为可能不同：
- iOS 上没有真正的生命周期概念
- Desktop 的窗口事件处理需要特殊考虑
- Web 的副作用管理更加严格
我的经验是：为每个平台实现特定的 Effect 封装层，共享核心逻辑但处理平台差异。
9. 实战案例：实现智能列表
结合上述所有知识，我们实现一个智能列表：
kotlin复制@Composable
fun SmartList(
items: List<Item>,
onLoadMore: () -> Unit,
onItemClick: (Item) -> Unit
) {
val listState = rememberLazyListState()
// 滚动到底部加载更多
val shouldLoadMore by remember {
derivedStateOf {
val layoutInfo = listState.layoutInfo
val lastVisibleItem = layoutInfo.visibleItemsInfo.lastOrNull()
lastVisibleItem?.index == layoutInfo.totalItemsCount - 3
}
}
LaunchedEffect(shouldLoadMore) {
if (shouldLoadMore) onLoadMore()
}
// 跟踪滚动位置
SideEffect {
analytics.trackScrollPosition(listState.firstVisibleItemIndex)
}
// 处理点击
LazyColumn(state = listState) {
items(items) { item ->
ItemRow(
item = item,
onClick = { onItemClick(item) }
)
}
}
}
这个实现展示了：
- 派生状态优化性能
- 两种不同的 Effect 使用场景
- 纯 UI 与副作用逻辑的清晰分离
10. 未来演进方向
虽然 Compose 的 Effect 系统已经很强大，但仍有改进空间：
- 更细粒度的 Effect 控制
- 更好的调试工具支持
- 与 Kotlin Flow 更深的集成
在我最近的项目中，我们实验性地使用了一个自定义的 Effect 记录器，可以可视化所有 Effect 的触发和清理过程，这对复杂界面的调试帮助很大。