企业官网建设流程全解析

1. 项目缘起：为什么“迁移 Compose”这件事让人烧心

做过 Android 老项目的人大概都有这种体会：一个跑了五六年的工程，Activity 里塞着几百行findViewById，布局文件层层嵌套，RecyclerView 的 Adapter 里混着业务逻辑和 ViewHolder 缓存，改一个列表项要动三四个文件。这时候如果团队决定往 Compose 上迁，第一反应往往不是兴奋，而是头疼——从哪儿下手？全量重写风险太大，增量迁移又怕两套 UI 体系打架。

Meta 这次分享的实践，核心就是回答一个问题：怎么用 AI 把 Compose 迁移这件事从“大工程”拆成“可执行的小任务”。它不是一个“一键转换”的神话，而是一套把 AI 嵌入到迁移流程里的工程方法。适合谁看？如果你手里有存量 Android 项目、团队在评估 Compose 迁移成本、或者你已经在用 AI 辅助编码但效果不稳定，这篇内容应该能给你一些可直接抄的思路。

我先说结论：AI 在 Compose 迁移里最能发挥价值的地方，不是“帮你写 Compose 代码”，而是帮你做模式识别、批量转换和一致性检查。把这三件事做好，迁移的“烧心指数”能降一大半。下面我按实际落地顺序，把整套方法拆开讲。

2. 迁移前的整体设计：先想清楚“迁什么”和“怎么迁”

2.1 全量重写还是增量迁移，这个决策不能拍脑袋

很多团队一上来就问“能不能用 AI 把 XML 直接转成 Compose”，这个问题本身就问偏了。真正要先定的是迁移策略。常见的有三条路：

• 全量重写：新建 Compose 模块，旧代码冻结，新功能全部用 Compose。适合项目生命周期还长、团队人力充足的情况。缺点是并行期长，两套 UI 并存容易出问题。
• 增量迁移：按页面或按模块逐步替换，旧 XML 和新 Compose 通过AndroidView和ComposeView互操作。适合大多数存量项目，风险可控。
• 混合过渡：先迁“无状态展示型”页面，再迁“有复杂交互”的页面，最后处理导航和主题。

Meta 的分享里倾向于增量迁移，理由很实际：AI 在局部转换上的准确率远高于全局重构。你让 AI 一次处理一个屏幕的布局，它能给出可用的 Compose 代码；你让它一次重构整个模块的架构，它大概率会给你一堆看起来对但跑不起来的东西。

提示：迁移策略的决策依据不是“哪个更先进”，而是“哪个能让团队在两周内看到第一个可运行的 Compose 页面”。看到效果，后面的事才好推。

2.2 AI 在迁移流程里的三个定位

把 AI 当成“代码生成器”是最低效的用法。在实际项目里，我把 AI 的介入点分成三层：

这三层里，识别层和校验层最容易被忽略，但恰恰是 AI 最能省时间的地方。转换层反而需要人工介入最多，因为 Compose 的写法不止一种，AI 给的方案不一定符合你团队的代码规范。

2.3 为什么不能指望“一键迁移”

我试过让 AI 直接处理一个包含ConstraintLayout、RecyclerView、ViewPager和自定义 View 的复杂页面。结果它给出的 Compose 代码在语法上没问题，但有几个致命伤：自定义 View 的测量逻辑丢了、ViewPager的页面缓存行为对不上、RecyclerView的局部刷新被简化成了全量重组。这些问题不是 AI 能力不够，而是迁移本身涉及行为等价性判断，而行为等价性需要人来定义。

所以整套方法的设计原则是：AI 做它擅长的批量模式转换，人做它擅长的边界判断和验收。把这条原则记住，后面的实操才不会跑偏。

3. 核心细节拆解：从 XML 到 Compose 的转换要点

3.1 布局转换：ConstraintLayout 是最大的坎

