一、

Jetpack Compose 作为 Android 现代 UI 工具包，其声明式编程范式明显改变了 Android UI 开发方式。与传统的 View 程序不同。Compose 通过重组机制来响应状态变化，自动更新 UI。只是“重组是高效的，但如果用得不对，它也可能成为性能瓶颈”。其实，

使用者痛点：

• 从界面卡顿来看。频繁触发 recomposition 导致帧率下降。
• 列表滑动不流畅：LazyColumn/RecyclerView 的项在状态变更时被过度重建。
• 不必要的频繁重组：同一个 Composable 被多次无意义执行。

要解决这些问题。仅靠表面调整远远不够——必须 Compose 的底层运行方式，并在代码层面做出精准调整。

二、Compose 重组原理

什么是重组

在 Compose 中。UI 是状态的函数：

UI = f

当状态发生变化时Compose 会重新执行与之相关的 Composable 函数，生成新的 UI 描述，这个过程就是重组。

三阶段流程

1. 组合: 执行 Composable 函数，生成 UI 描述树。
2. 布局: 测量和摆放 UI 元素。
3. 绘制: 将 UI 绘制到 Canvas 上。按理说，

当状态变化触发重组时Compose 会智能地只执行必要的阶段。如果布局和尺寸未变，则跳过布局和绘制阶段——这是 Compose 性能优势的主要。怎么说呢，

SLOT TABLE 与状态追踪

• SLOT TABLE 是线性表结构。用于存储 Composable 执行期间产生的数据，如 State 对象、位置信息、组合键等。老实说，
• Kotlin 编译器为每个 @Composable 注解插入跟踪代码。记录哪些状态被读取，一旦这些状态发生变化，Compose 就能精确知道哪些 Composable 需要重新执行。

// 编译前
@Composable
fun Greeting {
Text
}
// 编译后
@Composable
fun Greeting {
updateScope {
Text
}
}

三、重组作用域与跳过机制

函数级别重组边界

Create a small composable boundary so only readers of a state get recomposed.

@Composable
fun Parent {
var state by remember { mutableStateOf }
ChildA // state 改变时会重组
ChildB // 不读取 state。不会被影响
}

稳定类型 vs 不稳定类型

稳定类型

• Lambdas
• @Stable 或 @Immutable 标注的自定义类

不稳定类型

• 类型
• ,
• 字段存在的不标注类

: 当参数为不稳定类型时编译器无法用 equals 判断是否变化，会放弃跳过重组，每次都重新执行该 Composable。这正是常见性能瓶颈来源之一！

@Stable 与 @Immutable 的正确使用示例

@Immutable
data class UserProfile(
val id: String,val name: String。val avatarUrl: String
)
@Stable
class UiState {
var isLoading by mutableStateOf
var data by mutableStateOf)
fun startLoading { isLoading = true }
}

注意：@Stable/@Immutable 是编译期承诺，而非运行时检查。滥用会导致难以追踪 bug。

四、常见性能陷阱及修复思路

① 重组范围过大 —— 状态提高过高

// ❌ 错误实践：父组件持有全局状态导致所有子项共用同一 state
@Composable
fun ItemList {
var expandedId by remember { mutableStateOf }
LazyColumn {
items { item ->
ListItem(item,expanded = expandedId == item.id。onExpand = { expandedId = it })
}
}
}

// ✅ 调整实践：将展开状态下推到子组件内部，只影响本项
@Composable
fun ItemList {
LazyColumn {
items { item ->
ListItem
}
}
}
@Composable
fun ListItem {
var expanded by remember { mutableStateOf }
// ...
}
}

原则的观点是，尽量把状态下推到最低层级，以缩小 recomposition 范围。

② 在 Composable 中创建不稳定对象

// ❌ 每次 recomposition 都创建新 List 对象 → 不稳定 → 无法跳过
@Composable
fun MyScreen {
val list = listOf
ItemList
}
// ✅ 使用 remember 缓存对象，使其保持相同引用，从而被视为 stable
@Composable
fun MyScreen {
val list = remember { listOf }
ItemList
}

③ Lambda 创建微妙问题

// ❌ 每次 recomposition 都创建新 lambda → 可读性差，也可能导致 recomposition 扩散
@Composable
fun MyScreen {
MyButton })
}
// ✅ 调整1：无参数 lambda 用 remember 缓存
@Composable
fun MyScreen {
val onClick = remember { { doSomething } }
MyButton
}
// ✅ 调整2：依赖参数时记住对应值
@Composable fun MyScreen{
val onClick=remember{{ loadData}}
MyButton}

④ derivedStateOf 的使用时机 

Avoid recomposing when derived values don't change.
// ❌ 每次 todos 列表变化都会重新计算 filter。
即使 filter 未改动
@Composable
fun TodoList{
val filteredTodos= todos.filter{it.status==filter}
LazyColumn{ /* 渲染 */ }
}
// ✅ 调整：使用 derivedStateOf 延迟计算并缓存结果
@Composable
fun TodoList{
val filteredTodos by remember{
derivedStateOf{todos.filter{it.status==filter}}
}
LazyColumn{ /* 渲染 */ }
}


