企业官网建设流程全解析

1. 从 XML 到 Compose 的迁移，为什么让老 Android 人心里发怵

做过几年 Android 的人，手里多少都攥着几个“祖传”项目：布局文件一层套一层，findViewById写到手酸，RecyclerView.Adapter里塞满了ViewHolder和onBindViewHolder的样板代码。这时候你听说 Compose 好用、声明式、状态驱动，心里痒痒想迁，但一想到“迁完会不会崩”“工作量是不是无底洞”，立马就怂了。我自己第一次动迁移念头的时候，光是数了数项目里的 XML 文件就有一百多个，当场劝退。

后来真正把几个中型项目迁完，我才发现：迁移 Compose 最烧心的从来不是 Compose 本身，而是“怎么迁”这件事没有章法。有人一上来就把整个Activity的setContentView换成setContent，结果一半功能点不动；有人逐行翻译 XML，把ConstraintLayout硬生生搬成ConstraintLayout的 Compose 版本，写出来的代码比原来还长。这些坑我都踩过。

这篇东西就是把我这几轮迁移的经验摊开讲。核心思路其实一句话：让 AI 干重复劳动，你干决策和验收。AI 特别擅长把 XML 布局翻译成 Compose 代码、把RecyclerView的 Adapter 改写成LazyColumn、把主题和尺寸资源对应过去；但它不擅长判断“这个页面该不该现在迁”“这个状态该放哪一层”。所以正确的姿势是：你定策略和边界，AI 做批量转换，你负责 review 和联调。

适合谁看？如果你手上有一个还在用 XML +RecyclerView的 Android 项目，想逐步引入 Compose 又怕翻车，那这篇就是写给你的。不需要你已经精通 Compose，但至少得能看懂@Composable函数长什么样。下面我从整体设计讲到具体实操，中间会穿插大量我实际用过的提示词、验收清单和踩坑记录，你可以直接抄。

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

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

先说结论：全量重写是迁移里最贵、最容易失败的路子。我见过一个团队把整个 App 停掉两个月重写成 Compose，结果上线后崩溃率翻了三倍，因为原来 XML 里那些隐式的测量行为、include复用、ViewStub懒加载，在 Compose 里全都要重新实现一遍，而重写的人根本没意识到这些细节存在。

更现实的做法是增量迁移：新页面直接用 Compose 写，老页面按优先级逐个替换，中间通过ComposeView让两者共存。Android 官方提供的互操作 API 就是干这个的——你可以在 XML 里嵌一个ComposeView，也可以在 Compose 里用AndroidView包一个老控件。这意味着迁移过程中 App 始终是可运行、可发布的，风险被切成了很多小块。

那 AI 在这个增量策略里扮演什么角色？我的定位是**“翻译器 + 批量执行器”**。一个 XML 布局文件，AI 能在几秒内给你一版对应的 Compose 代码；一个RecyclerView.Adapter，AI 能帮你改写成LazyColumn的items写法。这些活儿人做要半天，AI 做要几秒，但前提是你得给它清晰的输入和约束，否则它给你的代码看着像那么回事，跑起来全是坑。

2.2 迁移优先级的判断标准

不是所有页面都值得迁。我一般按三个维度打分：

改动频繁 + 复杂度低 + 收益高的页面优先迁，比如首页、列表页、详情页。那些几年不动的设置页、关于页，留着 XML 完全没问题，别为了“统一技术栈”去动它们，纯属给自己找事。

这里有个反直觉的点：列表页反而是最适合先迁的。因为RecyclerView的样板代码最多，迁成LazyColumn之后代码量能砍掉一半以上，收益立竿见影。而看起来简单的静态页，迁过去收益有限，还容易因为字体、间距的细微差异被设计挑刺。

2.3 AI 辅助迁移的能力边界

用 AI 迁移，你得清楚它哪里强、哪里弱，不然期望错位会很痛苦。

AI 擅长的：XML 到 Compose 的语法翻译、RecyclerView.Adapter到LazyColumn的结构改写、资源引用（@color、@dimen、@string）的对应、样板代码生成、命名规范统一。

AI 不擅长的：判断状态该提升到哪一层、处理复杂的自定义 View 测量逻辑、理解你项目里那些“历史遗留的隐式约定”、保证迁移后视觉像素级一致。这些必须人来把关。

