1. 从 XML 到 Compose 的迁移困局

做过几年 Android 的人大概都有这种体会：打开一个五年前甚至更早的项目，满屏的findViewById、层层嵌套的LinearLayout、到处散落的setOnClickListener，改一个按钮的样式要翻三四个文件。Jetpack Compose 出来之后，大家都知道声明式 UI 是方向，但真要把一个线上跑了多年的老项目迁过去，心里是发怵的。不是不想迁，是迁移这件事本身太"烧心"了——工作量不可控、回归测试成本高、团队里有人熟有人不熟，稍不留神就是一个迭代周期搭进去还落一堆 bug。

Meta 的 Android 团队前阵子分享了他们在大规模 Compose 迁移上的实践思路，核心不是"人肉重写"，而是把 AI 当成迁移流水线里的一个环节来用。这个思路我觉得挺值得聊的，因为它解决的不是"Compose 怎么写"这种入门问题，而是"存量代码怎么低成本、可控地转过去"这种真正卡住团队的问题。这篇文章我会把整套方法论拆开讲：AI 在迁移里到底承担什么角色、哪些环节适合交给它、哪些必须人来兜底、具体怎么落地、踩过哪些坑。适合手里有存量 Android 项目、正在评估或已经启动 Compose 迁移的开发和团队负责人看，也适合想搞清楚"AI 辅助重构"边界在哪的人。

先说结论：AI 不是用来一键把整个项目转成 Compose 的，那是幻想。它真正有价值的地方，是在有明确约束、有验证手段、有回退机制的前提下，批量处理那些机械但繁琐的转换工作，把人的精力释放到架构决策和边界处理上。理解这一点，后面所有内容就顺了。

2. 迁移整体设计与 AI 的介入位置

2.1 为什么不能"一把梭"全量重写

很多团队一开始的想法很朴素：既然 Compose 好，那就新开一个模块，把老页面一个个重写。听起来干净，实际做起来问题一堆。老项目的 UI 逻辑往往和业务逻辑、状态管理、数据绑定缠在一起，一个列表页背后可能挂着 Presenter、Adapter、DiffUtil、自定义 View、动画、埋点，你重写 UI 层，等于把这些依赖全部重新梳理一遍。工作量不是"写 UI"的量级，是"重做半个页面"的量级。

更现实的问题是回归风险。老代码虽然丑，但它是经过线上验证的，边界情况都趟过了。重写意味着这些隐性知识全部丢失，你得靠测试和灰度一点点找回来。所以 Meta 的思路不是"重写"，而是渐进式迁移：以页面或组件为单位，逐个替换，每一步都可验证、可回退。AI 的价值就体现在这个"逐个替换"的过程里——它能把重复度极高的转换动作批量化，让单个页面的迁移成本降下来。

2.2 AI 在流水线里到底干什么

把 AI 放进迁移流程，得先想清楚它的能力边界。我的经验是，AI 擅长的是模式识别 + 模板化改写，不擅长的是跨文件的状态推理和架构判断。基于这个判断，迁移流水线可以拆成这么几段：

• 识别与分类：扫描存量代码，把 UI 组件按复杂度分级——纯展示型、带状态型、带复杂交互型。这一步 AI 可以辅助打标，但分级标准得人来定。
• 机械转换：把 XML 布局、简单的 View 组合、数据绑定表达式，按既定规则转成 Compose 代码。这是 AI 的主战场。
• 人工兜底：复杂状态管理、自定义绘制、动画、跨组件通信，这些交给 AI 容易出隐性错误，必须人工介入。
• 验证与回归：截图对比、UI 测试、灰度发布，确保转换前后行为一致。

这个分工的关键在于：AI 处理的是"有标准答案"的部分，人处理的是"需要判断"的部分。把这两者混在一起，要么 AI 干不好，要么人累死。

2.3 方案选型的几个关键取舍

在具体落地前，有几个决策点必须先定下来，否则后面会反复返工。

第一个是迁移粒度。按页面迁还是按组件迁？我的建议是先从叶子组件开始——那些不依赖其他自定义 View、纯展示的小组件。它们转换风险最低，能快速跑通流水线、积累提示词模板，给团队建立信心。等流程顺了，再往上迁页面级组件。

第二个是新旧共存策略。迁移期间必然是新旧混用，Compose 和 View 体系要能互相嵌套。ComposeView和AndroidView这两个互操作 API 是桥梁，但要注意它们的性能开销和生命周期处理，不能滥用。

第三个是验证标准。什么叫"迁移成功"？我的标准是三条：视觉一致（截图对比通过）、交互一致（关键路径 UI 测试通过）、性能不退化（首帧、滑动帧率在可接受范围）。这三条缺一不可，尤其是性能，Compose 写不好比 View 还慢。

