Jetpack Compose on zed的博客

Jetpack Compose 渲染性能：Modifier、graphicsLayer 与重组边界

Fri, 02 Jan 2026 21:30:00 +0800

在开发云游戏客户端的虚拟手柄功能时，我们需要处理高频触摸事件和复杂 UI 动画。这个场景很适合用来理解 Compose 性能：哪些变化会触发布局，哪些变化只影响绘制，哪些状态读取会扩大重组范围。

核心结论

Modifier 是按顺序包裹的，顺序会影响布局、点击和绘制。
布局阶段变化通常更贵，能放到绘制或合成阶段的动画尽量下沉。
graphicsLayer 适合把平移、缩放、透明度等变换交给 GPU 合成。
alpha 可能引入离屏缓冲，要关注裁剪和额外合成成本。
高频状态要隔离重组范围，不要让整棵 UI 跟着刷新。

1. Modifier 的「洋葱模型」

很多初学者容易被 Modifier 的链式调用顺序搞晕。记住一个核心原则：Modifier 是从外向内包裹的「洋葱」。

考虑以下代码：

Box(
 modifier = Modifier
 .size(100.dp)
 .background(Color.Red)
 .padding(10.dp)
 .background(Color.Blue)
)

Compose 并不是简单地按顺序执行属性设置，而是构建了一层层的 LayoutNodeWrapper：

最外层：size(100.dp) 限制了整个节点的大小。
第二层：background(Color.Red) 在 100x100 的范围内画红底。
第三层：padding(10.dp) 将内部的内容向内挤压，现在的可用空间变成了 80x80。
最内层：background(Color.Blue) 只在剩下的 80x80 范围内画蓝底。
核心：Box 的内容。

为什么点击区域会错位？

理解了这个模型，就能解释我在开发虚拟摇杆时遇到的一个诡异 Bug：“点击区域没有跟随滑块移动”。

错误代码：

// 错误示范
JoystickKnob(
 modifier = Modifier
 .clickable { /*...*/ } // 先设置点击
 .offset(x = 10.dp) // 再移动位置
)

在这个"洋葱"中，外层是 clickable，内层是 offset。

clickable 节点拿到了原始位置，它不知道内部的内容被 offset 移走了。
offset 仅仅移动了绘制内容（和布局坐标），但外层的点击检测区域还在原地。

修正：

// 正确示范
JoystickKnob(
 modifier = Modifier
 .offset(x = 10.dp) // 先移动
 .clickable { /*...*/ } // 再在外层设置点击
)

现在，offset 成了外层，它带着内部的 clickable 区域一起移动了。

2. Alpha 与离屏缓冲

当虚拟摇杆划出底座范围时，我希望它变半透明，于是加了 Modifier.alpha(0.5f)。结果发现：超出底座的部分直接被切掉了！

根因分析

Modifier.alpha 并不仅仅是改变绘制透明度。为了实现半透明混合，它会强制开启一个 离屏缓冲 (Off-screen Buffer / Layer)。

这个 Layer 的大小默认等于组件的大小。
Layer 自带物理边界（Clipping）。
当摇杆（内容）通过 offset 移出这个 Layer 的边界时，超出部分自然就被裁切了。

优化对策

对于只是想改变颜色透明度，且内容可能会溢出容器的场景，要谨慎使用 Modifier.alpha。

请直接操作颜色的 Alpha 通道：

// 性能更好，且不会裁切
Box(modifier = Modifier.background(Color.Red.copy(alpha = 0.5f)))

这直接在当前 Canvas 上绘制半透明颜色，不需要分配额外的 Buffer，既省内存又解决了 Bug。

3. 布局阶段 vs 绘制阶段

虚拟摇杆的位置更新频率极高（60fps+）。如果我们使用 Modifier.offset 来移动摇杆：

Modifier.offset(x = state.x.dp, y = state.y.dp)

这里有一个隐患：offset 会改变组件的 Layout 参数，不仅触发 Draw (绘制) 阶段，还会触发 Placement (布局) 阶段。虽然 Compose 做了优化不会触发 Measure，但在高频场景下，Layout 开销依然可观。

使用 graphicsLayer 降低布局压力

更优的方案是使用 Modifier.graphicsLayer：

Modifier.graphicsLayer {
 translationX = state.x
 translationY = state.y
}

