聊 Compose 迁移很多人第一反应是“工作量太大”第二反应是“AI 能帮上什么忙”。Meta 团队在公开分享里讲过他们怎么用 AI 辅助把大批存量 Android 页面迁移到 Jetpack Compose核心结论其实不是“AI 全自动重写”而是“AI 负责把重复劳动吃掉人负责守住质量和节奏”。这篇文章就围绕这套思路展开结合我自己迁移项目的经验把从摸底、拆分、提示词设计到审查验证的完整流程拆开讲一遍。适合正在准备迁移、被 XML 页面拖住、想提高迁移效率又不想踩坑的 Android 开发者。1. 用 AI 迁移 Compose先想清楚“烧心”到底烧在哪1.1 手工迁移最难受的几件事一个稍微有点历史的 Android 项目页面数量通常以几十甚至上百计。每个页面都由 XML 布局、Activity/Fragment、Adapter、资源文件、主题属性、点击监听、状态刷新逻辑拧在一起。手工迁移到 Jetpack Compose 时最磨人的不是“写不出 Compose”而是下面这些环节。第一件事XML 层级关系的转写。LinearLayout 加 weight 转成 Row/Column 加 weight 还算顺手但 RelativeLayout 里各种相对约束或者 ConstraintLayout 里一堆链、比率、引导线转起来容易漏语义。比如一个“在父布局垂直居中、水平靠右”的约束写成 Compose 时就得想清楚是 Modifier.align 还是 Arrangement漏掉任何一个对齐关系界面观感就变了。这类转写本身不难但数量一大人就很容易疲。第二件事事件处理与数据流的重新组织。XML 时代回调散落在各处Activity 里的点击监听、Adapter 里的 item 回调、Fragment 里生命周期与 UI 的耦合。迁移到 Compose 时要把这些理顺成状态提升、回调参数、rememberCoroutineScope 这种习惯。这项工作需要人理解页面逻辑AI 可以帮忙搬运但搬运之前得先有人想明白状态该放哪。第三件事适配与回归验证。每迁移一个页面都要在多种屏幕尺寸、深色模式、不同字体缩放下过一遍。这个环节最烦人也最容易被压缩一压缩后面就线上翻车。尤其深色模式下的颜色验证、大字体模式下的布局检查手工做一次就是大半天几十个页面下来体力和耐心都被磨光。“烧心”主要烧在这三件事上而不是“学习 Compose API”本身。搞清楚这一点很重要因为 AI 辅助方案的编排也应该围着这三件事设计AI 解决层级转换的体力活人抽身处理交互逻辑和回归验证。注意不要一开始就指望 AI 自动完成全项目迁移。AI 的能力适合“单页面、小单元”级别的转换直接丢一个巨型模块进去输出质量会急剧下降返工成本反而比手工还高。1.2 AI 适合接手哪部分不适合哪部分Meta 团队那套做法的可取之处是先给 AI 划定了工作边界。概括下来有三类活非常适合交给 AI。第一类是 XML 到可组合函数的机械转换。布局结构清晰、没有太多自定义 View 的页面AI 的转换准确率很高。一个由若干 TextView、ImageView、Button 组成的静态结构页AI 一次生成的代码几乎可以做到只改几个命名就提交。第二类是简单资源引用和主题属性的映射。比如颜色、尺寸、字符串资源、字体家族AI 基本不会出错。把 R.color.xxx、R.dimen.xxx 保留成原引用AI 只要看到了上下文就能处理。第三类是重复性样板代码。比如按列表项生成 LazyColumn 的 item 结构、把 findViewById 加类型转换改写成参数回调、把 Adapter 的 getItemCount 和 onBindViewHolder 改写成 data 列表遍历。这类代码量大、规律性强AI 写起来又快又不容易烦。不太适合 AI 直接拍板的部分同样有三类。状态架构设计。一个页面是用 ViewModel 还是 remember状态提升到哪一层这需要结合功能演进和团队习惯来决定。AI 给不了可靠答案它只会给出一个“看起来合理”的方案但这个方案未必适合你的项目。自定义 View 与复杂触摸交互。自定义绘制、手势冲突、嵌套滚动这些是迁移中的高难点必须人工介入。AI 训练数据里对这种代际差异巨大的代码理解有限让它硬转大概率转出一堆无法编译的奇怪代码。无障碍和动态字体适配。AI 生成的代码经常忽略这些必须靠人工检查。contentDescription 丢失、文本字号用死值、点击区域过小这些是 AI 迁移代码里的高发问题。这个边界一旦确认后续所有提示词、审查清单、测试策略都可以对应展开。换句话说AI 参与迁移的正确姿势不是“让 AI 写完我检查”而是“让 AI 写我能写得很烦的部分把精力留给 AI 写不了的部分”。2. 迁移前的摸底、拆分与路线图2.1 先给项目做一次“体检”动手迁移前我会先花一两天做代码盘点。不是大概看看而是把项目里的页面清单、依赖关系、自定义 View 密度、布局复杂度都量化出来。具体做法是写一个简单的扫描脚本把如下信息导出成表格。每个 Activity/Fragment 对应的 XML 布局文件路径布局文件里的 View 节点数量与类型分布重点统计自定义 View、WebView、RecyclerView布局中引用的资源数量区分颜色、尺寸、字符串、drawable页面是否存在多布局适配、横竖屏差异、深色模式定制。拿到这张表后按“迁移难度”给页面分级。我常用的分级维度有三个。维度低难度高难度布局复杂度线性布局为主层级浅ConstraintLayout 嵌套、自定义 View 多状态逻辑单次加载、静态展示多状态切换、列表刷新、表单校验测试覆盖有基础冒烟测试无测试依赖人工回归分级的意义在于排定迁移顺序。低难度页面先做可以在项目里快速建立一套 AI 辅助迁移的流程规范也让团队积累信心。高难度页面放到后面等流程成熟了再啃风险会小很多。提示盘点阶段顺便统计一下 RecyclerView.Adapter 的数量。Adapter 的迁移往往是工作量的大头提前知道总量对工期估算非常有帮助。2.2 划分迁移单元控制单次变更范围分级的下一步是切分迁移单元。我的原则是一个合并请求尽量只包含一个页面或一个完整功能模块的迁移不做跨模块的大爆炸式改动。这既是为了回滚方便也是为了让 AI 生成的代码保持在小范围、可控的上下文里。页面内部的迁移顺序也有讲究。我通常按下面的顺序来排。静态内容页先行。这类页面逻辑少、布局简单适合让 AI 快速产出团队也能在低风险环境里跑通整个迁移流程。列表页次之。RecyclerView 转 LazyColumn 是高频场景AI 生成的骨架可用性高人工主要补状态刷新和空态处理。表单页和含有复杂交互的页面最后处理。这类页面要人工主导AI 只辅助局部的转换。每个迁移单元都包含三个产出可用的 Compose UI、对应的单元测试或截图对比、以及旧的 XML 布局的删除。删除旧代码这一步别省否则项目维护成本会变成两套。很多项目迁移到一半新老代码并行维护改一个功能要动两套实现那才是真的烧心。2.3 互操作方案选型ComposeView 还是 AndroidView迁移不是一天完成的新旧代码共存是常态。Android 提供双向互操作机制我实际使用时的选型经验如下。在 XML 页面里渐进引入 Compose用 ComposeView 作为容器。适合把某个复杂页面里的一个区域先抽出来用 Compose 实现比如原来 View 体系里的头部卡片、底部操作栏。这种情况下XML 文件里直接写一个 ComposeView 节点再在代码里 setContent原有页面骨架保持不变风险最小。在 Compose 页面里保留旧的自定义 View用 AndroidView 包装。适合还没有完成迁移的自定义控件、地图、视频播放器等。AndroidView 的 factory 参数负责创建 Viewupdate 参数负责在状态变化时更新 View两个参数分工明确用好了过渡期会很平稳。对 RecyclerView 这类复杂的 View不要硬包。先迁移内部 item再逐步将整个列表替换成 LazyColumn。直接在一个 AndroidView 里塞一个 RecyclerView 也能跑但这样既享受不到 Compose 的优势还引入一层多余的桥接后续还得再迁移一次。互操作的关键是生命周期和状态对接。在 ComposeView 里创建的 Composition要跟着容器 View 的生命周期走在 AndroidView 里包装旧 View则要注意 Compose 重组时不要重建 View 实例。一个常见的坑是在 AndroidView 的 lambda 里直接 new 一个 View导致每次重组都创建新对象。正确做法是用 remember 保存实例lambda 里只做更新。注意互操作期间两套 UI 体系的主题和字体会不一致。提前把 Compose 主题映射到现有设计令牌上能避免迁移页面和未迁移页面放在一起时出现明显的视觉割裂。3. AI 辅助迁移的核心实操3.1 XML 布局转 Compose 的提示词工程AI 输出质量的最大变量是输入给它多少上下文。直接把一整个 XML 文件丢给 AI它虽然能生成一段 Compose 代码但经常出现资源引用错误、布局语义丢失、dp 与 sp 混淆等问题。我总结了一套相对稳定的提示词模板基本结构包含四个部分。角色与任务明确告诉 AI这是一个 Android Compose 迁移任务。输入内容粘贴完整的 XML 文件并说明对应的主题、资源文件位置。输出要求只输出 Compose 代码使用指定的 API 版本遵循项目的包名和命名规范。约束条件不使用第三方扩展库遇到不认识的属性时保持原样并注释说明处理点击事件时只留参数占位。下面是我常用的一个提示词样例。你是一名 Android 工程师正在把 XML 布局迁移到 Jetpack Compose。这是布局文件内容 粘贴 XML 迁移要求 1. 使用 Material3 组件主题色使用文件中的引用 2. layout_width/layout_height 中 0dp 对应 weight请保留权重语义 3. 所有字符串、颜色、尺寸引用保留原 R 文件引用 4. 点击事件不要实现定义为参数回调命名以 onXxx 开头 5. 输出完整 Kotlin 代码不需要 import 和包声明。实测下来约束条件比任务描述更能提升准确率。特别是“点击事件参数化”这一条能有效避免 AI 生成一堆不存在的 View 引用。另一个人工补充的关键点是让 AI 输出前先描述它对布局结构的理解。比如要求它用三五行文字概括“这个布局是左图标、中间标题、右侧按钮的三列结构权重比为 1:3:1”它理解结构后再生成的代码准确率明显更高。提示一次只转换一个 XML。多个布局一起丢进去AI 很容易混淆资源引用和组件归属。3.2 状态与交互逻辑迁移XML 时代的交互逻辑散落在 Activity、Fragment、Adapter 和各种各样的监听器里。AI 能处理的是“搬运”不能处理的是“重新设计状态归属”。我通常把状态设计放在前面先确定每个页面状态放在哪里。仅当前页面使用、且页面退出后不需要保留的用 remember 加 mutableStateOf。比如一个展开收起的状态、一个临时选中的 tab这种状态跟着页面走就够了不需要引入 ViewModel。需要跨页面共享或者与数据层绑定的放 ViewModel。比如用户信息、购物车数据、需要持久化的表单草稿这些必须交给 ViewModel配合 StateFlow 或 LiveData 使用。迁移时最容易犯的错就是把原本 ViewModel 里的数据改成了页面内 remember导致退出页面再进入时状态丢失。与列表项相关的放在 item 级别使用 remember避免提升到整个列表范围。列表项的选中态、展开态、输入态都应该在 item 内部管理提升到列表容器一级会造成所有 item 一起重组性能损耗很大。状态归属确定后再让 AI 做搬运工作。给 AI 的提示词要包含迁移前的旧状态代码片段、页面的 UI 结构描述以及状态归属的结论。一个比较实用的写法是让 AI“按照指定模式改写”。以下是旧版 Activity 中的点击处理和状态更新逻辑 粘贴代码 现在将它改写到 Compose 中。要求 1. 页面内部状态使用 remember { mutableStateOf(...) } 2. 需要外部驱动的状态通过参数传入 3. 列表刷新逻辑保留在 ViewModelUI 层通过 collectAsState() 获取 4. 回调函数命名统一为 onXxx。这里有一个容易踩的坑AI 会把原本在 Adapter 里的 item 点击回调直接写成 item 内嵌逻辑结果列表重组时反复触发。正确做法是让回调参数从 LazyColumn 的 item 内容里提升到列表容器一级再往下传。我在提示词里会明确加上一条“item 内部的回调必须从外部传入不要在 item 组合函数内部定义业务逻辑”。3.3 主题、资源与样式的对齐主题迁移是 AI 最容易出错、也最容易被忽视的地方。XML 时代的主题是用 style 和 theme 表达的层级较多还有 parent 继承关系。Compose 里则是一套 MaterialTheme 加自定义扩展属性的结构。我的做法是分两步走。第一步先由人工建立映射表。XML 风格Compose 对应项colorPrimary / colorPrimaryVariantMaterialTheme.colorScheme.primarytextAppearance 系列MaterialTheme.typography 对应层级圆角与背景 drawable自定义 Shape 与 Modifier.clipelevationModifier.shadow 或 Card 的 elevation 参数第二步把映射表喂给 AI并要求它严格按映射输出。如果项目里有大量自定义 style建议先写成 Compose 侧的主题扩展属性再让 AI 引用。这样同样一段颜色、字体配置迁移页面和未迁移页面都使用同一套视觉变量能明显降低回归风险。需要注意的一个细节是字体缩放。XML 里很多文本用了 spCompose 里默认也支持 sp但个别属性比如 lineHeight 在迁移时容易写死成 dp导致大字体模式下文字被裁剪。我在审查清单里固定有一条检查所有文本样式的字号与行高单位并配合系统字体缩放进行视觉验证。另一个细节是背景 drawable 的转换。XML 里的 selector drawable 经常用于按钮按下、禁用等不同状态。Compose 里对应的是 Modifier 加 state 判断或者使用 Material3 组件自带的 interactionSource 处理。这部分转手动容易错AI 也很容易转成“只有默认状态”。我的经验是先由人把 selector 的状态分支列出来再让 AI 按分支生成对应的 Modifier 链比直接让 AI 读 drawable 文件靠谱得多。4. 人在回路AI 负责快人负责稳4.1 审查 AI 生成代码的固定检查项AI 生成的代码不是终点审查是必须的。我不会逐行阅读 AI 输出的全部代码那会失去提效的意义。我会按一个固定清单重点看几个高风险点。首先是重组风险。AI 生成的代码里经常出现“在组合函数内部直接读取数据库或网络缓存”“对同一份状态做多处写操作”这类问题。检查时我会搜索整个文件的 State、remember、LaunchedEffect、DisposableEffect确认副作用都在合适的作用域里。LaunchedEffect 的 key 写不对可能导致协程频繁取消重启DisposableEffect 没写 onDispose可能造成监听泄漏。其次是资源引用。AI 有时会把颜色资源转成硬编码色值把字符串引用替换成中文字面量。我审查时会用一次简单的全局搜索检查代码里是否存在“#”开头的硬编码色值以及中文字符串直接出现在代码文件里。一旦发现全部改回 R 资源引用。这不仅是为了多语言也是为了统一修改入口。硬编码颜色尤其危险设计规范调整时一处遗漏就可能让界面颜色不统一。第三是布局语义。重点看 AI 有没有把原布局里的 contentDescription、importantForAccessibility 丢掉。这类属性在 XML 里常见但 AI 转换时经常默默忽略。如果原页面有语义说明迁移后丢了无障碍回归就是一次事故。还要检查 clickable 组件的 role 是否保留AI 很容易把原本的 Button 语义弄丢读屏用户拿到的是一个“无角色可点击区域”体验会很差。注意不要对 AI 输出的第一版代码抱太高期望。把它当作“初稿”审查的目的是定位需要修的点而不是判断“能不能用”。心态上把 AI 当成一个很快的初级工程师工作流才顺得起来。4.2 用测试和截图撑住质量底线只靠肉眼审查撑不住大规模迁移的质量。我建议每个迁移单元至少配套两类验证。第一类是 Compose UI 测试。用 createComposeRule 或 Robolectric 写基础用例覆盖页面能够正常渲染、关键按钮存在、列表能滚动、空态与错误态能切换。这些用例不求全但至少要拦住“页面直接崩了”“按钮没了”“列表空白”这几类回归。写 UI 测试时有一个小技巧给关键节点加上 testTag。AI 生成的 Compose 代码通常不会主动加 testTag但测试用例需要稳定定位。可以在提示词里要求“为每个可交互组件添加 testTag命名为页面名加组件名”这样测试代码写起来会顺畅很多。第二类是截图对比。迁移前后在相同设备与状态下截取页面用像素对比工具计算差异比。差异比的绝对值不是重点重点是找出哪些位置的差异超出预期。比如相同内容下文本换行方式不一样、间距不一致、颜色有偏差这些截图都能直观暴露。截图对比我以前用的是半自动流程手工截图再脚本比对。后来发现直接把这一步交给 AI 分析截图差异描述效率更高。让 AI 输出“这两张图在哪些区域存在差异可能是由什么代码导致”可以直接定位到可疑模块省去不少人工对照时间。4.3 按功能分配合入做可回滚的迁移大规模迁移最怕的是改出问题后找不到回滚点。我现在的习惯是一个迁移单元对应一个独立合并请求并在合并请求里保留旧代码删除前的完整提交记录。这样既满足“每步可回滚”也能在代码评审时有清晰的对照。同时每次合并不用“这个页面迁移完了”一概而论而是按子功能拆分比如一个页面迁移涉及列表展示、搜索、筛选三个功能可以拆成三次合并。每次合并后跑一轮核心功能回归出问题的定位范围会小很多。灰度方面如果项目有条件我会把迁移页面放到小流量实验里观察崩溃率、页面停留时间和关键转化。Meta 团队在分享里也提到过他们会用内部指标来判断迁移质量而不是只看代码有没有编译通过。这一步对核心链路页面的迁移尤其重要。有一个我栽过的跟头迁移完一个列表页后本地测试全过但线上反馈说“滑动卡顿”。后来排查发现AI 生成的列表项里用了大量不必要的 Modifier 链加上每帧都在做的重复计算。灰度阶段的性能监控如果提前接入这类问题能在小流量期就被发现而不是等到全量上线。迁移不是“能编译能显示”就结束性能体验必须纳入验收标准。5. 常见问题与避坑记录5.1 高频报错与排查我在用 AI 做 Compose 迁移的过程中遇到最多的问题集中在下面这几类整理成表方便直接查询。现象常见原因处理办法AI 生成的代码引用不存在的 id资源文件名与布局不一致提示词里限制只使用输入文件中已有的 id审查阶段全局搜索 id列表项点击事件反复触发回调在 item 内部定义重组后重复绑定把回调参数提升到列表容器级编译报“Composable invocations can only happen from the context of a Composable function”普通函数里调用可组合函数检查是否正确添加 Composable或把逻辑移到可组合函数内大量使用 deprecated APIAI 训练数据包含旧版本代码提示词指定 Compose 版本审查时关注编译警告中文字符串硬编码进代码AI 将资源引用直接替换为字面量审查时全局搜索中文字符串统一改回 R 资源深色模式下颜色错乱只迁移了亮色主题的颜色引用增加深色模式截图对比用例检查 colorScheme 是否完整映射列表滚动性能下降item 内状态提升过度或 Modifier 链过重检查 remember 粒度拆分 item 内容减少不必要重组状态丢失原本 ViewModel 数据被改成 remember严格按状态归属设计迁移退出页面再进入必测5.2 一些平时没人写在文档里的细节最后分享几个我实际踩过的坑这些通常不在官方文档里但遇到之后真的能省一两天时间。第一个是迁移时不要顺手改功能。AI 生成代码时偶尔会“自作聪明”调整布局比如把原来的 wrap_content 改成 match_parent或者重新分配权重。这类改动会让用户明显感受到视觉和行为的差异。我审查时会专门把 AI 的代码和旧 XML 的布局参数做一次对应比对发现不一致就标记改回来再继续。第二个是 keep 规则要及时补。项目启用 R8 混淆后如果迁移时删除了旧的 View 和 XML 引用就要检查是否有 keep 规则还在引用这些类。否则发布后在用户设备上偶发崩溃排查会很痛苦。我习惯在删除旧布局的同一个合并请求里同步清理对应的 proguard 规则和资源瘦身配置。第三个是迁移过程要给 AI 足够多“锚点”。我曾经试着只给 AI 一个 XML 文件不提供主题、不提供现有代码风格结果生成的代码风格和项目完全不一致返工花了很久。AI 的上下文窗口有限所以要在提示词里主动提供关键锚点包括现有代码命名风格、是否使用 Material3、导航库版本、状态管理模式等。锚点越多输出越接近可落地的水平。第四个是在迁移过程中逐步增加自定义语义检查。这个是我后来形成的习惯不太常被提起。AI 生成代码审查通过后我会把一次迁移中用到的所有改写规则沉淀成一个临时检查清单下一个页面复用。随着迁移页面增多这个清单会越来越丰富AI 输出的初稿质量也会肉眼可见地提升。比如从一开始的“每次都忘 contentDescription”到后面提示词里直接固定要求补齐返工频率明显下降。第五个是关于迁移节奏。不要连续几个星期高强度赶迁移AI 看似省力但审查和回归测试仍然消耗专注力。我会把迁移任务和其他开发任务交叉安排给大脑留出缓冲。这个经验听起来不像技术但实操下来它对“不烧心”的贡献比任何工具都大。迁移是一场持久战节奏稳了质量才稳得住。按这套方法跑了几个模块之后我自己最大的感受是用 AI 迁移 Compose 项目真正让人“不烧心”的不是 AI 能写出多少代码而是我们把 AI 放到了一个边界清晰、有人审查、可验证、可回滚的流程里。AI 负责把重复劳动吃走人只需要守住那些它做不了的决定——状态怎么放、边界怎么切、质量怎么验。如果你正准备启动迁移我的建议是从一个低难度的静态页面开始跑通整个“盘点—拆分—提示词—审查—验证—合入”的闭环再慢慢扩大到复杂页面。先建立能信任的流程再追求速度这个过程就不会烧心。