企业官网建设流程全解析

1. 为什么“迁移 Compose 项目”这件事让 Android 开发者集体头疼

做过几年 Android 的人应该都有体会：一个跑了三五年的老项目，里面塞满了 Java、Kotlin、XML 布局、自定义 View、第三方库，突然要往 Jetpack Compose 上迁，第一反应不是“怎么迁”，而是“从哪下手”。Compose 不是换个 UI 框架那么简单，它把命令式的 View 树换成了声明式的重组模型，把 findViewById、Adapter、notifyDataSetChanged 这一整套心智模型全部推翻。你让一个熟悉 RecyclerView 的兄弟去写 LazyColumn，他能写出来，但写出来的东西性能可能还不如原来的 ListView。

Meta 这次分享的“用 AI 迁移 Compose 项目不烧心”，核心不是教你某个 API 怎么调，而是把 AI 当成一个“结对迁移工程师”来用。这个定位很关键。很多人对 AI 写代码的期待是“一键转换”，结果发现生成的代码编译不过、状态管理混乱、副作用到处飞，最后比手写还累。问题不在于 AI 不行，而在于迁移这件事本身是有结构、有优先级、有取舍的工程活动，你把一个需要架构判断的任务直接丢给模型，它当然给你一堆看似合理实则埋雷的代码。

这篇文章我会围绕 Meta 这套思路，把“AI 辅助 Compose 迁移”拆成可复现的流程。适合两类人看：一是手里有存量 Android 项目、正在评估 Compose 迁移成本的团队技术负责人；二是已经上手 Compose、但面对老代码不知道如何系统推进的一线开发。我会讲清楚每一步为什么这么做、AI 在哪个环节介入最有效、哪些坑必须人工兜底，以及我自己在实际操作中踩过的雷。

2. 迁移前的整体设计与思路拆解

2.1 先想清楚：全量重写还是渐进式迁移

这是迁移的第一个决策点，也是 AI 介入方式的分水岭。全量重写的意思是新建一个 Compose 模块，把老页面逐个重写，老代码保持可运行直到新页面替换完成。渐进式迁移则是同一个页面里 XML 和 Compose 混用，通过ComposeView或AndroidView互相嵌套，边跑边换。

Meta 的分享里倾向于渐进式为主、局部重写为辅。原因很实际：一个中型 App 动辄几十上百个页面，全量重写意味着几个月内新旧两套 UI 并存，测试成本、回归风险、人力投入都是指数级上升。而渐进式迁移允许你按页面、按模块推进，每个迭代都能交付可验证的成果。

但渐进式有个前提：你的项目得先具备混用的基础条件。这包括 Compose 的 BOM 版本、Kotlin 版本、AGP 版本要匹配，buildFeatures { compose true }要打开，Compose 编译器插件要配置好。这些基础工作不做，后面 AI 生成的代码你连编译都过不了。

提示：迁移前先在一个独立分支上把 Compose 环境跑通，写一个最简单的Text("hello")页面确认能编译能运行，再开始动老代码。这一步花半小时，能省后面几天的环境排查。

2.2 AI 在迁移链路里到底该站在哪个位置

这是整套方法的核心认知。很多人用 AI 迁移失败，是因为把 AI 放在了“全权负责”的位置，期望它读一遍老代码就吐出可用的 Compose 版本。正确的定位是：AI 负责模式识别和代码草稿，人负责架构决策和边界校验。

具体来说，AI 擅长的环节有三个。第一是识别可迁移单元，比如它能快速扫描一个 XML 布局文件，判断哪些部分适合直接转成 Compose、哪些依赖自定义 View 需要保留。第二是生成等价代码草稿，把 RecyclerView 的 Adapter + ViewHolder + item 布局这套模板代码，转成 LazyColumn + item 的写法。第三是解释差异，当你对某段转换结果有疑问时，让 AI 对比新旧两套实现的语义差异。

