XML老项目迁移到Compose 2.0：性能提升、踩坑记录与分批迁移路线

上个月我把一个维护了快三年的 XML 老项目，抽出两个核心页面迁到了 Compose 2.0（圈里人最近喜欢叫它 A2UI），跑通第一版时我盯着屏幕愣了几秒——代码量直接砍掉一半，之前怎么调都别扭的嵌套布局让我顺手删了三层。

先说清楚：标题里那个 A2UI 不是什么官方名词，是 Android 社区里对“第二代 Android UI 体系”的口头叫法，落到具体技术栈上就是 Jetpack Compose 2.x。它来得很急，Android Studio 现在新建项目默认勾选 Compose 模板，新系统的一堆特性适配也明显优先落在 Compose 这边。写这篇文章不是劝你今晚就把 XML 全删了，而是想把“为什么这次是真的要变了”“迁移路上有哪些坑”“到底值不值得动”这些问题，一次说清楚。

这篇东西适合两类人：一类是写了两三年 XML 布局、还在观望的 Android 开发者，另一类是已经在用 Compose 1.x、但没搞清楚 2.x 升级价值的团队负责人。看完之后你能得到一条完整的判断链路，而不是零散的“Compose 很爽 / XML 也能用”的站队观点。

1. 先掰清楚 A2UI 到底是谁：它不是新名词，是 Compose 的第二代

1.1 名字的出处，以及为什么总有人搜到 Docker

我在不少群里看到标题这种写法，第一反应是“又有人把 Jetpack Compose 和 Docker Compose 搞混了”。

其实这里有个真实背景：Docker 那套容器编排工具叫 Docker Compose，Google 的声明式 UI 框架叫 Jetpack Compose，两者名字撞车多年。你在搜索引擎敲“compose”，大概率先蹦出来一堆“docker compose 安装”“docker compose up -d 报错”的帖子。这也是很多 Android 新人第一次搜 Compose 时最懵的事。

那 A2UI 从哪来？我看到的说法是，Google 在 2025 年 I/O 大会上把 Compose 定位成 Android 的默认 UI 体系，Android Studio 的新版模板里，Empty Activity 已经默认勾选 Compose。社区里有人调侃“Android 的 UI 终于进入第二代”，缩写一下就成了 A2UI。说白了，它不是一个官方产品代号，而是“Android UI 2.0 时代”的简称，核心就是 Jetpack Compose 2.x。

为什么强调“2.x”？因为 Compose 1.x 已经发布了好几年，很多团队试过、也退回 XML 过。真正让“换框架”从冲动变成理性的，是 2.x 这一波把性能和互操作补上了。

1.2 Compose 2.0 相比 1.x，真正升级了什么

如果你还停留在“Compose 就是写 Kotlin 代替 XML”的认知，那这篇文章你得往后看。Compose 2.x 的升级，我挑四个实际影响最大的点说。

强跳过重组（Strong Skipping）。这是 2.0 里最实在的改进。Compose 1.x 里如果组件参数没变，靠的是编译器生成的跳过逻辑；但 lambda 传参这种写法经常导致跳过失效，引发不必要的重组。2.0 改了规则——稳定参数相同、lambda 捕获值相同时，直接跳过重组。我自己那个项目的购物页，重构前滑动时列表反复重组，换成 2.0 后帧率从 45 稳定到 60，这个体感差别非常明显。

共享元素动画转正。Compose 1.x 里做跨页面共享元素动画很折腾，要么用第三方库，要么自己管理过渡状态。2.x 把 SharedTransitionLayout 做成了稳定 API，写起来简单很多。这对列表进详情的场景是刚需，至少省了我两天工作量。

性能和布局工具链补齐。2.x 的布局 inspector、recomposition 计数、强跳过分析工具，基本做到了和 XML 时代 Hierarchy Viewer 同级的可视度。1.x 时代“性能问题像黑盒”的痛点，现在算是有了解药。

WindowInsets 和 Material 组件重构。折叠屏、大屏、全面屏的适配变得规范了。2.x 把 insets 处理从“要自己读系统窗口”变成了声明式 API，后面我讲系统适配时再展开。

