深入理解 Jetpack Compose 生命周期

作为 Android 声明式 UI 框架的代表，Jetpack Compose 彻底改变了 UI 开发模式。与传统 View 体系中 "回调驱动" 的生命周期（如onCreate/onStart/onDestroy）不同，Compose 的生命周期完全由状态变化 和组合树（Composition Tree） 驱动。本文将从核心概念出发，逐步拆解 Compose 生命周期的关键阶段、感知工具及实践注意事项。

一、先搞懂 3 个核心概念：Compose 生命周期的基石

在聊生命周期之前，必须先明确 3 个高频术语 ------ 它们是理解 Compose 生命周期的前提：

1. 组合（Composition）

定义：Compose 执行@Composable函数后，生成的 "UI 描述树"（即组合树），包含 UI 的结构、样式和交互逻辑。
本质：这是 Compose 对 "当前 UI 应该长什么样" 的不可变快照，后续 UI 更新需通过 "重组" 生成新快照。

2. 重组（Recomposition）

定义：当 Compose 感知到状态（如State、LiveData）变化时，重新执行受影响的@Composable函数，更新组合树的过程。
特点：
- 局部性：仅重新执行 "依赖变化状态" 的 Composable，而非整个 UI 树（性能优化核心）；
- 可中断：Compose 会优先处理更紧急的重组，避免资源浪费。

3. 状态驱动（State-Driven）

核心逻辑：Compose 生命周期的所有变化（组合、重组、退出），本质都是 "状态变化" 的结果。
对比传统 View ：传统 View 需手动调用setVisibility/setText更新 UI，而 Compose 只需维护状态 ------ 状态变了，UI 自动跟着变。

二、Compose 生命周期的 3 个关键阶段

Compose 的生命周期可简化为 "从创建到销毁" 的 3 个核心阶段，每个阶段对应明确的触发条件和行为：

1. 初始组合（Initial Composition）

触发时机 ：首次执行setContent（或ComposeView.setContent）时，Compose 启动并执行根@Composable函数。
核心行为：

执行@Composable函数体内的逻辑（如创建 Text、Button 等 UI 元素）；
构建初始组合树，将 UI 描述转换为 Android 可渲染的 View（底层通过ComposeView桥接）；
为依赖的状态（如remember { mutableStateOf() }）建立 "观察者关系"------ 后续状态变化会触发重组。

示例场景：

kotlin 复制代码

class MainActivity : ComponentActivity() {

 override fun onCreate(savedInstanceState: Bundle?) {

   super.onCreate(savedInstanceState)

   // 触发初始组合：执行MyApp()函数，构建初始UI

   setContent {

     MyApp() // 根Composable

   }

 }

}

@Composable

fun MyApp() {

 Text("Hello Compose") // 初始组合时创建

}

2. 重组（Recomposition）

触发时机 ：当 Compose 感知到 "被观察的状态" 发生变化时（如mutableStateOf的值被修改）。
核心行为：

识别 "依赖该状态的 Composable 范围"（如仅重新执行包含state.value的代码块）；
重新执行这些 Composable，生成新的 UI 描述；
对比新旧组合树的差异，仅更新变化的部分（Diffing 优化）。

关键注意点：
- 重组可能 "频繁且不可预测"：同一状态变化可能触发多次重组（如快速点击按钮修改状态）；
- 重组是 "幂等的"：@Composable函数应避免副作用（如网络请求、数据库操作），否则可能重复执行。
示例场景（点击按钮更新文本）：

kotlin 复制代码

@Composable

fun Counter() {

 // 状态：count变化时触发重组

 val count = remember { mutableStateOf(0) }

 Column {

   // 依赖count的Composable：count变化时仅重新执行此Text

   Text("当前计数：${count.value}")


   Button(onClick = { count.value++ }) {

     Text("点击加1") // 不依赖count，仅初始组合时执行一次

   }

 }

}

3. 退出组合（Exit Composition）

触发时机：Composable 从组合树中移除时（如条件判断不满足、页面销毁）。
核心行为：

释放该 Composable 关联的资源（如协程、监听器、内存缓存）；
解除与状态的观察者关系，避免内存泄漏。

示例场景（条件控制 Composable 存在性）：

kotlin 复制代码

@Composable

fun ConditionalUI(show: Boolean) {

 if (show) {

   // show=true时：加入组合树（初始组合）

  DisposableEffect(Unit) {

     println("UI已创建")

     // show=false时：执行onDispose（退出组合）

     onDispose {

       println("UI已销毁，释放资源")

     }

   }

   Text("我只在show=true时存在")

 }

 // show=false时：Text从组合树移除（退出组合）

}

三、生命周期感知工具：如何处理 "副作用"？

Compose 的@Composable函数是 "纯函数"（无副作用），但实际开发中难免需要处理副作用（如协程、网络请求、注册监听器）。此时需用 Compose 提供的 "生命周期感知 API"，确保副作用与 Composable 生命周期同步。

1. LaunchedEffect：生命周期绑定的协程