3. 核心细节解析与实操要点

3.1 提示词工程：让 AI 输出可用的 Compose 代码

AI 迁移的质量，八成取决于提示词。随手丢一段 XML 让它转 Compose，出来的代码大概率不能用——命名随意、状态处理混乱、没有预览注解。我摸索下来，一个高质量的转换提示词应该包含这几块信息：

• 角色与约束：明确告诉它"你是一个资深 Android 工程师，把给定 XML 转成符合 Material 3 规范的 Compose 代码"。
• 项目上下文：把项目里已有的主题、颜色、字体、间距规范喂给它，让它复用而不是自己造。
• 输出规范：要求带@Preview、状态用remember/mutableStateOf、列表用LazyColumn、避免在 Composable 里做耗时操作。
• 反例说明：明确列出不要做什么，比如"不要用!!强制解包""不要在 Composable 里直接调网络"。

举个实际的提示词骨架：

你是资深 Android 工程师。将下面的 XML 布局转换为 Jetpack Compose 代码。 约束： 1. 使用 Material 3 组件，颜色引用项目主题中的 colorScheme 2. 状态用 remember + mutableStateOf 管理，不要用全局变量 3. 列表用 LazyColumn，带 key 参数 4. 每个 Composable 加 @Preview 5. 不要引入新的第三方依赖 6. 保持原有 View 的 id 语义，转成有意义的参数名 输出：仅输出 Kotlin 代码，不要解释。

这套提示词跑下来，简单组件的首次通过率能到七八成，剩下的靠人工微调。关键是约束越具体，返工越少。

3.2 状态管理的转换是重灾区

XML 时代的 UI 状态，很多是散落在 Activity、Fragment、Adapter 里的成员变量，靠手动notifyDataSetChanged刷新。转到 Compose，状态必须收敛到 Composable 内部或 ViewModel 里，用单向数据流驱动。这一步 AI 最容易出错，因为它看不到状态在多个文件间的流转。

我的做法是：状态相关的转换不交给 AI 全自动做，而是让它生成骨架，人来填状态逻辑。具体来说，让 AI 把 UI 结构转出来，把原来散落的状态变量列成一个清单，然后人工决定哪些进 ViewModel、哪些用remember本地管理、哪些用rememberSaveable做配置变更保留。这个清单本身就是迁移的检查表，很有价值。

注意：remember和rememberSaveable的区别一定要搞清楚。前者在配置变更（如旋转屏幕）时会丢失，后者会保留。列表滚动位置、输入框内容这类必须用rememberSaveable，否则用户转个屏数据就没了，这种 bug 在测试里很难稳定复现。

3.3 互操作边界的处理细节

迁移期新旧混用，ComposeView和AndroidView是必经之路。这里有几个坑我踩过：

• ComposeView嵌在 XML 里时，主题传递容易出问题。Compose 用的是MaterialTheme，XML 用的是Theme.Material3，两套主题体系要对齐，否则颜色字体对不上。解决办法是在ComposeView外层包一层ContextThemeWrapper，或者用CompositionLocalProvider手动注入主题。
• AndroidView嵌在 Compose 里时，update回调会被频繁调用，里面不要做重操作，否则滑动卡顿。而且 View 的生命周期和 Composable 的重组节奏不一致，onRelease里要做好资源释放。
• 触摸事件冲突：Compose 的手势系统和 View 的触摸分发机制不同，嵌套时容易出现滑动冲突。列表嵌套列表这种场景，能避免就避免，实在要嵌套，用NestedScrollConnection手动协调。

这些细节 AI 基本帮不上忙，得靠人对两套体系的理解。所以我在团队里推迁移时，会先花半天时间专门讲互操作，把这几条讲透，后面能省很多排查时间。

3.4 验证环节的自动化设计

迁移最怕的是"看起来对了，实际有细微差异"。人眼盯截图不靠谱，得靠自动化。我的验证流水线是三层：

第一层是截图对比。用 Paparazzi 或 Roborazzi 这类工具，在 JVM 上跑 Compose 的渲染，和迁移前的 View 截图做像素级对比。差异超过阈值就报警。这一层能抓住大部分视觉回归。

第二层是UI 测试。用 Espresso 或 Compose Testing 跑关键路径，确保交互行为一致。重点是那些有状态变化的场景——点击、输入、滚动、加载。

第三层是性能基线。记录迁移前后的首帧时间、滑动帧率、内存占用，设一个可接受的退化阈值（比如帧率下降不超过 5%）。Compose 的性能陷阱不少，比如在 Composable 里创建对象、LazyColumn没设 key、过度重组，这些都得靠性能测试兜住。