XML 时代最常用的ConstraintLayout，在 Compose 里没有一一对应的写法。AI 通常会给你两种方案：用ConstraintLayout的 Compose 版本，或者用Row/Column/Box加Modifier重新表达。我的经验是：简单约束用 Row/Column 重写，复杂约束才用 Compose 的 ConstraintLayout。

举个例子，一个常见的“头像在左、名字和描述在右、右侧有个按钮”的列表项：

<ConstraintLayout> <ImageView android:id="@+id/avatar" ... /> <TextView android:id="@+id/name" ... /> <TextView android:id="@+id/desc" ... /> <Button android:id="@+id/action" ... /> </ConstraintLayout>

AI 转换时，我会在提示词里明确要求用Row加Column表达：

Row(verticalAlignment = Alignment.CenterVertically) { Avatar() Column(modifier = Modifier.weight(1f)) { Name() Desc() } ActionButton() }

这样写出来的代码比 Compose 版 ConstraintLayout 更易读，性能也更好。关键点在于：不要让 AI 自由发挥，而是给它明确的转换规则。我在项目里维护了一份“XML 组件到 Compose 组件的映射表”，每次让 AI 转换时把这张表作为上下文传进去，输出的一致性会高很多。

3.2 RecyclerView 迁移：Adapter 的拆分逻辑

RecyclerView迁到LazyColumn是另一个高频场景。AI 常见的错误是把 Adapter 里的onCreateViewHolder、onBindViewHolder直接翻译成items块，但忽略了 ViewHolder 里可能藏着的点击事件、状态缓存和局部刷新逻辑。

正确的拆法是三步：

1. 把 item 布局转成独立的 Composable，比如UserItem(user: User, onClick: () -> Unit)。
2. 把 Adapter 的数据源转成LazyColumn的items，用key参数保持和原来stableIds一致的行为。
3. 把notifyItemChanged这类局部刷新，转成状态驱动，让 Compose 自己处理重组。

这里有个坑：原来 Adapter 里如果有payloads做局部更新，迁移后需要用remember加derivedStateOf来模拟，否则会出现整项闪烁。AI 一般不会主动处理这个，需要你在提示词里点出来。

3.3 状态管理：从“手动更新”到“状态驱动”的思维切换

XML 体系里，UI 更新是命令式的：找到 View，设置属性。Compose 是声明式的：状态变了，UI 自动重组。这个思维切换是迁移中最容易出 bug 的地方。

AI 在转换时，如果只做语法层面的翻译，很容易写出这样的代码：

var name by remember { mutableStateOf("") } Text(text = name) // 然后在某个回调里 name = newName

这看起来没问题，但如果原来的逻辑是“多个 View 共享一个数据源”，AI 可能会给每个 View 都创建一个独立的mutableStateOf，导致状态不同步。我的做法是：在让 AI 转换之前，先把页面的状态模型画出来，明确哪些状态是共享的、哪些是本地的，然后把这份状态模型作为提示词的一部分。

注意：状态提升是 Compose 迁移的核心动作。AI 可以帮你写remember和mutableStateOf，但“状态应该放在哪一层”这个决策，必须由人来定。

3.4 主题与样式：别让 AI 自由发挥

XML 里的styles.xml、themes.xml、dimens.xml在 Compose 里对应MaterialTheme、Typography、Shapes和自定义的CompositionLocal。AI 转换时如果不管这些，会直接写死颜色和尺寸，后期维护会很痛苦。

我的做法是提前把设计系统的 token 整理成 Compose 的Theme对象，然后在提示词里告诉 AI：“所有颜色用MaterialTheme.colorScheme，所有间距用dimensionResource对应的常量，不要写硬编码值。”这样输出的代码才能直接进代码库。

4. 实操过程：一个页面的完整迁移记录

4.1 第一步：用 AI 做迁移可行性扫描

拿到一个存量项目，我不会直接开始转代码。先让 AI 帮我做一轮扫描，输出一份“迁移难度清单”。提示词大概是这样：