我踩过最典型的一个坑：让 AI 把一个带NestedScrollView的页面转成 Compose，它直接给我套了个Column加verticalScroll，看起来对，但原来NestedScrollView和内部RecyclerView的嵌套滚动行为完全丢了，用户滑到一半就卡住。这种问题 AI 不会主动告诉你，因为它不知道你的业务依赖那个滚动行为。

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

3.1 用 AI 翻译 XML 布局的正确姿势

直接甩一个 XML 文件给 AI 说“转成 Compose”，你大概率会得到一坨能编译但很丑的代码。我摸索出来的流程是这样的：

第一步，先让 AI 做结构分析，而不是直接翻译。我会把 XML 贴进去，然后问：“这个布局的层级结构是什么？哪些是容器，哪些是叶子节点？有没有可以合并的层级？”这一步的目的是让 AI 先理解布局意图，而不是机械翻译。很多时候 AI 会指出“这个LinearLayout套LinearLayout其实可以合并”，这种优化在翻译前做掉，比翻译后再改省事。

第二步，给出明确的翻译约束。我的提示词模板大概是这样：

把这个 XML 布局翻译成 Jetpack Compose 代码，要求： 1. 使用 Material3 组件 2. 尺寸用 dp，字体用 sp，颜色引用项目已有的 Color 资源 3. 不要用 ConstraintLayout 的 Compose 版本，优先用 Column/Row/Box 4. 列表部分用 LazyColumn 5. 每个 Composable 函数加 @Preview 6. 保持原有的 id 命名，方便后续查找

这几条约束里，“优先用 Column/Row/Box 而不是 ConstraintLayout”是最关键的一条。Compose 里的ConstraintLayout虽然能用，但写起来比 XML 还啰嗦，而且失去了 Compose 声明式的优势。绝大多数 XML 里的ConstraintLayout，用Column+Row+Modifier的组合都能表达，而且更清晰。

第三步，人工 review 三个重点。AI 给的代码我必看三处：一是Modifier的顺序，因为 Compose 里Modifier顺序会影响最终效果，padding在前还是在后结果完全不同；二是状态相关的部分，AI 经常把本该remember的东西写成普通变量；三是LazyColumn的key，AI 默认不给 key，列表数据变化时会有性能问题。

3.2 RecyclerView 迁移到 LazyColumn 的关键差异

这是迁移里最值钱的部分，也是坑最多的部分。RecyclerView和LazyColumn看着都是列表，但心智模型完全不同。

RecyclerView是命令式的：你给它一个 Adapter，它问你要 ViewHolder，你bind数据进去。LazyColumn是声明式的：你告诉它“对于列表里的每一项，渲染成什么样”，它自己管复用。

迁移时几个必须注意的点：

第一，ViewHolder里的状态要重新想。原来ViewHolder里可能存了一些临时状态（比如某个按钮的选中态），在 Compose 里这些状态应该提升到items的 lambda 外面，用remember管理，或者干脆提到 ViewModel。我见过有人直接把ViewHolder的字段翻译成 Composable 里的局部变量，结果滚动一下状态就乱了。

第二，notifyItemChanged这类方法全部删掉。Compose 是状态驱动的，你改了数据源，UI 自动更新。如果 AI 给你的代码里还有notifyDataSetChanged的影子，说明它没理解 Compose 的模型，要打回去重写。

第三，key一定要给。LazyColumn的items函数有个key参数，给它一个稳定唯一的 id，列表增删时 Compose 才能正确复用。不给 key 的话，列表数据一变整个列表都会重组，性能直接崩。

一个典型的迁移对照：

// 迁移前：RecyclerView.Adapter class UserAdapter(private val users: List<User>) : RecyclerView.Adapter<UserAdapter.VH>() { class VH(view: View) : RecyclerView.ViewHolder(view) { val name: TextView = view.findViewById(R.id.name) } override fun onBindViewHolder(holder: VH, position: Int) { holder.name.text = users[position].name } // ... 省略其他样板 } // 迁移后：LazyColumn @Composable fun UserList(users: List<User>) { LazyColumn { items(users, key = { it.id }) { user -> Text(text = user.name, modifier = Modifier.padding(16.dp)) } } }

代码量从几十行降到几行，这就是迁移列表页的收益。

3.3 主题、尺寸、字符串资源的对应

XML 时代我们用@color/primary、@dimen/spacing_16、@string/app_name，Compose 里这些引用方式变了，但资源本身不用动。