跳过 Layout：graphicsLayer 只改变绘制阶段的变换矩阵（Matrix），完全跳过 Measure 和 Layout 阶段。
GPU 加速：这些变换直接在 GPU 上执行，效率极高。

这也解释了为什么在 Compose 动画中，优先推荐使用 graphicsLayer 属性，而不是修改 Layout 参数。

4. 重组边界隔离 (Provider Pattern)

全局状态（如 GameUiState）的变化很容易导致大面积的 Recomposition (重组)。

例如：

@Composable
fun GameScreen(state: GameUiState) {
 // 每次 state 变化，GameScreen 整体重组
 Header(state.userInfo)
 Body(state.streamInfo)
}

即使只有 streamInfo 变了，Header 也会因为父组件重组而被牵连（除非它加了 skips 优化）。

为了极致优化，我们可以引入 Lambda Provider 模式：

@Composable
fun GameScreen(stateProvider: () -> GameUiState) {
 // GameScreen 只持有一个 lambda 引用，永远不会变 -> 跳过重组
 Header { stateProvider().userInfo }
 Body { stateProvider().streamInfo }
}

父组件只接收一个稳定的 Lambda 对象。
取值操作被推迟到了子组件内部真正需要数据的那一刻。
结果：状态变化时，只有真正用到该状态的最底层子组件才会重组，父组件稳如泰山。

总结

Compose 的性能优化往往隐藏在细节中：

理解 Modifier 顺序：外层决定内层的命运。
避免无谓的 Layer：慎用 Modifier.alpha，善用 Color.alpha。
避重就轻：高频动画用 graphicsLayer 跳过 Layout 阶段。
延迟读取：用 Lambda 推迟状态读取，通过「重组隔断」缩小刷新范围。

Jetpack Compose 入门：声明式 UI、State 与重组

Sat, 25 Oct 2025 19:52:44 +0800

Compose 不是把 XML 换成 Kotlin，而是把 UI 从“命令式更新 View”换成“状态驱动界面”。理解 State 和重组之后，Compose 的很多 API 才会变得顺。

核心结论

Composable 函数描述某个状态下 UI 应该长什么样。
State 变化会触发读取它的 Composable 重组。
remember 负责在重组之间保存对象。
状态应该尽量上提，让无状态 Composable 更容易复用和测试。
重组不是重建整个屏幕，Compose 会尽量跳过输入未变化的部分。

声明式 UI

传统 View 更像这样：

textView.text = user.name
button.isEnabled = user.isValid

Compose 更像这样：

@Composable
fun UserCard(user: User) {
 Text(text = user.name)
 Button(enabled = user.isValid, onClick = {}) {
 Text("Submit")
 }
}

你不再手动寻找某个 View 并修改它，而是声明：在当前状态下，UI 应该是什么样。

组合与重组

组合是第一次执行 Composable，生成 UI 树。

重组是状态变化后，Compose 再次执行受影响的 Composable，让 UI 和新状态保持一致。

关键点：

重组可能频繁发生；
Composable 应该保持轻量；
不要在 Composable 函数体里直接执行不可控副作用；
可以被重复调用的代码才适合放在 Composable 里。

State 和 remember

State 的作用是通知 Compose：值变了，需要更新 UI。

@Composable
fun Counter() {
 var count by remember { mutableStateOf(0) }

 Button(onClick = { count++ }) {
 Text("count = $count")
 }
}

这里有两个角色：

remember：让 count 在多次重组之间保留下来；
mutableStateOf：让 count 变化时触发重组。

如果没有 remember，每次重组都会重新创建状态。

状态提升

当一个 Composable 同时负责保存状态和展示 UI 时，它会比较难复用。

更推荐拆成：

@Composable
fun CounterScreen() {
 var count by remember { mutableStateOf(0) }
 CounterContent(
 count = count,
 onIncrease = { count++ }
 )
}

@Composable
fun CounterContent(
 count: Int,
 onIncrease: () -> Unit,
) {
 Button(onClick = onIncrease) {
 Text("count = $count")
 }
}

CounterScreen 管状态，CounterContent 只负责展示和发事件。

重组触发

重组常见来源：

Composable 读取的 State 发生变化；
父 Composable 重组，并传入了新参数；
Flow/LiveData 被转换成 Compose State 后发出新值。