请分析以下 XML 布局文件和对应的 Activity/Fragment 代码， 输出： 1. 该页面包含哪些 UI 组件 2. 哪些组件可以直接映射到 Compose 3. 哪些组件需要自定义实现 4. 是否存在 RecyclerView、ViewPager、自定义 View 等复杂组件 5. 预估迁移难度（低/中/高）

这一步的价值在于：把“感觉很难”变成“具体哪里难”。扫完一轮，你会发现真正需要人工介入的页面可能只有两三个，其余的都是模式化转换。

4.2 第二步：建立转换规则库

在批量转换之前，我会先手动迁移一个“样板页面”，把转换过程中用到的规则整理成一份文档。这份文档包括：

• 组件映射表（XML 组件 → Compose 组件）
• 命名规范（Composable 函数名、参数名）
• 状态管理约定（什么状态放 ViewModel，什么状态放 Composable 内部）
• 样式引用规则（颜色、字体、间距怎么取）

这份文档就是后续所有 AI 转换的“系统提示词”。实测下来，有规则库和没规则库，AI 输出的可用率差距在 40% 以上。

4.3 第三步：分批转换与人工校验

转换时按“页面”为单位分批进行，每批不超过 5 个页面。每个页面转换完，做三件事：

1. 编译检查：确保没有语法错误和缺失的 import。
2. 行为对比：在模拟器上跑新旧两个版本，对比布局、交互、状态变化。
3. 代码审查：重点看状态管理、副作用处理、性能敏感点。

这里有个实操技巧：让 AI 同时生成一份“迁移说明”，列出它在转换过程中做的假设和取舍。这份说明在代码审查时非常有用，能快速定位可能出问题的地方。

4.4 第四步：互操作层的处理

增量迁移期间，Compose 页面和 XML 页面会共存。两种互操作方式：

• 在 XML 里嵌入 Compose：用ComposeView。
• 在 Compose 里嵌入 XML：用AndroidView。

AI 对这两种互操作的代码生成准确率很高，但要注意生命周期和状态同步问题。比如AndroidView里的 View 如果持有自己的状态，Compose 侧的重组不会自动更新它，需要手动加update回调。

AndroidView( factory = { context -> CustomView(context) }, update = { view -> view.setData(data) } )

update块是必须的，AI 有时候会漏掉，导致数据变了但 View 不刷新。

4.5 第五步：测试与回归

迁移后的页面，我会让 AI 帮忙生成 UI 测试用例，重点是：

• 关键交互路径（点击、输入、滚动）
• 状态变化后的 UI 表现
• 边界情况（空数据、加载中、错误态）

Compose 的测试 API 和传统 Espresso 差别很大，AI 在这方面的知识比较新，生成的测试代码质量参差不齐。我的做法是：让 AI 生成测试场景列表，人工写测试代码。场景列表它给得挺全，代码还是自己写更稳。

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

5.1 AI 转换后编译不过，最常见的原因有哪些

5.2 状态管理相关的坑

最常见的是“状态放错层”。比如一个搜索框，输入文字后要过滤列表。如果query状态放在 Composable 内部，列表数据放在 ViewModel，那过滤逻辑就会很别扭。正确的做法是query也提升到 ViewModel，Composable 只负责展示和回调。

AI 在转换时，如果原来的代码是“EditText 监听 + 手动过滤”，它可能会把query留在 Composable 里。这时候需要在提示词里明确：“所有影响业务逻辑的状态，统一放到 ViewModel。”

5.3 性能问题的排查思路

Compose 的性能问题通常表现为：滚动卡顿、重组次数过多、首帧慢。排查步骤：

1. 用 Layout Inspector 看重组次数。
2. 检查是否有 Composable 在每次重组时创建新对象。
3. 检查LazyColumn的key是否稳定。
4. 检查是否有不必要的derivedStateOf或LaunchedEffect。

AI 生成的代码里，常见性能问题是“在 Composable 里直接创建 Lambda 或对象”，这会导致每次重组都产生新实例。解决办法是用remember包一层，或者把 Lambda 提升到外面。

