Compose 的阶段和性能
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Compose 更新帧时会经历三个阶段:
- 组合:Compose 确定要显示的内容。它会运行可组合函数并构建界面树。
- 布局:Compose 确定界面树中每个元素的大小和位置。
- 绘制:Compose 实际渲染各个界面元素。
Compose 可以智能地跳过其中任何不需要的阶段。例如,假设单个图形元素在尺寸相同的两个图标之间切换。由于此元素不会更改大小,并且不会添加或移除界面树的任何元素,因此 Compose 可以跳过组合和布局阶段并重新绘制这一个元素。
不过,代码错误可能会导致 Compose 难以确定可以安全跳过哪些阶段,在这种情况下,Compose 会运行所有三个阶段,这可能会降低界面的速度。因此,许多性能最佳实践都旨在帮助 Compose 跳过不需要的阶段。
如需了解详情,请参阅 Jetpack Compose 阶段指南。
一般原则
总体而言,您需要遵循几项可以提高性能的宽泛原则:
- 尽可能将计算移出可组合函数。
每当界面发生变化时,可能都需要重新运行可组合函数。您放置在可组合项中的任何代码都会重新执行,可能是针对动画的每一帧。将可组合项的代码限制为仅包含构建界面所需的代码。
- 尽可能延后读取状态。通过将状态读取移至可组合子项或后续阶段,您可以最大限度地减少重组或完全跳过组合阶段。为此,您可以传递 lambda 函数(而不是状态值)以适应频繁变化的状态,并在传入频繁变化的状态时优先使用基于 lambda 的修饰符。您可以在遵循最佳做法的尽可能延后读取部分中查看此方法的示例。
其他资源
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Compose phases and performance\n\nWhen Compose updates a frame, it goes through three phases:\n\n- **Composition:** Compose determines *what* to show. It runs composable functions and builds the UI tree.\n- **Layout:** Compose determines the size and placement of each element in the UI tree.\n- **Drawing:** Compose actually *renders* the individual UI elements.\n\nCompose can intelligently skip any of those phases if they aren't needed. For\nexample, suppose a single graphic element swaps between two icons of the same\nsize. Since this element isn't changing size, and no elements of the UI tree are\nbeing added or removed, Compose can skip over the composition and layout phases\nand redraw this one element.\n\nHowever, coding mistakes can make it hard for Compose to know which phases it\ncan safely skip, in which case Compose runs all three phases, which can slow\ndown your UI. So, many of the performance best practices are to help Compose\nskip the phases it doesn't need to do.\n\nFor more information, see the [Jetpack Compose Phases](/develop/ui/compose/phases) guide.\n\nGeneral principles\n------------------\n\nThere are a couple of broad principles to follow that can improve performance in\ngeneral:\n\n- **Whenever possible, move calculations out of your composable functions.** Composable functions might need to be rerun whenever the UI changes. Any code you put in the composable gets re-executed, potentially for every frame of an animation. Limit the composable's code to only what it needs to build the UI.\n- **Defer state reads for as long as possible.** By moving state reading to a child composable or a later phase, you can minimize recomposition or skip the composition phase entirely. You can do this by passing lambda functions instead of the state value for frequently changing state and by preferring lambda-based modifiers when you pass in frequently changing state. You can see an example of this technique in the [Defer reads as long as possible](/develop/ui/compose/performance/bestpractices#defer-reads) section of [Follow best practices](/develop/ui/compose/performance/bestpractices).\n\nAdditional Resources\n--------------------\n\n- **[App performance guide](/topic/performance/overview)**: Discover best practices, libraries, and tools to improve performance on Android.\n- **[Inspect Performance](/topic/performance/inspecting-overview):** Inspect app performance.\n- **[Benchmarking](/topic/performance/benchmarking/benchmarking-overview):** Benchmark app performance.\n- **[App startup](/topic/performance/appstartup/analysis-optimization):** Optimize app startup.\n- **[Baseline profiles](/baseline-profiles):** Understand baseline profiles."]]