五、实战调整策略 

# 合理使用 Key 以减少列表中无意义重构 
kotlin
LazyColumn {
items{item->
ItemRow
}
}
Key 的作用是帮助 Compose 在列表项增删改时复用已有 Composable，而不是全部销毁再建。没有 key 或 key 非唯一时会导致位置索引定位失效，引发大量无谓 recomposition。

# LazyColumn 性能细节拆分 
kotlin
@Composable
fun MessageList {
LazyColumn {
items{msg-> MessageItem}
}
}
private fun MessageItem{
Row(
modifier=Modifier.fillMaxWidth
.padding
){
Text
Spacer)
Text(
text=message.timestamp,color=MaterialTheme.colorScheme.onSurfaceVariant // 固定颜色值避免每次读取 Theme
)
}
}

# SideEffect 与 LaunchedEffect 正确分离 
kotlin
// ❌ 错误：每一次 recomposition 都启动协程！@Composable fun MyScreen{
coroutineScope.launch{loadData} // 每次都 new coroutine!}
// ✅ 正确：仅在生命周期内启动一次
@Composable fun MyScreen{
LaunchedEffect{ loadData }
}

# Content Receiver 避免过度 recomposition`#`**注意** `#`**避免频繁读取 Theme** `#` **建议外部缓存主题颜色** `#`**只在需要渲染部分读取** `#` **减轻渲染负担**
kotlin
val surfaceColor = MaterialTheme.colorScheme.surface // 外部取一次
@SuppressLint
@OptIn
private fun OptimizedItem{
Surface{
Text
}
}


六、分析工具与方法 

# Compose Compiler Metrics

`build.gradle.kts` 示例配置：
kotlin
composeOptions {
kotlinCompilerExtensionVersion = "1.x.x"
}
tasks.withType.configureEach {
kotlinOptions.freeCompilerArgs += listOf(
"-P"。"plugin:androidx.compose.compiler.plugins.kotlin:metricsDestination=${project.buildDir.absolutePath}/compose-metrics","-P","plugin:androidx.compose.compiler.plugins.kotlin:reportsDestination=${project.buildDir.absolutePath}/compose-reports"
)
}
报告文件中可查看各个 composable 的 “skippable” 状态与 stability 分析。

# Layout Inspector


A run app> View> Tool Windows> Layout Inspector> Show Recompositions counts> select composable to see count.

The red flashing border indicates components currently being re‑composed.

The layout inspector also shows slot table and current layout hierarchy.

# 自定义 Recomposition Counter 示例
kotlin
import androidx.compose.runtime.*
@Composable
private fun TrackRecomposition{
var count by remember{mutableIntStateOf}
SideEffect{
count++;Log.d
}
}
@Composable private fun TrackedItem{
TrackRecomposition
ItemContent
}


七、与常用方法

# 调整检查清单

`\t


类别/检查项<\/th>
说明<\/th>
<\/tr>
<\/ad>


数据类型/Stability<\/b>
多用 *val*,少用 *var*;接口返回数据映射为不可变 data‑class；添加 @Immutable/@Stable 注解；避免裸 Mutable 集合。<\/td>
<\/tr>

状态提高/下推<\/b>
把 state 提高到最小层级；让子组件自己管理局部状态。<\/td>
<\/tr>

Remember Cache Non‑Primitive Params & Lambdas<\/b>
使用 *remember*/*rememberSaveable*;按理说，对于依赖参数需传入 key。<\/td>
<\/tr>

Key for Lists / Lazy Components<\/b>
始终为 items 提供唯一且稳定 key；避免默认索引定位，<\/td>
<\/tr>

derivedStateOf for High‑Freq State Changes<\/b>
包装衍生数据，使其仅在输入真正变更时才计算并触发 Recompose。\t
\/\t
\/\t
\t\t\t\t\t\t\t\t
\t\t
\t\t
`\t
\t \t \t \t \t \t \ttm\r\r\r\r\r\r\r`\r`\r`\r`\r`\r`
`。`


# 主要原则概括 📌


- 重构粒度是函数，而非完整树。拆分成小而精确的 @Composables 能显著降低重复工作。

- 状态读取决定边界——让「谁读谁写」关系尽量清晰且最小化。

- 跳过 Recompose 是最快速最安全的调整手段——让编译器有足够信息去做判断。话说回来，

- 用工具说话—开启 Compiler Metrics + Layout Inspector。让根据数据调整决策，而不是凭经验盲目调整。其实，
 




# 写在最终…，Compose 的性能调整本质上是对数据流向和 Recompose 边界精细控制. 与传统 View 程序强调「减少绘制」不同，这里主要是“让编译器能够安全地跳过冗余工作”。怎么说呢，理解并应用上述技术，可以帮助你从项目早期就规避卡顿与滑动抖动的问题。
让 Jetpack Compose 开发既优雅又高效。