两三年前我第一次尝试把页面迁到 Jetpack Compose 的时候，心里其实挺没底的：布局要改、状态要改、生命周期的处理方式也要改，一个中等页面下来，编码加调试往往就是一整天，整个人被一堆琐碎细节磨得疲惫不堪。最近看了 Meta 工程师公开分享的用 AI 辅助迁移 Compose 项目的思路，很多以前靠人肉硬顶的环节确实可以交出去了。这篇文章我会结合那套方法论，再加上我自己实际踩出来的经验，把整个迁移过程里最容易让人烦躁的环节拆开讲清楚，给你一套可以直接抄作业的路线图。
先说清楚适用对象：如果你手上是一个已经在用传统 View 体系的 Android 项目，计划整体或部分迁移到 Compose；或者你已经在用 Compose，但想引入 AI 来提升重构、翻新旧模块的效率，那这篇文章基本就是为你准备的。我会尽量做到既讲清楚 AI 怎么用，也讲清楚哪些地方绝对不能全信 AI，保证你看完之后知道每一步该怎么落地。
1. 为什么 AI 能让 Compose 迁移不再“烧心”
1.1 迁移 Compose 从来不是“顺手改改”的事
一个典型的 Android 界面栈，通常长这样：Fragment + ViewBinding + RecyclerView.Adapter + ViewModel + 各种自定义 View，再加上一堆 XML 布局。一次全面迁移要动的东西，远比“把 XML 换成 Kotlin 代码”多得多。
拿一个中等规模的模块来说，几十个 XML、十几个 Adapter、外加若干自定义控件是常规操作。你如果只是把这些文件手写翻译一遍，等于用几个月时间重复一遍没有技术含量的苦力劳动。更难受的是，这个过程中还容易引入隐藏故障，比如 RelativeLayout 依赖关系在 Compose 里没有等价物、自定义 View 的 onMeasure 逻辑在 Compose 里需要重新建模，这些问题会拖慢迁移节奏。
这里我习惯把迁移拆成四个层次来看：
- UI 描述层：XML / View 体系换成 Compose UI。
- 状态层：普通可观察状态换成 StateFlow / Compose State。
- 生命周期层：Fragment 的 ViewLifecycleOwner 换成 Compose 容器相关的 LifecycleOwner。
- 交互层：回调用接口回调、事件总线等方式，换成 Compose 事件传递和 Side Effect。
一旦把这四层分开处理，迁移就从“一次大手术”变成了“拆解成多个小操作”。Meta 分享的思路本质上也是这个方向，但他们额外加了一个关键变量：让 AI 参与每一层里的机械翻译工作。开发者的主要任务变成审查、校验和纠偏。这样确实能省下大量重复劳动，让人把精力放在真正需要判断力的地方。
1.2 Meta 的迁移困境与 AI 的切入点
Meta 在 Android 这边最头疼的并不是“能不能用 Compose”，而是“存量代码怎么低成本搬过去”。他们的几款核心应用都有海量历史页面，这些页面可能承担着核心用户链路，不能因为一次重构就直接下线。以前不少工程师宁愿在旧体系里多补一个功能，也不想碰迁移这块硬骨头，因为一个页面从 XML 搬到 Compose，要反复确认视觉还原度、语义逻辑、埋点上报等一大堆细节。
Meta 公布的 AI 辅助方案，本质上是拿“代码翻译模型”去处理最基础的 XML 到 Compose 转换，再用规则和编译检查把 AI 生成的结果约束在一个安全范围里。一个很关键的细节是，他们不是让 AI 一次性生成整个页面，而是把一个大页面切成若干个小块，每次只翻译一块，然后马上跑编译、跑测试、做视觉对比。这样就算 AI 出问题，影响范围也被锁在一个很小的模块里，不至于让整个项目处于不可用状态。
另外一个值得借鉴的点是提示词约束。Meta 工程师在分享里提到，他们的提示词会带上非常明确的输入输出格式，比如“输入 XML 和对应 ViewModel，输出可组合函数，不要修改状态逻辑，保持原有命名前缀”。这个约束听起来很普通，但实际效果差异极大。如果没有这层约束，AI 很容易把包结构、命名、依赖全部自作主张改掉，最后你拿回一份“能编译但完全看不懂”的新代码，代码评审阶段就能把团队拖垮。
我自己试过之后，最大的感受是：AI 在 Compose 迁移里的价值，不在于它有多聪明，而在于它能不厌其烦地重复“翻译、格式化、匹配资源”这些机械化动作。真正决定迁移成败的，反倒是人怎么给它设定边界、怎么验证它的输出。
2. 动手迁移前，先把地基打稳
2.1 盘点工程现状与迁移范围
很多迁移失败的项目，死因不在后面，而在最开始没定义清楚“迁什么、不迁什么”。我先说一个比较稳妥的盘点方法：把页面按使用频率和复杂度分成三类，然后再决定每一类的处理节奏。
第一类是高频且简单的页面，比如设置页的单个条目、用户信息展示块。这类页面结构简单、依赖少，适合作为 AI 迁移的第一梯队，即使出现偏差也容易发现。
第二类是逻辑复杂但 UI 相对固定的页面，比如订单详情、个人主页摘要。这类页面核心价值在状态和交互逻辑，迁移时需要把更多精力放在状态对齐上，AI 负责处理 UI 布局，人负责核对状态流转。
第三类是极度复杂的自定义页面，比如地图轨迹展示、复杂图表、视频编辑面板。这类页面通常依赖大量自定义 View 和底层绘制能力，不太适合初期就让 AI 直接生成，最好先保留在旧体系里，等前面两类跑顺了再逐步处理。
我实操时还会用脚本统计模块之间的依赖关系。具体做法是扫描 Gradle 模块的依赖配置，看看哪些模块的 UI 层和业务层耦合度最低，就把它们排在迁移队列前面。耦合度极端的模块，在 AI 时代也不建议硬迁，因为 AI 对跨层业务的理解仍然有限，强行让模型去生成复杂业务逻辑容易出偏差。
2.2 建立可验证的迁移基线
迁移不烧心的重要前提，是你随时能回答“改完之后有没有变坏”。我推荐在动手之前先把三样基线做起来：视觉基线、功能基线和性能基线。
视觉基线的做法，是把目标页面在不同分辨率、不同主题下的截图保存好，之后 AI 生成的 Compose 页面在相同环境下重新截图做对比。这个环节麻烦归麻烦，但绝对不能省。因为 Compose 默认的阴影、边距、字体渲染和传统 View 体系存在细微差异，这些差异开发时肉眼不容易发现，上线后却会变成用户嘴里“好像哪里不一样”。
功能基线更直接：把关键用户路径的 UI 测试和端到端测试跑通一遍，保存测试结果。之后每一批迁移完成，这些路径都要重新跑一遍。任何一条失败都要先做归因，而不是盲目让 AI 去修。
性能基线要记录页面首次加载耗时、滑动帧率、内存占用。Compose 的初始化开销和重组计算都是新风险点，没有性能基线帮你兜底，时间长了你根本说不出一次迁移到底是变好了还是变差了。
2.3 选好 AI 工具并固化提示词
关于 AI 工具选型，我的建议是不要只依赖一个大模型。Meta 内部那套系统我们接触不到，但现有的大模型和代码补全工具完全可以组成一条流水线。我常用的组合是这三种：
- 结构理解：用支持代码库检索的模型，先让 AI 通读整个模块的代码，回答“这个页面的数据来源有哪些”这类问题。
- 代码生成：用专门的代码生成模型来写 Compose 代码，把 XML 片段、ViewModel、资源文件一起作为输入丢给它。
- 代码审查：再用另一个侧重代码审查的模型，对生成结果做一轮静态检查和风格检查。
这种多模型组合会带来额外的好处：不同模型的“偏见”会互相抵消。生成模型容易写出千篇一律的样板结构，审查模型则会从规范层面挑出问题。两轮下来，代码质量通常比我单靠一个模型来回调优高出不少。
提示词模板是另一个关键点。我整理了一套基础模板，核心要素包括：
- 输入文件的绝对路径与文件内容。
- 目标框架版本与项目约束，比如 Kotlin 版本、minSdk。
- 明确禁止改动的东西，比如数据层、网络层、业务状态。
- 输出格式要求，比如输出一个可组合函数、独立文件、导出给调用方。
这套模板一旦固化下来，就可以在项目里反复复用。每迁一批页面，只需要把新页面的 XML 和 ViewModel 填进模板，剩下的交给 AI。
3. 用 AI 拆解和转换 UI 层
3.1 XML 布局翻译成 Compose 的标准流程
XML 布局里，LinearLayout、FrameLayout、RelativeLayout 三类容器占了绝大多数。AI 翻译时最容易出的问题，是它喜欢把布局层级原封不动搬到 Compose 里。比如一个可以合并成 Column 的多层嵌套 FrameLayout，AI 直接照搬，导致重组范围无谓扩大，性能反而比原来更差。
所以我会在让 AI 干活之前，明确要求它先做一步“结构简化”：把没有业务含义的中间容器合并，把只有装饰作用的层级去掉，用 Modifier 代替布局嵌套。这是 AI 能做但需要明确指示的一项优化，你不说它默认不做。
实际操作中，我建议让 AI 分两步输出：第一步输出“翻译版”，也就是和 XML 结构一一对应的 Compose 代码；第二步输出“优化版”，在翻译版基础上做层级合并和 Modifier 改造。你只需要人工审查优化版，对比起来非常清爽。不要让 AI 直接输出最终版，否则它很可能会跳步骤，甚至连某些资源引用都漏掉。
3.2 状态从 View 体系搬到 Compose 的关键点
UI 层翻译完之后，下一步是状态。传统 View 体系里，我们习惯用 LiveData 或者直接把 Activity / Fragment 作为状态持有者；Compose 里更推荐把状态提升到 ViewModel，并用 StateFlow 暴露给界面。AI 在这里能帮的忙，是读取整个页面的数据流，自动生成一个基于 StateFlow 的 ViewModel 状态容器。
这个环节有几个坑特别典型。
第一，AI 经常自作主张地把 val 变量改成 var，然后把所有字段都包装成 MutableStateFlow。这在编译上没问题，但会让状态管理变得不可控，因为任何地方都能改状态，违背了单向数据流原则。我会在提示词和人工审查里同时加两重约束。
第二，事件处理容易出错。传统 View 里可能有 interface Listener，或者用 LiveData 传递一次性事件；迁移到 Compose 之后，一次性事件应该用 Channel 或者 StateFlow 加事件标志。AI 往往直接照搬接口回调，把它转成一个普通函数调用，这在组合函数里容易引发状态不一致。
第三，Compose 的重组模型要求“读什么状态就传什么状态”。如果你把一整个对象都传给了可组合函数，那么任何字段变化都会触发不必要的大范围重组。AI 生成的代码经常忽略这一点，所以我一般会让模型针对每个状态对象，额外生成一组用于拆包的小函数，确保各字段按需读取。
3.3 可组合函数怎么拆分才不影响后续维护
另一个容易被忽略的问题是函数粒度。旧体系里的一个页面类，如果迁移时只是简单翻译成一个巨大的可组合函数，虽然能跑，但后续维护就是给自己埋雷。
我习惯让 AI 按照“一个职责一块 UI”的标准把大函数拆开。比如一个订单详情页，拆成订单信息区、物流卡片区、操作按钮区、底部推荐区，每个区域对应一个独立的可组合函数。这样有几个明显的好处：单块预览调试方便，状态更新范围变小，后续修改只动某个区域也不容易影响其他区域。
可组合函数拆分之后，还需要注意参数设计。我建议尽量使用“数据对象 + 回调函数”这种形式，而不是“一堆零散参数 + 内部创建 ViewModel”。因为 Compose 函数要符合可复用原则，如果每个函数都内部 new 一个 ViewModel，测试时就没有解耦手段，代码也会越来越难读。
4. 阶段式迁移的实操细节
4.1 按模块分批迁移，批次怎么划
Meta 的方法给了一个挺重要的启示：永远不要让某一版迁移一次性合并进主干。他们的做法是按页面划分迁移批次，每个批次单独提交、单独测试、单独发布。这种方式看似拖慢节奏，实际上保证了任何时候仓库主干都是可发布的，回归风险大大降低。
我在团队里采用的批次划分更细一点：
- 第一批：选取 5 到 8 个低复杂度、低耦合的页面，跑通完整流程。这个阶段的目的是磨合 AI 提示词模板和测试流程，不在于迁移数量。
- 第二批：选择中等复杂度的列表页和表单页，加入状态容器迁移，把 ViewModel 和 Compose 的配合模式确定下来。
- 第三批：处理需要自定义绘制、复杂动画的页面。此时前两批积累的模式已经比较成熟，AI 提示词也更加稳定，即使遇到难题也能靠已有经验快速排查。
每一批完成的标准不是“能编译”，而是“视觉对比通过、功能测试通过、性能不劣化”。少任何一项，都别往下一批走，否则问题会在后面被放大到很难收拾。
4.2 生成“最小差异代码”而不是整文件重写
这里说的差异代码，指的是改造前后能够进行 diff 对比的代码，而不是整个文件重写。AI 迁移过程中最怕的，就是模型把和 UI 无关的代码也改了，比如格式化变了、import 顺序换了、字符串资源被合并了。这些无谓改动会让代码 review 变成一场灾难，因为你根本分不清哪些是核心变更。
解决方案是约束 AI 生成“最小差异模块”。具体做法是：让 AI 只输出目标可组合函数加上必要的 import 语句，不要让它碰其它文件；使用统一的格式化工具处理新代码，确保 diff 范围可控。我还会把旧文件的 hash 值记下来，迁移完成之后对比 hash，一旦发现无关文件被动过，先还原，再退回重新生成。
这里再补充一个细节：迁移 Compose 代码时，最好把“旧资源名到新资源名”的映射表交给 AI。比如某个颜色在旧体系叫 colorPrimary，在 Compose 里可能已经被统一成 brandColor。AI 如果不知道这个映射，就会保留旧名字造成不一致。映射表不长，但能省掉大量后期清理工作。
4.3 回归测试与性能对比的数据怎么抓
回归测试方面，我强烈推荐引入 Compose 自带的 UI 测试框架。Compose 的测试比传统 View 测试要自然得多，可以直接通过节点查找、点击交互、断言状态，不需要等待视图加载过程。AI 生成的代码在测试这块也可以“学”起来，比如让它读取旧测试用例，翻译成 Compose 测试版本，再由人来增补边界场景。
性能对比不能只看一次冷启动。Compose 的重组优化有热点效应，真实用户操作路径会触发不同的重组。所以性能对比要覆盖几种典型场景：快速滚动列表、表单输入触发状态变化、页面频繁进出。我会把这几个场景录制成基准脚本，每次迁移一批页面后都重新跑一遍，数据落后直接回滚。
做性能对比时，还有一个细节很多人会忽略：要区分 debug 和 release。Compose 在 debug 模式下由于额外检查和实时布局工具，性能会明显偏慢。如果拿 debug 包跑性能对比，数据失真严重。至少要用 release 包来跑核心指标，才能反映真实用户环境。
5. 常见问题与避坑笔记
5.1 AI 生成代码最容易犯的五个错误
据我自己观察，AI 生成 Compose 代码时，以下五个错误出现得最频繁，我按发生概率从高到低排一下：
第一是资源引用错误。XML 里的 @dimen、@drawable、@color 引用，AI 偶尔会用错名字或直接省掉。解决办法是让 AI 输出代码时保留所有资源引用的原始命名，并通过 IDE 的 lint 做二次校验。
第二是 Modifier 使用过度。AI 倾向把本来应该靠布局组合实现的效果全部堆进 Modifier.padding / Modifier.size，导致样式和布局逻辑缠绕在一起，后续改起来很费劲。
第三是隐藏的无限重组。如果某个可组合函数把整个列表数据源作为 key 传入 LazyColumn，很可能每次滑动都会触发全量重组。AI 自身很难发现这种问题，需要靠性能测试才能暴露。
第四是空安全处理不当。生成代码里容易出现大量 !!，一旦数据缺失，直接崩溃。我会在提示词里明确加一句“禁止使用非空断言，所有可空字段必须提供默认值或显式处理”。
第五是重复造轮子。AI 经常忽略项目里已经存在的通用组件，比如项目里本身封装好了 AsyncImage，AI 却会引入一个新的网络图片组件，增加依赖和风险。在提示词里附上项目可复用组件列表，能很大程度缓解这个问题。
5.2 第三方库在 Compose 环境里的适配问题
迁移过程中最容易被低估的是第三方库适配。Compose 对生态的要求更高，很多旧库在 Compose 环境里不能直接使用，或者需要额外的桥接层。常见的几类问题：
- 图片加载库如果带有自定义占位动画，往往需要提供 Compose 版本的封装。
- 地图、视频类 SDK 一般还是基于 View 设计，需要 AndroidView 容器包一层，再通过状态桥接。
- 埋点库通常对 View 体系和 Compose 体系分别有接口，需要确认当前版本是否支持 Compose 节点监听。
我建议在迁移排期表上专门留出“依赖升级”的时间，不要在业务迁移进行到一半时才突然发现某个库在 Compose 环境里不可用。在盘点阶段就应该把每个模块用到的依赖列出来，逐个确认是否有对应的 Compose 支持或者桥接方案。
如果某个第三方库在 Compose 环境下确实没有成熟方案，还有一个变通思路：用 AndroidView 把它包起来，先用最少的代价保证页面功能可用，后续再考虑替换。虽然这种方式不是最优雅的，但它是迁移过程中的合法逃生通道，能避免你被一个第三方库卡住整个项目。
5.3 我踩过的坑和总结出的经验
最后聊点实在的。我用 AI 做 Compose 迁移多次之后，最大的体会是：AI 再强，也只能作为速度放大器，不能作为判断器。它能把一个两天的工作量压到几小时，但这些省出来的时间必须花在验证上，而不是提前结束任务。
有一个坑我印象特别深：有一版迁移生成的代码，所有页面看起来都正常，测试也全绿，结果上线后用户反馈一个表单页的输入法弹出位置不对。查了两天才发现，是 AI 生成代码时把一个 ScrollState 的初始化位置搞错了，导致滚动锚点异常。这类问题单靠代码审查很难发现，必须结合设备实测才能暴露。
所以我现在给自己定了一条规矩：任何 AI 生成的迁移代码，至少要在一个主流机型和一个小内存机型上跑一次完整闭环流程。因为你永远无法预判 AI 会在哪个细节里埋雷，但一定能通过不断实测把风险包住。
另外还有一个我自己比较受用的经验：AI 迁移出来的代码，一定要让人重新读一遍，而且最好是让没参与这次迁移的同事来读。原因很简单，参与迁移的人对代码太熟了，很多问题看不出来；而一个全新视角的同事往往能一眼发现命名混乱、职责不清的地方。
如果你准备启动一个 Compose 迁移项目，我的建议是先花一个星期搭建好提示词模板、验证流程和性能基线，再让 AI 正式开始生成。这个准备工作看似慢，实则是整个迁移过程中最值得的一笔投入。真正开始逐批迁移时，你会发现自己只需要做审查和决策，那些以前让人“烧心”的机械劳动，已经不需要你亲自下场了。