用途：在 Composable 中启动协程，且协程会随 Composable 退出组合而自动取消。
核心参数：
- key1/key2：依赖的 "键"------ 当键变化时，会取消旧协程并启动新协程；
- 若键为Unit，则仅在初始组合时启动一次。
示例（页面可见时请求数据）：

kotlin 复制代码

@Composable

fun DataRequestUI() {

   val data = remember { mutableStateOf<String?>(null) }

   // 初始组合时启动协程，退出组合时取消

   LaunchedEffect(Unit) {

       // 模拟网络请求（副作用）

       val result = api.fetchData()

       data.value = result // 更新状态，触发重组

  }

  Text(data.value ?: "加载中...")

}

2. DisposableEffect：资源注册与释放

用途：处理 "需要手动释放" 的资源（如注册监听器、订阅广播），确保资源在退出组合时释放。
强制要求 ：必须实现onDispose回调（释放资源的逻辑），否则编译报错。
示例（注册 / 注销传感器监听器）：

kotlin 复制代码

@Composable

fun SensorUI() {

 val sensorManager = getSystemService(SENSOR_SERVICE) as SensorManager

 val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

 DisposableEffect(accelerometer) {

   // 初始组合：注册监听器（副作用）

   val listener = object : SensorEventListener {

     override fun onSensorChanged(event: SensorEvent) {

       // 处理传感器数据

     }

     override fun onAccuracyChanged(sensor: Sensor?, accuracy: Int) {}

   }

   sensorManager.registerListener(listener, accelerometer, SensorManager.SENSOR_DELAY_UI)

   // 退出组合：注销监听器（释放资源）

   onDispose {

     sensorManager.unregisterListener(listener)

   }

 }

}

3. rememberUpdatedState：避免重组时的 "过时值"

用途：当LaunchedEffect/DisposableEffect的 "键未变化" 但依赖的变量已更新时，确保内部逻辑使用最新值。
场景：若直接在 Effect 中引用外部变量，可能因 "闭包捕获" 导致使用旧值（因为 Effect 未重组）。
示例（解决 "过时值" 问题）：

kotlin 复制代码

@Composable

fun TimerUI(interval: Int) { // interval可能动态变化

 // 用rememberUpdatedState保存最新的interval

 val latestInterval = rememberUpdatedState(interval)

 LaunchedEffect(Unit) { // 键为Unit，仅启动一次协程

   while (true) {

     delay(latestInterval.value.toLong()) // 始终使用最新的interval

     println("定时器触发")

   }

 }

}

4. SideEffect：任意时机的副作用

用途：在每次重组完成后执行副作用（如上报埋点、更新外部状态）。
注意：无生命周期绑定 ------ 每次重组都会执行，需谨慎使用（避免频繁操作）。
示例（重组后上报 UI 状态）：

kotlin 复制代码

@Composable

fun TrackedUI(count: Int) {

 Text("计数：$count")



 // 每次重组完成后上报埋点

 SideEffect {

   Analytics.report("count_updated", mapOf("count" to count))

 }

}

四、常见问题与最佳实践

1. 避免 "过度重组"

问题：不必要的重组会浪费性能（如频繁修改未被 UI 依赖的状态）。
解决方案：

kotlin 复制代码

// 优化示例：用derivedStateOf减少重组

@Composable

fun FilteredList(items: List<String>, query: String) {

 // 仅当items或query变化时，才重新计算过滤结果

 val filteredItems = remember(items, query) {

   derivedStateOf {

    items.filter { it.contains(query) }

   }

 }

 LazyColumn {

   items(filteredItems.value) { Text(it) }

 }

}

缩小状态作用域：将状态定义在 "最小依赖范围" 内（如子 Composable 而非根 Composable）；
使用remember缓存计算结果：避免重组时重复执行耗时计算（如remember { heavyCalculation() }）；
用derivedStateOf转换状态：当 UI 依赖 "多个状态的组合结果" 时，减少重组触发次数。

2. 避免 "内存泄漏"

问题：若副作用未随 Composable 退出而释放（如未取消协程、未注销监听器），会导致内存泄漏。
解决方案：
- 协程用LaunchedEffect（自动取消）；
- 资源用DisposableEffect（强制onDispose释放）；
- 避免在 Composable 中持有 Activity/Fragment 引用（可用LocalContext.current替代）。

3. 正确理解 "重组的可中断性"

问题：Compose 可能在重组过程中中断并启动新重组，若副作用依赖 "中间状态"，可能导致异常。
解决方案：
- 确保@Composable函数是 "纯函数"：无副作用、输入相同则输出相同；
- 避免在 Composable 中修改状态（如count.value++应放在onClick等回调中）。

五、总结

Compose 的生命周期本质是 "组合树随状态变化的动态过程"，核心是 "初始组合→重组→退出组合" 的循环。与传统 View 相比，它更简洁（无需手动管理 UI 更新），但也要求开发者转变思维 ------ 从 "命令式控制 UI" 转向 "声明式维护状态"。

掌握LaunchedEffect/DisposableEffect等生命周期感知工具，结合 "避免过度重组""防止内存泄漏" 的最佳实践，才能真正发挥 Compose 的性能优势，写出高效、稳定的声明式 UI 代码。