颜色方面，Compose 用MaterialTheme.colorScheme.primary这类语义化引用。迁移时我会让 AI 把@color/xxx映射到最接近的colorScheme角色，映射不了的再单独定义。这里有个经验：别急着把老的颜色资源全删掉，迁移期间两套并存很正常，等所有页面迁完再清理。

尺寸方面，@dimen/spacing_16直接换成16.dp就行，Compose 里不需要为每个尺寸定义资源，直接写字面量反而更清晰。但要注意dp和sp的区别：尺寸用dp，字体用sp，AI 有时候会搞混，review 时要盯一下。

字符串方面，stringResource(R.string.xxx)替代getString(R.string.xxx)，这个 AI 基本不会错。但要注意stringResource是@Composable函数，只能在 Composable 里调用，如果 AI 把它用在普通函数里，编译会报错。

3.4 互操作：让新旧代码和平共处

迁移期间，XML 和 Compose 必然共存。两种互操作方式：

XML 里嵌 Compose：用ComposeView，在 XML 里声明，然后在代码里setContent。适合老页面里想局部用 Compose 的场景。

Compose 里嵌 XML：用AndroidView，把老的自定义 View 包进来。适合那些暂时不想迁的自定义控件。

这里有个坑：AndroidView里的 View 生命周期和 Compose 不同步，如果那个 View 依赖onResume之类的回调，可能会出问题。我的做法是，能用 Compose 重写的自定义 View 尽量重写，实在复杂的才用AndroidView包，并且加注释说明为什么。

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

4.1 环境准备与依赖配置

迁移前先把环境搭好。build.gradle里需要开启 Compose：