AI 不擅长的环节同样明确。状态提升（state hoisting）的边界怎么划、副作用该放在哪一层、重组范围如何控制，这些需要结合具体业务逻辑判断，AI 给的方案往往是“能跑但不够优”。还有跨模块的依赖关系、老代码里隐藏的反射调用、第三方 View 的生命周期绑定，这些 AI 看不到全貌，必须人工兜底。

2.3 迁移优先级的排序逻辑

不是所有页面都值得优先迁移。Meta 的思路是按“收益/成本比”排序，我把它整理成一个可操作的判断表：

这个排序的意义在于：先用高优先级页面跑通“AI 辅助迁移”的完整流程，积累提示词模板和校验清单，再往复杂页面推进。上来就啃硬骨头，很容易在第一个页面就卡死，团队信心直接崩掉。

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

3.1 给 AI 的输入怎么组织才有效

AI 生成代码的质量，八成取决于你喂给它的上下文。直接把一个 800 行的 Activity 丢进去，让它“转成 Compose”，结果必然是灾难。有效的做法是按迁移单元切分输入，每个单元包含四类信息。

第一类是目标布局文件，也就是要转换的 XML。第二类是关联的 Kotlin/Java 代码，包括 Activity/Fragment 里对这个布局的操作逻辑。第三类是数据模型，让 AI 知道 item 的数据结构长什么样。第四类是迁移约束，明确告诉它哪些必须保留、哪些可以改。

我常用的提示词结构是这样的：

你是一名资深 Android 工程师，正在把一个 XML 布局迁移到 Jetpack Compose。 迁移目标： [粘贴 XML 布局] 关联逻辑： [粘贴 Activity/Fragment 中操作该布局的代码] 数据模型： [粘贴相关 data class] 约束条件： 1. 保持现有的业务逻辑不变，不要自行增减功能 2. 列表使用 LazyColumn，不要用 Column + forEach 3. 状态用 remember + mutableStateOf 管理，需要跨重组保留的用 rememberSaveable 4. 副作用统一用 LaunchedEffect 或 SideEffect，说明选择理由 5. 输出完整的 Composable 函数，并标注哪些地方需要人工确认

这个结构的关键在最后一条：要求 AI 标注不确定的地方。这比让它假装什么都会要有用得多。AI 标出来的“需要人工确认”点，往往就是迁移的真正风险点。

3.2 RecyclerView 到 LazyColumn 的转换要点

这是迁移里最高频、也最容易出问题的场景。RecyclerView 和 LazyColumn 看着都是列表，但底层模型完全不同。RecyclerView 是命令式的，你手动创建 ViewHolder、手动绑定数据、手动通知刷新；LazyColumn 是声明式的，你描述“列表长什么样”，重组机制负责更新。

AI 转换时最常见的三个错误，我逐个说。

第一个错误是把 Adapter 的逻辑直接搬进 item 里。RecyclerView 的onBindViewHolder里可能有复杂的条件判断、图片加载、点击事件绑定，AI 容易把这些全部塞进 LazyColumn 的 item lambda 里，导致每次重组都重新执行。正确做法是把这些逻辑拆成独立的 Composable，用remember缓存不随重组变化的部分。

第二个错误是忽略 key 的设置。RecyclerView 有stableIds，LazyColumn 有key参数，作用类似但更重要。不设 key 的话，列表增删时 Compose 会按位置重组，导致状态错乱。AI 经常忘记加 key，你需要手动补上：

LazyColumn { items( items = userList, key = { user -> user.id } ) { user -> UserItem(user = user, onClick = { onUserClick(user.id) }) } }

第三个错误是分页加载的触发时机。RecyclerView 用addOnScrollListener判断滚动到底部，LazyColumn 要用LazyListState配合derivedStateOf或者snapshotFlow。AI 生成的版本经常是直接在 item 里判断if (index == list.size - 1) loadMore()，这在重组频繁时会重复触发。稳妥的写法是：