典型链路：

ViewModel StateFlow 发出新值
 -> collectAsStateWithLifecycle()
 -> Compose State 更新
 -> 读取该 State 的 Composable 重组
 -> 子 Composable 根据参数变化决定是否重组

智能跳过

Compose 会尝试跳过输入没有变化的 Composable。

更容易被跳过的参数：

基本类型；
String；
稳定的函数引用；
@Stable / @Immutable 类型；
Compose 内置稳定类型。

需要避免：

每次重组都创建新的复杂对象；
在参数里传不稳定集合；
把过大的状态对象直接传到很深层级。

回看清单

Compose 用状态描述 UI，而不是手动更新 View。
remember 保存对象，State 触发重组。
状态尽量上提，UI 组件尽量无状态。
副作用用 LaunchedEffect、DisposableEffect 等 API 管理。
性能问题先判断是重组、布局还是绘制阶段。

Compose Navigation 入门：路由、NavHost 与模块化导航

Sat, 25 Oct 2025 16:01:56 +0800

Compose Navigation 的重点不是“怎么跳页面”，而是如何把页面地址、返回栈、参数和模块边界组织清楚。页面少时可以直接写在一个 NavHost 里，页面多时就需要模块化导航。

核心结论

NavController 负责执行导航和维护返回栈。
NavHost 承载导航图，把 route 映射到 Composable。
route 是页面地址，建议统一封装，不要散落字符串。
feature 模块可以通过扩展函数向主导航图注册自己的页面。
复杂页面参数要谨慎传递，优先传 ID，再由目标页加载数据。

核心组件

组件	职责
`NavController`	导航控制器，负责 `navigate()`、`popBackStack()` 和返回栈
`NavHost`	导航容器，根据当前 route 显示目标 Composable
`NavGraph`	导航图，描述页面和页面之间的关系
`Route`	目标页面地址

基础结构：

@Composable
fun AppNavHost(
 navController: NavHostController = rememberNavController(),
) {
 NavHost(
 navController = navController,
 startDestination = "home",
 ) {
 composable("home") {
 HomeScreen(
 onOpenDetail = { id ->
 navController.navigate("detail/$id")
 }
 )
 }

 composable("detail/{id}") { backStackEntry ->
 val id = backStackEntry.arguments?.getString("id")
 DetailScreen(id = id)
 }
 }
}

路由封装

不要在项目里到处写字符串 route。更稳的方式是集中定义：

object HomeRoute {
 const val route = "home"
}

object DetailRoute {
 const val route = "detail/{id}"

 fun create(id: String): String = "detail/$id"
}

使用：

navController.navigate(DetailRoute.create(id))

如果项目使用 Navigation 的类型安全路由能力，也可以用序列化对象表达 route：

@Serializable
data object ForYouRoute

模块化导航

大型项目里，主导航图不应该知道每个 feature 内部的页面细节。可以让 feature 暴露一个注册函数：

fun NavGraphBuilder.forYouSection(
 onTopicClick: (String) -> Unit,
) {
 navigation(
 startDestination = "for-you/feed",
 route = "for-you",
 ) {
 composable("for-you/feed") {
 ForYouScreen(onTopicClick = onTopicClick)
 }
 }
}

主工程只负责装配：

NavHost(
 navController = navController,
 startDestination = "for-you",
) {
 forYouSection(
 onTopicClick = { id ->
 navController.navigate("topic/$id")
 }
 )
}

这样 feature 可以维护自己的子图，主导航只处理跨模块跳转。

参数传递原则

返回栈

常用操作：

navController.navigate("detail/$id")
navController.popBackStack()

底部 Tab 场景通常需要：

保存每个 Tab 的状态；
避免重复创建同一个目的地；
回到根目的地时恢复状态。

示例思路：

navController.navigate(tab.route) {
 popUpTo(navController.graph.startDestinationId) {
 saveState = true
 }
 launchSingleTop = true
 restoreState = true
}

回看清单

NavController 管行为，NavHost 管展示，route 管地址。
route 不要散落字符串，最好集中封装。
feature 模块通过 NavGraphBuilder 扩展函数注册自己的导航图。
页面参数优先传 ID，不传复杂对象。
底部 Tab 要关注返回栈复用和状态恢复。