1.3 一个最容易忽略的背景：新系统特性在往 Compose 倾斜

你去看 Android 15、16 的适配文档会发现一个明显的趋势：预测性返回动画、动态主题取色、Edge-to-edge 强制适配，这些新特性要么只在 Compose 里有高层 API，要么用 View 体系实现时补丁叠补丁。

我举一个实际的：Android 12 以后，Material You 动态取色在 View 体系里要靠dynamicColors()或者手动读系统颜色资源，而 Compose 里是dynamicLightColorScheme()一行事。到了 Android 15 的 16KB 页大小适配，以及后续 16 的分屏尺寸变化，View 体系的适配文档越来越长。这不代表 XML 明天就死，但“新玩法都在 Compose 先落地”这个信号，已经足够说明问题了。

2. XML 不是不能写，而是它欠下的账开始集中到期

2.1 重复劳动：“布局税”和“模板代码”是两笔大开销

我在社区见过一个很有意思的提问节奏：隔三差五就有人搜“xml 文件怎么打开和编辑”“xml 格式文件没有标签怎么办”——这种问题在 UI 开发语境里，指的就是 XML 布局文件。

为什么 XML 包装了这么多年，至今还有人在基础上犯难？因为 XML 本身就不是给人高效手写的。一个复杂页面动辄几百行，层级嵌套五六层是常态。你在 IDE 里拖拽生成布局，生成出来的代码通常有大量冗余；手写又得自己维护ConstraintLayout的app:layout_constraint一堆约束。我见过一个 banner + 列表的页面，布局 XML 730 行，运行时还需要include三个子布局。

这还没算控件访问的模板代码。老项目里findViewById一把梭，后来升级 ViewBinding，每次加一个控件、改一个 id，对应 Binding 类自动生成还好；但 XML 里稍微调整结构，牵一发动全身。DataBinding 虽然能缓解一部分，但 DataBinding 的表达式调试起来等于给项目加了另一种心智负担。

这笔账我称为“布局税”：你每写一个 XML 页面，就要交一次层级规划税、约束管理税、控件查找税。单一页面还好，几十个页面叠下来，维护成本是指数级的。

2.2 系统适配清单越长，View 体系越力不从心

手机上动辄 4GB 内存还说得过去，关键是新形态设备越来越多：折叠屏、大屏平板、车载横屏、Android TV 的 D-pad 焦点。这些场景对 UI 框架的要求已经远超“画几个 box 拼在一起”。

举三个我在项目里实际碰到的：

大屏和可折叠尺寸。XML 时代适配折叠屏，最常见的做法是res/values-large或res/values-sw600dp资源目录，写两套布局。两套布局意味着两倍维护量，而且折叠状态切换时 Activity 重建，状态经常丢。Compose 里通过 WindowSizeClass 拿到当前尺寸类，一套代码响应式变化，不需要维护两份布局。

预测性返回动画。系统返回时，页面要跟着手势做缩放/位移过渡。View 体系下要自己接管OnBackInvokedCallback配合动画，处理手势进度和动画同步，很容易出 bug。Compose 2.x 里predictiveBackHandler加上共享元素，几十行搞定。

Android TV 的焦点处理。一直用 XML 的团队做 TV 版，焦点移动全靠android:nextFocusUp/Down这种属性在 XML 里标。焦点顺序一变，改起来就是全局搜索。Compose 用Modifier.onFocusChanged()和焦点请求 API，逻辑写在代码里，可读性和可调性都强。

当然，你可能会说你做的是一个普通手机 App，不碰这些。那也得面对 Android 12 之后的动态取色和深色模式。深色模式在 XML 里靠values-night资源切，资源文件一多，漏适配是常事。Compose 的主题是运行时状态，isSystemInDarkTheme()拿到直接做条件分支，代码里逻辑更集中。

2.3 更尴尬的是人：新人不愿学，老人不敢动

还有一个被很多技术文章忽略的信号——人才结构。

现在校招和实习简历里写“熟悉 XML 布局”的比例在明显下降，写“了解 Jetpack Compose”的比例在上升。新人不愿意把时间砸在一个“随时可能被替代”的旧体系上；老手则被两年的历史包袱拖着，想动又怕踩坑。