android { buildFeatures { compose = true } composeOptions { kotlinCompilerExtensionVersion = "1.5.1" } } dependencies { implementation(platform("androidx.compose:compose-bom:2024.02.00")) implementation("androidx.compose.ui:ui") implementation("androidx.compose.material3:material3") implementation("androidx.activity:activity-compose:1.8.2") implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.7.0") }

用 BOM 管理 Compose 版本，省得一个个对版本号。activity-compose提供setContent，lifecycle-viewmodel-compose提供viewModel()函数，这两个是迁移必备。

注意：Kotlin 版本和 Compose 编译器版本必须匹配，不匹配会报一堆看不懂的错。升级 Kotlin 时记得同步查一下对应的 Compose 编译器版本。

4.2 用 AI 批量转换布局文件的流程

我实际的操作流程是这样的：

第一步，收集待迁移的布局文件清单。我会按前面说的优先级排序，一次处理一批，比如先处理首页相关的 5 个布局。

第二步，逐个喂给 AI，但一次只喂一个。别贪心一次喂十个，AI 会串味。每个布局单独对话，转换完立刻 review。

第三步，把转换结果放到一个临时目录，先不替换原文件。这样出问题可以随时回退。

第四步，写一个简单的 Compose 预览，肉眼比对。我会给每个转换后的 Composable 加@Preview，在 Android Studio 里看效果，和原来的 XML 预览对比。这一步能抓出大部分布局问题。

第五步，接入真实数据联调。预览对了不代表真机对，尤其是涉及状态和交互的部分，必须跑起来看。

这个流程走下来，一个中等复杂度的布局，从转换到验收大概 15 到 30 分钟，比手写快得多，而且质量更稳定。

4.3 状态管理的迁移：从 ViewModel 到 Compose

XML 时代，状态通常放在 ViewModel 里，通过LiveData或ObservableField暴露给 View。Compose 时代，推荐用StateFlow或mutableStateOf。

迁移时，LiveData不用急着换，Compose 可以用observeAsState()消费LiveData：

@Composable fun UserScreen(viewModel: UserViewModel) { val users by viewModel.users.observeAsState(emptyList()) UserList(users) }

这样 ViewModel 几乎不用改，迁移成本很低。等页面稳定了，再考虑把LiveData换成StateFlow。

但有个坑：observeAsState的初始值必须给，不给的话第一次组合时是 null，容易空指针。我一般给个空列表或空对象，别给 null。

4.4 迁移后的验收清单

每迁完一个页面，我会过一遍这个清单：

• 布局在深色模式下正常吗
• 字体缩放（系统设置里调大字体）后会不会错位
• 列表滚动流畅吗，有没有卡顿
• 状态在配置变更（旋转屏幕）后保留吗
• 返回栈行为正常吗
• 无障碍（TalkBack）能正常朗读吗

这几条里，字体缩放和深色模式是最容易翻车的。XML 时代很多硬编码的尺寸和颜色，迁到 Compose 后如果没处理好，字体一放大就溢出，深色模式下一片惨白。我一般会在迁移时就把硬编码的颜色换成MaterialTheme.colorScheme的引用，尺寸尽量用sp而不是dp来写字体。

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

5.1 AI 转换结果常见问题速查

5.2 我踩过的三个典型坑

坑一：Modifier顺序搞反。有一次 AI 给我生成的代码里，Modifier.padding(16.dp).background(Color.Red)，结果背景色只覆盖了内容区，padding 区域是透明的。正确顺序应该是Modifier.background(Color.Red).padding(16.dp)，背景先铺满再内缩。这个坑很隐蔽，预览时不容易发现，真机上才看出来。

坑二：LazyColumn嵌套滚动冲突。一个页面里LazyColumn套在Column的verticalScroll里，直接崩了，报“Vertically scrollable component was measured with an infinity maximum height constraints”。原因是外层verticalScroll给了无限高度，LazyColumn不知道怎么算。解决办法是给LazyColumn一个固定高度，或者干脆去掉外层滚动，让LazyColumn自己滚。

坑三：remember用错位置。AI 有时候把remember写在items的 lambda 外面，导致所有列表项共享同一个状态。正确的做法是写在 lambda 里面，每个 item 有自己的状态。这个错误在列表项有独立交互（比如点赞按钮）时特别明显，点一个全亮了。

5.3 性能排查：迁移后卡顿怎么办

迁移后如果发现卡顿，先别怀疑 Compose 本身，八成是代码写法有问题。排查顺序：

第一，看有没有不必要的重组。用 Layout Inspector 的 recomposition 计数功能，看看哪个 Composable 重组次数异常高。常见原因是把大对象直接传进 Composable，导致每次父级重组子级都跟着重组。解决办法是用remember缓存，或者把参数拆细。

第二，看LazyColumn的 key。没给 key 的话，列表数据一变整个列表重组，性能直接崩。给上稳定 key，性能立竿见影。

第三，看有没有在 Composable 里做重活。比如在 Composable 里直接读数据库、做复杂计算，这些应该放到 ViewModel 里。Composable 应该只负责渲染，不负责计算。

我实测下来，一个迁移前用RecyclerView流畅的列表，迁移后如果按规范写，流畅度只会更好，因为 Compose 的复用机制比RecyclerView更智能。如果变卡了，一定是写法问题，不是 Compose 的锅。

5.4 团队协作时的注意事项

如果是团队迁移，有几件事必须提前对齐：

命名规范统一。Composable 函数用大驼峰，和普通函数区分开。参数命名、Modifier 参数的位置（惯例是第一个可选参数）都要统一，不然 review 时全是风格问题。

状态管理方案统一。是用StateFlow还是LiveData，状态提升到哪一层，这些要定好，不然每个人写法不一样，后期维护很痛苦。

迁移进度可视化。我会维护一个表格，列出所有待迁移页面、负责人、状态（待迁/迁移中/已验收），每周同步一次。这样谁在做什么一目了然，也方便排优先级。

代码 review 重点。迁移的 PR 我重点看三处：Modifier 顺序、状态管理、key 的使用。这三处对了，基本不会有大问题。

6. 迁移节奏把控与经验收尾

迁移这事，节奏比技术更重要。我的建议是小步快跑，每个迭代迁一到两个页面，迁完立刻上线观察。别攒一个大版本一次性上，出了问题不好定位。我见过一个团队攒了二十个页面的迁移一起发，结果崩溃率飙升，回滚都回不干净，因为改动太分散了。

另外，别追求 100% 迁移。有些页面用 XML 挺好的，迁过去纯属折腾。我的项目里到现在还留着几个 XML 页面，它们稳定、没人动、迁了也没收益，那就留着。技术栈统一是手段，不是目的。

最后分享一个我常用的提示词收尾技巧：每次让 AI 转换完代码，我会追加一句“指出这段代码里可能存在的性能问题或不符合 Compose 最佳实践的地方”。AI 经常会指出一些我自己没注意到的点，比如某个Modifier可以提取、某个状态可以提升。把它当成一个随时在线的 code reviewer，比单纯当翻译器价值大得多。

迁移过程中最爽的时刻，是看着一个原来两百行的 Adapter 变成二十行的LazyColumn，而且跑得还更顺。那种感觉，值得你花时间把这事做对。