val listState = rememberLazyListState() val shouldLoadMore by remember { derivedStateOf { val lastVisible = listState.layoutInfo.visibleItemsInfo.lastOrNull()?.index ?: 0 lastVisible >= userList.size - 3 } } LaunchedEffect(shouldLoadMore) { if (shouldLoadMore) loadMore() }

注意：derivedStateOf的作用是减少不必要的重组，把“是否接近底部”这个判断从每次滚动都触发，变成只在结果变化时触发。这个细节 AI 经常漏掉，需要人工补。

3.3 状态管理的迁移是真正的深水区

XML 时代，状态散落在各处：View 的 visibility、TextView 的 text、Adapter 的 dataList、Activity 的成员变量。迁移到 Compose，这些状态需要重新组织。AI 能帮你把textView.text = "xxx"转成Text("xxx")，但状态该放在哪一层、由谁持有、怎么流转，这是架构问题。

Meta 分享里强调的一个原则是状态提升到最近的共同祖先。举个例子，一个搜索页面有输入框和结果列表，输入框的内容和列表的筛选条件都依赖搜索关键词，那这个关键词就应该提升到包含两者的父 Composable 里，而不是各自维护一份。

AI 在处理这类问题时，倾向于把状态放在最内层，因为那样改动最小。你需要主动要求它做状态提升：

请检查这段代码的状态管理，把可以提升的状态提升到合适的层级， 并说明每个状态为什么放在这个位置。区分 UI 状态和业务状态。

区分 UI 状态和业务状态很重要。UI 状态比如展开/收起、选中项，用remember就够了；业务状态比如登录用户、购物车内容，应该放在 ViewModel 里。AI 经常把两者混在一起，全塞进 Composable 的remember里，导致配置变更后状态丢失。

3.4 副作用 API 的选择不能靠猜

Compose 提供了一堆副作用 API：LaunchedEffect、SideEffect、DisposableEffect、rememberCoroutineScope、produceState。每个的适用场景不同，选错了轻则逻辑不执行，重则内存泄漏。

AI 生成代码时，最常用的是LaunchedEffect，因为它最通用。但通用不等于正确。我整理了一个选择对照表，迁移时逐条核对：

collectAsStateWithLifecycle这个点特别值得说。AI 默认生成collectAsState，但它在页面不可见时仍然收集数据流，浪费资源。迁移时应该统一换成collectAsStateWithLifecycle，需要引入lifecycle-runtime-compose依赖。这个改动 AI 不会主动做，得你在提示词里明确要求。

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

4.1 环境准备与依赖配置

动手之前，先把环境配好。这部分看着枯燥，但配错了后面全是坑。以下是我实测可用的配置组合，版本会随时间变化，但配置项的逻辑不变。

项目根目录的libs.versions.toml（如果你用版本目录管理）：

[versions] composeBom = "2024.09.00" kotlin = "1.9.24" agp = "8.5.0" lifecycle = "2.8.4" [libraries] androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" } androidx-compose-ui = { group = "androidx.compose.ui", name = "ui" } androidx-compose-material3 = { group = "androidx.compose.material3", name = "material3" } androidx-lifecycle-runtime-compose = { group = "androidx.lifecycle", name = "lifecycle-runtime-compose", version.ref = "lifecycle" }

模块的build.gradle.kts：

android { buildFeatures { compose = true } composeOptions { kotlinCompilerExtensionVersion = "1.5.14" } } dependencies { implementation(platform(libs.androidx.compose.bom)) implementation(libs.androidx.compose.ui) implementation(libs.androidx.compose.material3) implementation(libs.androidx.lifecycle.runtime.compose) }

这里有个容易忽略的点：Compose 编译器版本和 Kotlin 版本必须严格对应。Kotlin 1.9.24 对应编译器扩展 1.5.14，版本对不上会直接编译失败，报错信息还特别晦涩。我建议直接查官方兼容性表，别凭记忆填。

4.2 用 AI 完成第一个页面的完整迁移

选一个简单的展示型页面作为第一个迁移对象。我拿一个用户详情页举例，老代码是一个 XML 布局加一个 Activity。