这种结构性错位造成一个很现实的问题：你团队如果继续 XML 一套吃到底，招人难度只会越来越高。我用一个朋友公司的真实情况说明：去年他们想招一个能做 TV 端定制焦点的中级开发，面了七八个，两个只写 XML 却又说不出焦点管理技巧，三个表示愿意学 Compose；最后录用的是一个能同时写 View 和 Compose 互操作的选手。市场已经在用脚投票了。

3. 迁移 Compose 之前，必须翻过三座山：状态、重组和互操作

3.1 状态驱动 UI：从“找控件改控件”到“改数据等界面自己变”

很多 XML 开发者第一次写 Compose 时最不习惯的就是：没有控件引用了，没有findViewById了，我的界面怎么改？

我常用一个装修类比来帮人理解：XML 时代你是一个拿着图纸指挥施工队的包工头，想换块地砖，得先找到负责的工人（控件），告诉他位置、材质、规格；Compose 里你是个给设计师看效果图的甲方，只需要说“地砖换成浅色”，整张效果图自动重新画。

代码上说，核心就是mutableStateOf加重组。

@Composable fun DownloadProgress(count: Int, max: Int = 100) { val progress = remember(count, max) { count.coerceIn(0, max) } Text(text = "下载中：$progress%", modifier = Modifier.fillMaxWidth()) LinearProgressIndicator(progress = { progress / max.toFloat() }) }

当count这个状态改变时，Compose 会重新执行组件函数，界面随之更新。你不需要手动调用textView.text = "下载中：xxx"，也不需要担心忘记更新进度条。

这种“状态到 UI”的单向映射，最直接的好处就是少了一大批 bug 来源。XML 时代最常见的崩溃之一就是控件状态和业务状态不同步——你改了数据忘了刷界面，或者刷了界面但有两个控件引用同一个字段，字段一变忘了一个。Compose 里状态是唯一数据源，界面是它的投影，投影永远跟着状态走。

3.2 重组不是 DOM：别把 View 时代的坏习惯带到 Compose

这里容易踩一个坑，我把它当作第二座山来说。很多人以为重组就是“整个页面重新执行一遍”，然后开始用各种办法避免重组，最后代码越改越糊涂。

实际上 Compose 的重组和浏览器里的 DOM diff 不是一回事。它是在编译期标记依赖状态，运行时只重组真正受影响的那一小块代码。你要做的不是“避免重组”，而是“让重组范围最小、可预测”。

举一个反面例子：我早期项目里写过一个页面，每秒钟刷新一个倒计时文本，但整个页面都放在同一个@Composable函数里。