4. 实操过程与核心环节实现

4.1 迁移前的准备工作

正式动手前，有几件事必须先做完，否则中途会卡壳。

统一依赖版本。Compose 的版本和 Kotlin 编译器版本强绑定，composeOptions里的kotlinCompilerExtensionVersion要和 Kotlin 版本匹配。老项目往往 Kotlin 版本偏低，得先升上去。升级 Kotlin 本身可能引入编译错误，这一步要单独做、单独验证，别和迁移混在一起。

建立设计系统映射。把项目里 XML 用的颜色、字体、间距、圆角这些设计 token，整理成 Compose 的MaterialTheme配置。这一步做完，AI 转换时才有统一的引用目标，不然每个组件都自己写死颜色，后面改主题要命。

搭建迁移脚手架。包括：AI 转换的提示词模板库、转换后的代码检查脚本（lint 规则）、截图对比的基线管理、UI 测试的公共工具。脚手架搭好，单个组件的迁移就是流水线作业。

4.2 单个组件的完整迁移流程

拿一个典型的"用户信息卡片"组件举例，走一遍完整流程。

第一步，AI 初转。把 XML 和提示词一起喂给 AI，得到 Compose 代码。这一步产出的是草稿，不要直接合入。

第二步，人工审查。重点看四件事：状态处理对不对、有没有硬编码的颜色尺寸、@Preview能不能正常渲染、有没有引入不必要的依赖。审查时对照原 XML 逐行过，确保没有遗漏的 View。

第三步，主题对齐。把硬编码的值替换成MaterialTheme.colorScheme、MaterialTheme.typography里的引用。这一步是保证视觉一致的关键。

第四步，截图对比。跑 Paparazzi，和原 View 的截图对比。有差异就调，直到像素级接近。这一步往往要来回几次，间距、字体渲染的细微差异都得抠。

第五步，UI 测试。补上这个组件的交互测试，点击、状态切换都要覆盖。

第六步，灰度接入。先在测试环境替换，观察一两个版本，没问题再上生产。生产环境用开关控制，出问题能一键切回旧实现。

这个流程走下来，一个中等复杂度的组件大概半天到一天。比纯手写快，但也不是"一键完成"。关键是每一步都有验证，风险可控。

4.3 参数计算与性能调优实例

Compose 的性能调优，很多时候是算出来的，不是猜出来的。举个LazyColumn的例子。

假设一个列表有 1000 项，每项高度约 80dp，屏幕高度 800dp。理论上屏幕内可见约 10 项，加上预加载，LazyColumn会维护 15 到 20 个 Composable 实例。如果每项的重组成本高，滑动就会掉帧。

优化手段有几个，按收益排序：

• 给items加key：让 Compose 能正确复用，避免整列表重组。这是收益最大的一步，几乎零成本。
• 用derivedStateOf收敛状态读取：比如"是否显示回到顶部按钮"依赖滚动位置，如果直接在 Composable 里读listState.firstVisibleItemIndex，每次滚动都会触发重组。用derivedStateOf包一层，只在布尔值真正变化时才重组。
• remember缓存计算结果：列表项的格式化文本、颜色计算这类，用remember缓存，避免每次重组重算。
• 避免在 Composable 里创建对象：比如Modifier.padding(16.dp)里的16.dp是编译期常量没问题，但Modifier.background(Color(...))里动态创建 Color 对象就会增加开销。

这些优化点，AI 生成的代码往往不会主动做，得人工过一遍。我一般会在代码审查清单里专门列一条"Compose 性能检查"，逐项对照。

4.4 团队协作与知识沉淀

迁移不是一个人的事，团队协作方式直接影响效率。我的做法是：

• 建立转换案例库：每迁移一个组件，把原始 XML、AI 提示词、最终 Compose 代码、踩过的坑，整理成一条案例。积累几十条之后，这就是团队最宝贵的资产，新人照着案例就能上手。
• 定期复盘提示词：AI 的输出质量会随着提示词迭代提升。每周花半小时，把本周返工最多的场景拿出来，优化提示词模板。
• 代码审查双人制：AI 生成的代码，必须经过一个熟悉 Compose 的人审查。审查重点不是语法，是状态管理和性能。

实操心得：迁移初期不要追求速度，前十个组件慢一点没关系，把流程和模板打磨好。后面速度会指数级提升。我见过团队一上来就冲量，结果模板没定型，返工率极高，反而更慢。

5. 常见问题与排查技巧实录

5.1 迁移过程中的典型问题速查