第一步，把 XML 布局和 Activity 代码一起发给 AI，用 3.1 节的提示词结构。AI 会返回一个 Composable 函数草稿。这时候不要急着用，先做三件事。

第一件，核对 UI 结构。把 AI 生成的 Composable 和原 XML 逐层对比，看有没有漏掉的 View、错位的层级、丢失的约束。XML 里的ConstraintLayout约束关系，AI 有时会转成嵌套的Column/Row，结构对了但性能差了。能扁平化的尽量扁平化。

第二件，核对交互逻辑。原 Activity 里的点击事件、文本变化监听、可见性切换，逐个确认在新代码里有对应实现。AI 容易漏掉的是那些写在onCreate之外的逻辑，比如onResume里的刷新。

第三件，核对状态来源。原代码里从 Intent、ViewModel、SharedPreferences 拿的数据，在新代码里是否通过参数或 ViewModel 正确获取。这一步最容易出问题，因为 AI 看不到数据的完整来源。

4.3 混合模式下的互操作处理

渐进式迁移绕不开互操作。两种方向都要会：在 Compose 里用老 View，在老 XML 里用 Compose。

在 Compose 里嵌入老 View，用AndroidView：

AndroidView( factory = { context -> MyLegacyView(context).apply { // 初始化配置 } }, update = { view -> // 状态变化时更新 View view.setData(currentData) } )

factory只执行一次，update在每次重组时执行。这个区别很关键，初始化逻辑放factory，数据绑定放update。AI 经常把两者搞混，把初始化放update里导致重复创建。

在老 XML 里嵌入 Compose，用ComposeView：

val composeView = findViewById<ComposeView>(R.id.compose_view) composeView.setContent { AppTheme { MyComposable() } }

或者在 XML 里直接声明：

<androidx.compose.ui.platform.ComposeView android:id="@+id/compose_view" android:layout_width="match_parent" android:layout_height="wrap_content" />

互操作有个性能陷阱：跨边界的重组代价高。频繁在 Compose 和 View 之间传递状态，会导致两边都频繁刷新。迁移时尽量让边界清晰，一个页面要么以 Compose 为主，要么以 View 为主，不要深度嵌套。

4.4 迁移后的验证清单

代码写完不等于迁移完成。我整理了一份验证清单，每个页面迁移后逐项过：

• 配置变更（旋转屏幕）后状态是否正确保留
• 深色模式切换后颜色是否正确
• 字体缩放后布局是否错乱
• 列表快速滚动是否有卡顿或错位
• 页面退出后是否有资源未释放（用 Profiler 看）
• 无障碍功能（TalkBack）是否正常朗读
• 返回栈行为是否和原来一致

这份清单里的每一项，我都遇到过 AI 生成的代码出问题。尤其是配置变更和资源释放，AI 基本不会主动考虑，必须人工验证。

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

5.1 AI 生成代码编译不过的排查顺序

这是最高频的问题。别急着改代码，按顺序排查效率最高。

先看导入。AI 生成的代码经常缺 import 或者 import 了错误的包，尤其是androidx.compose.material3和androidx.compose.material混用。Material3 和 Material2 的组件名有重叠但 API 不同，混用会报一堆莫名其妙的错。

再看版本兼容。某个 API 在当前 Compose 版本里不存在，通常是 AI 用了更新版本的 API。查一下这个 API 是哪个版本引入的，要么升级依赖，要么换等价写法。

最后看类型推断。Compose 大量使用 lambda 和泛型，AI 生成的代码有时类型推断失败，需要显式标注类型。这类错误编译器会给出具体位置，按提示补类型即可。

5.2 重组性能问题的定位方法

迁移后页面卡顿，八成是重组范围失控。定位方法是用 Layout Inspector 的重组计数功能，看哪个 Composable 重组次数异常。

常见的重组失控原因有三个。一是状态读取位置太靠上，一个顶层 Composable 读了状态，导致整个子树重组。解决办法是把状态读取下移到真正需要它的地方。二是lambda 未稳定，每次重组都创建新的 lambda 实例，导致接收它的 Composable 被判定为不稳定。用remember包裹或者把 lambda 提到外面。三是数据类不稳定，包含List、Map等可变集合的 data class 会被 Compose 判定为不稳定，用ImmutableList或者加@Stable注解。

提示：Compose 编译器会生成稳定性报告，在build.gradle.kts里加编译器参数-P plugin:androidx.compose.compiler.plugins.kotlin:reportsDestination=...就能导出。迁移期间定期看这份报告，能提前发现稳定性问题。

5.3 状态丢失与错乱的典型场景

配置变更后状态丢失，通常是用了remember而不是rememberSaveable。但rememberSaveable也不是万能的，它要求状态能被序列化。自定义对象需要实现Saver，这一步 AI 基本不会主动做。

列表状态错乱，通常是 key 的问题。key 重复、key 不稳定（比如用 index 当 key）、key 类型不一致，都会导致 Compose 复用错误的 item。检查方法很简单：给 key 加个日志，看列表变化时 key 是否稳定。

还有一种隐蔽的情况：状态被多个 Composable 共享但更新不同步。这通常是状态提升没做到位，两个 Composable 各自持有了一份状态副本。解决办法是找到共同祖先，把状态提升上去，通过参数传递。

5.4 常见问题速查表

这个表是我迁移过程中逐步积累的，每次遇到新问题就补一行。建议你也维护一份自己的，比查文档快得多。

5.5 几个 AI 不会告诉你的实操心得

第一个心得：让 AI 生成测试代码。迁移后的 Composable 逻辑对不对，写 UI 测试验证最靠谱。AI 生成测试代码的质量比生成业务代码高，因为测试的结构更模板化。用createComposeRule写几个关键交互的测试，能挡住大部分回归问题。

第二个心得：保留老代码的注释。老代码里那些“这里不能改，改了会崩”的注释，是前人踩坑留下的。迁移时把这些注释一起带过去，AI 不会主动保留，你得手动搬。

第三个心得：分批提交，每批可回滚。迁移一个大页面时，不要一次性改完再提交。按“布局转换、状态迁移、副作用调整、互操作处理”分几次提交，每次都能编译能运行。出问题时git bisect能快速定位是哪一步引入的。

第四个心得：AI 的提示词要迭代。第一次生成的代码不理想，别急着放弃，把问题反馈给 AI 让它修正。比如“这个列表没有加 key，请补上并说明为什么 key 很重要”，多轮对话的效果远好于一次性生成。我通常会迭代三到五轮，直到代码质量稳定。

6. 迁移节奏与团队协作的几点经验

一个人迁移和团队迁移是两回事。团队迁移最大的风险是风格不统一：张三用remember管状态，李四用 ViewModel，王五直接在 Composable 里发网络请求。三个月后代码库变成一锅粥。

我的做法是先定一份迁移规范，哪怕只有一页纸。内容包括：状态放哪一层、副作用用哪个 API、列表怎么设 key、互操作边界怎么划、命名怎么统一。这份规范让 AI 也遵守，在提示词里带上，生成的代码风格就一致了。

节奏上，我建议每周迁移一到两个页面，不要贪多。每个页面迁移完做一次代码评审，把新发现的问题补进规范和速查表。这样推进三个月，团队对 Compose 的掌握程度和迁移效率都会有明显提升。

还有一点：别追求一次迁移到位。有些页面迁移后性能不如原来，有些交互细节对不上，这很正常。先保证功能正确，性能优化和细节打磨放到后面。迁移是长跑，不是冲刺。

最后分享一个我自己的判断标准：当一个页面的 Compose 版本代码量比 XML 版本少 30% 以上，且没有明显的性能退化，这次迁移就算成功了。达不到这个标准，说明要么迁移方式有问题，要么这个页面本来就不适合迁移。接受“不是所有页面都值得迁移”这个事实，比强行迁移所有页面要明智得多。