@Composable fun CountdownScreen() { var seconds by remember { mutableStateOf(60) } LaunchedEffect(Unit) { while (seconds > 0) { delay(1000) seconds-- } } // 下面这行如果用老思维，会觉得整个页面都要跟着动 HomeHeader() OrderList() Text("剩余 $seconds 秒") }

其实只要把不断变化的部分抽成独立组件，让seconds只在它里面读取，重组的范围就缩小到那一个Text：

@Composable fun CountdownText(state: State<Int>) { Text("剩余 ${state.value} 秒") }

这是 Compose 性能和心智的核心：状态读得越内层，重组面越小。很多人说“Compose 性能不行”，八成是栽在这个点上。

3.3 老项目互操作：ComposeView 和 AndroidView 是双向门

第三座山是互操作。我见过最多的问题就是“我项目里几十个 Activity 全是 XML，怎么开始用 Compose”。

答案是：不用推翻。View 和 Compose 可以在同一个 Activity 里共存，ComposeView 可以嵌进 XML，AndroidView 可以把旧 View 包进 Compose。

我一般推荐从页面内嵌开始，最小改造。举个例子，你想在旧 Fragment 里加一段 Compose 实现的内容：

class LegacyFragment : Fragment() { override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View = ComposeView(requireContext()).apply { setViewCompositionStrategy( ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed ) setContent { MaterialTheme { OrderSummaryPanel() } } } }

反过来，如果 Compose 页面里需要一个很成熟的第三方 View 控件（比如地图、自定义画板），用AndroidView包一层：

@Composable fun MapWidgetView(attribution: String) { AndroidView( factory = { context -> LegacyMapView(context).apply { setAttributionText(attribution) } }, update = { view -> view.refreshMarker() } ) }

互操作坑在哪？一个是生命周期策略，setViewCompositionStrategy不配好，页面销毁时 Compose 还在重组，容易崩；另一个是 View 特有的onTouch事件和 Compose 手势冲突，这类问题我在第五部分细说。

4. 分批迁移的实操路线：先吃低风险页面，再啃硬骨头

4.1 第一步：给现有页面排个迁移优先级

别一上来就迁首页。首页通常是整个 App 里控件最杂、状态最多、交互最频繁的页面，拿它练手等于给自己上强度。我的经验是把页面按三个维度打分：业务复杂度、UI 复杂度、历史包袱（有没有老的自定义控件）。

我实际迁的第一个页面是订单详情页。它没有复杂手势、没有第三方自定义控件，逻辑就是状态展示 + 几个按钮，非常适合第一次试水。迁完之后拿它当基准，在 Layout Inspector 里对比重组次数和帧率，心里有底了再动第二个。

4.2 第二步：在一个页面里混合，不追求一步到位

一个页面如果足够大，也可以混合。比如保留 XML 写好的头部 Banner（因为用了开源库自动轮播），中间列表改用 LazyColumn 重写。混用期最长不要超过一个迭代，否则代码库会同时存在两套风格，维护比全迁还痛苦。

关键做法是给这个页面定一个新的 Fragment，用ComposeView承接 Compose 部分，XML 部分保留原来的 FragmentView；两者通过共享 ViewModel 通信。这样即使 Compose 部分出问题，也可以方便地 revert 回 XML 版本。

4.3 第三步：新页面全 Compose，老页面按迭代逐步替换

迁移最忌讳的是“全有或全无”。我给团队定的策略是：新需求一律用 Compose，老页面只在有业务改动时顺手迁。这样每条业务需求都带一点迁移量，三个月下来，新代码基本全是 Compose，老代码慢慢萎缩。

还要配一条质量红线：迁移后的页面，帧率不能低于旧版本，冷启动耗时增加不能超过 5%，核心操作路径的崩溃率不能上升。没有这些指标，“迁移完成”永远是一句空话。

4.4 项目管理上容易忽略的一件事：把 Compose 成熟度做成团队技能表

如果你的团队不止一个人，迁移前最好先统一状态管理方案。Compose 本身不强制你用哪种状态架构——你可以直接用remember，也可以上 ViewModel + StateFlow。但团队必须选一个标准。

我们最终选了 ViewModel +MutableStateFlow的方式，理由很直接：和现有架构一致，老页面迁过来时 ViewModel 不用重写，只把 UI 层换成 Compose。如果你一上来就引入第三方状态库，学习成本和冲突成本都会翻倍。

5. 迁移路上我踩过的坑：性能、预览、兼容性三连

5.1 预览和真机不一致：主题、字体缩放、WindowInsets

第一个坑发生在 IDE 预览阶段。我迁完订单详情页后，在 Android Studio 的 Compose Preview 里看效果很完美，一上真机却发现顶部状态栏区域和底栏区域全乱了。

原因是我在预览里没有配置模拟设备的主题参数，真机用的是 Material 3 动态主题，正好触发了 WindowInsets 不同。Compose 2.x 要求你显式处理 insets，不然内容会被系统状态栏遮住。

解法很简单：在预览注解里把主题和字体参数配上，或者在根布局上用.statusBarsPadding()和.navigationBarsPadding()做统一收敛。记住一点：真机永远比预览早一步暴露 insets 问题，所以别依赖预览做最终验收。

5.2 重组风暴：一段日志定位卡顿

第二个坑，也是性能上最典型的：列表页滑动掉帧。一开始我以为是 LazyColumn 性能问题，查了半天发现是某次的列表 item 里传了一个很大的对象，导致 item 整体重组频繁。

我在代码里临时加了一个组合项的重组计数：

@Composable fun ListItem(item: Item, modifier: Modifier = Modifier) { val current = 0 // 临时调试用 LaunchedEffect(item.id) { snapshotFlow { item } .collect { Log.d("Rebuild", "item=${item.id}, state=$it") } } // 实际 UI 内容 OrderCard(item, modifier) }

跑完一轮观察日志，发现明显是在滑动过程中item这个不可变数据结构里的某个字段被反复赋值。改成稳定的 key 和只读数据类之后，重组次数降了一个数量级。

这里可以给一个通用经验：数据类字段如果会在运行期变化，优先用Immutable标注或者 Kotlin 的val保证引用稳定；如果列表 item 需要根据状态变化，把变化值抽到 item 内部读取，而不是把整个列表数据传进去。

5.3 第三方 View 混用：手势冲突与生命周期

我迁项目时最痛的一个页面，是一个带有横向滑屏删操作的历史记录页。它内部还有一个老的自定义 SwipeLayout View。在 Compose 里用 AndroidView 包住它以后，手势冲突就来了：Compose 的Modifier.draggable会先拦截事件，老 View 的 onTouch 拿不到完整事件流。

排查过程是这样的：先用 Layout Inspector 确认事件流向，发现 Compose 的 drag 分支和原生 SwipeLayout 的滑动判断都认为自己在处理同一个 DOWN 事件，导致 SwipeLayout 经常只响应一半滑动。

解法分两步：对外层 Compose 容器禁用 Compose 手势拦截，让事件先给 AndroidView 消费；对内给 SwipeLayout 加一个触摸代理，把事件分发给 Compose 和 View 双方。这种场景下，直接“全用 Compose 重写”成本太高，而混用时必须明确手势事件的主人是谁。

5.4 无障碍和自动化测试兼容

还有一个容易忽视的点：无障碍服务。Compose 的语义系统比 View 体系更抽象，TalkBack 读屏时需要你在组件上补充contentDescription语义。不少从 XML 迁过来的页面，看着没问题，一开读屏就全乱了。我的建议是在迁移验收标准里把无障碍检查列为必选项，用系统自带的 TalkBack 跑一遍核心路径，不指望自动检测工具。

自动化测试也一样：UI Automator 的控件定位在 Compose 里要使用测试标签testTagsAsResourceId来保证 id 稳定性。早期迁移时被这个坑过，UI 测试跑着跑着就找不到节点，后来规范成每个可测组件必须显式加Modifier.testTag("xxx")，才把自动化回归拉回正轨。

6. 迁移之后的真实感受：哪些项目值得动，哪些按兵不动

跑完两个页面的迁移，经历了预览翻车、重组风暴、手势冲突和大大小小七八个坑之后，我的最终看法是这样的。

如果你的项目是以下三种情况之一，我建议你尽早动：

• 还要活三年以上的长期项目。系统新特性不断往 Compose 倾斜，再拿 XML 撑三年，后面要付的迁移债只会更多。
• 团队有新成员要培养。新人学 Compose 的意愿和速度都远高于 XML，继续守着旧体系会加速团队技术断层。
• 页面状态复杂、交互密集的产品。状态驱动 UI 在购物车、表单、实时刷新这类场景里，开发和维护成本降低得非常明显。

如果你的项目是以下情况，暂时不动也合理：

• 纯维护型、几乎没有新需求的小工具，XML 已经稳定运行多年。
• 重度依赖多个第三方自定义 View，且这些库没有 Compose 版本。
• 团队没有时间和资源做迁移演练，硬迁只会增加线上风险。

我自己的判断标准其实很简单：看未来一年这个项目会不会有超过三个页面的改动。如果有，Compose 就是值得现在开始还的债；如果没有，继续用 XML 也不是不可以，但别再说“XML 永远够用”这种话。平台的风向已经变了，作为 Android 开发者，手里多一套方案总比守着老船票强。

最后分享一个实际体会：迁移 Compose 后，我最明显的感受不是“代码量变少”，而是“改 UI 时终于敢翻动代码了”。以前 XML 堆出来的复杂布局，改起来像拆炸弹，现在状态和 UI 边界清晰了，改一个字段、加一个分支都心里有底。这种感觉，才是迁移最大的红利。