5.4 互操作层的生命周期问题

ComposeView在 XML 里使用时，如果所在的 Fragment 被销毁重建，Compose 的状态可能会丢失。解决办法是用rememberSaveable保存关键状态，或者在 ViewModel 里持有状态。

AndroidView在 Compose 里使用时，如果 View 需要在onDetachedFromWindow里做清理，要确保 Compose 的DisposableEffect能正确触发。这个细节 AI 经常忽略，需要手动补。

6. 工具链与协作方式的经验

6.1 AI 工具的选择

我用过几种不同的 AI 辅助方式，各有适用场景：

• IDE 内置补全：适合写单个 Composable 时的实时建议，但对跨文件重构帮助有限。
• 对话式 AI：适合做迁移方案设计、规则整理、问题排查，上下文可以给得很足。
• 批量转换脚本：适合模式化转换，比如把一批 XML 文件批量转成 Composable 骨架。

实际项目里，这三者是配合使用的。先用对话式 AI 定规则，再用批量脚本做初转，最后用 IDE 补全做细节调整。

6.2 提示词的组织方式

提示词的质量直接决定输出质量。我的提示词结构一般是：

角色：你是一个 Android Compose 迁移专家。 上下文：以下是项目的转换规则库（粘贴规则）。 任务：把以下 XML 布局和对应代码转成 Compose。 约束： 1. 所有颜色用 MaterialTheme.colorScheme 2. 所有间距用 dimensionResource 3. 状态统一放 ViewModel 4. 列表用 LazyColumn，key 用 item 的 id 输出：Compose 代码 + 迁移说明

关键是约束要具体，不要写“代码要规范”这种模糊要求。约束越具体，AI 的输出越可控。

6.3 团队协作的注意事项

迁移不是一个人的事。团队里需要明确几个角色：

• 规则维护者：负责维护转换规则库，确保多人协作时输出一致。
• 样板页面负责人：先迁一个页面作为参考，其他人照着做。
• 验收负责人：负责对比新旧行为，确保迁移不引入回归。

AI 生成的代码必须经过人工审查才能进主干，这一点不能省。审查的重点不是语法，而是行为等价性和状态管理是否正确。

7. 迁移后的维护与扩展

7.1 代码规范的持续统一

迁移完成后，新旧代码会共存一段时间。这时候需要一份统一的代码规范，覆盖：

• Composable 的命名和参数顺序
• 状态提升的边界
• 副作用的使用场景
• 预览（Preview）的写法

这份规范可以反过来作为 AI 提示词的一部分，让后续新写的 Compose 代码也保持一致。

7.2 渐进式优化

迁移不是终点。Compose 页面跑起来之后，可以逐步做这些优化：

• 把重复的 UI 模式抽成通用 Composable
• 用derivedStateOf减少不必要的重组
• 用remember缓存昂贵计算
• 用LazyLayout的contentType优化复杂列表

这些优化 AI 也能帮忙，但前提是页面已经稳定运行，否则优化和 bug 混在一起很难排查。

7.3 把迁移经验沉淀成资产

一个项目迁完之后，最有价值的不是迁移后的代码，而是迁移过程中积累的规则、提示词和排查经验。这些东西可以复用到下一个项目，让第二次迁移的成本大幅降低。

我在实际项目里的体会是：第一次迁移最烧心，因为什么都要摸索；第二次开始，有了规则库和样板，AI 的输出质量会明显提升，人的介入会越来越少。所以如果你正准备开始迁移，别急着写代码，先花两天时间把规则和流程定下来，后面会省很多事。

最后分享一个小技巧：每次让 AI 转换完一个页面，让它自己生成一份“这个页面迁移后可能的风险点”清单。这份清单不一定全对，但能帮你快速定位需要重点测试的地方。我试过几次，它列出的风险点里大概有六七成是真正需要注意的，这个命中率已经能省不少排查时间了。