这张表是我从实际项目里攒出来的，基本覆盖了迁移期八成的问题。遇到新问题，先往这几个方向靠，能省不少排查时间。

5.2 AI 转换的隐性错误与识别方法

AI 生成的 Compose 代码，有些错误很隐蔽，编译能过、跑起来也不崩，但行为不对。我总结了几类高发的隐性错误：

状态提升过度或不足。AI 有时会把本该本地管理的状态提升到 ViewModel，导致不必要的重组；有时又把该共享的状态留在 Composable 里，导致多个组件状态不同步。识别方法是画状态流转图，看每个状态的所有者和消费者是否清晰。

副作用位置错误。LaunchedEffect、DisposableEffect这些副作用 API，AI 经常放错位置或用错 key。比如LaunchedEffect(Unit)和LaunchedEffect(someKey)的行为完全不同，前者只跑一次，后者 key 变化就重跑。识别方法是审查每个副作用的触发时机是否符合预期。

重组范围过大。AI 倾向于把整个页面写成一个大的 Composable，导致任何状态变化都触发全页重组。识别方法是用 Compose 的 recomposition 计数工具，看哪些 Composable 被不必要地重组了。

Modifier顺序错误。Modifier是有顺序的，padding在background前后，效果完全不同。AI 经常搞混。识别方法是逐个检查Modifier链，对照设计稿确认。

这几类错误，靠编译器和 lint 抓不住，必须靠人工审查和测试。所以我在流程里坚持"AI 生成 + 人工审查"两道关，不能省。

5.3 独家避坑技巧

分享几个文档里不会写、但实际很有用的技巧。

技巧一：用旧代码做"金标准"测试。迁移前，先给要迁移的组件补一套 UI 测试，跑在旧实现上，记录通过状态。迁移后，同一套测试跑在新实现上，必须全绿。这样能确保行为一致，比人眼靠谱。

技巧二：分批迁移，每批不超过五个组件。一次迁太多，出问题难定位，回退成本也高。小批量迁移，每批验证通过再进下一批，节奏稳。

技巧三：保留旧实现的开关。生产环境用远程配置控制走新实现还是旧实现，出问题能秒切回。这个开关在迁移完成后保留一两个版本再移除，给自己留后路。

技巧四：把 AI 提示词当代码管理。提示词放 Git 里，有版本、有 review、有变更记录。提示词改坏了，影响的是整个迁移流水线，值得像对待代码一样对待它。

技巧五：性能基线要提前建。别等迁移完才发现性能退化。迁移前就把关键页面的性能数据采集好，作为对比基线。没有基线，性能问题就是笔糊涂账。

5.4 迁移完成后的收尾工作

迁移不是把最后一个组件转完就结束了，收尾工作同样重要。

清理互操作代码。迁移完成后，ComposeView和AndroidView这些桥梁代码要逐步移除，让整个 UI 层统一到 Compose。留着它们，代码库会越来越乱。

统一代码规范。迁移期可能新旧风格并存，收尾时要统一。包括命名规范、文件组织、状态管理模式，都要对齐到 Compose 的最佳实践。

更新文档和培训。把迁移过程中的经验整理成文档，给团队做一次分享。尤其是那些踩过的坑，让后来人少走弯路。

移除迁移开关。确认新实现稳定运行几个版本后，把远程配置的开关和旧实现代码一起移除，避免代码库长期背着历史包袱。

6. 我对 AI 辅助迁移的真实看法

聊了这么多方法论，最后说点个人体会。AI 在 Compose 迁移里的价值，我觉得被高估也被低估了。高估的是"全自动"——指望它一键搞定整个项目，不现实，至少现在不现实。低估的是"批量化机械转换"——这部分它做得比人快得多，而且不知疲倦，只要约束给到位，质量相当稳定。

真正决定迁移成败的，不是 AI 有多强，而是流程设计得有多细。提示词模板、验证流水线、回退机制、案例库，这些"脏活累活"才是核心竞争力。AI 只是流水线上的一个工位，前后得有配套的输入输出和质量控制。

我自己的经验是，一个中等规模的 Android 项目（几十个页面），用这套方法迁移，人力投入大概能比纯手写省一半以上，而且回归 bug 明显更少，因为每一步都有验证兜底。但前提是团队愿意在前期花时间搭流程、磨模板，而不是急着出活。急着出活的，往往在中后期被返工拖垮。

如果你正准备启动迁移，我的建议是先拿两三个叶子组件试水，把流程跑通，再逐步扩大。别一上来就啃硬骨头，容易受挫。等流程顺了，你会发现迁移这件事，其实没那么烧心。