企业官网建设流程全解析

1. 为什么 Compose 迁移这件事让 Android 团队集体头疼

做过几年 Android 的兄弟应该都有体会，Jetpack Compose 刚出来那阵子，大家的态度基本分两派：一派觉得声明式 UI 是未来，早迁早享受；另一派看着手里几十万行的 View 体系代码，默默把迁移计划排到了下个世纪。我属于后者，直到去年接手一个中型项目，被逼着认真研究了一遍迁移路径，才发现这事没想象中那么可怕，但也没那么简单。

传统 View 体系迁移到 Compose，核心痛点其实就三个：XML 布局怎么转、自定义 View 怎么重写、状态管理和数据流怎么对接。这三个问题任何一个单独拎出来都不算致命，但叠在一起，再加上业务不能停、版本还得照常发，就变成了典型的"边开车边换轮胎"。Meta 这次分享的 AI 辅助迁移思路，本质上就是给这个换轮胎的过程加了一套自动化工具链，把大量机械性的转换工作交给模型去做，人只负责审核和收尾。

这篇文章我会把整个迁移流程拆开讲清楚：从前期评估、AI 辅助转换的具体做法、到迁移后的验证和踩坑记录。适合正在考虑 Compose 迁移的 Android 开发者、技术负责人，也适合对 AI 辅助代码重构感兴趣的同学。不管你是刚接触 Compose 的新手，还是已经写过一些 Compose 代码但没做过大规模迁移的老手，应该都能从里面找到能直接用的东西。

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

2.1 先搞清楚哪些能迁、哪些不该迁

很多人一上来就想全量迁移，这是最容易翻车的地方。我的建议是先把项目里的界面按复杂度分个级，不同级别用不同策略。

这个分级不是拍脑袋定的。简单静态页之所以优先，是因为它们的 XML 结构规整，AI 模型见过的样本多，转换准确率能到 85% 以上。而自定义 View 重度页，尤其是那些继承 View 自己 onDraw 的，AI 基本帮不上忙，硬转反而会引入一堆难以排查的 bug。

提示：迁移优先级不要按业务重要性排，要按"转换收益/风险比"排。先把低风险高收益的页面吃掉，团队信心和工具链都能快速跑通。

2.2 为什么选择 AI 辅助而不是纯手工或纯脚本

纯手工迁移的问题很明显：一个中等复杂度的页面，熟练工也得半天到一天，几十个页面就是几个月的人力。纯脚本方案（比如正则替换 XML）听起来美好，但 Compose 的声明式结构和 XML 的命令式结构差异太大，脚本能处理的只有最表层的东西，稍微复杂点的布局嵌套就歇菜了。

AI 辅助的价值在于它能理解语义而不只是语法。举个例子，一个 LinearLayout 嵌套 RelativeLayout 再嵌套 TextView 的结构，脚本只能机械地一层层转，但 AI 能识别出"这其实就是一个带图标和文字的横向排列"，直接给你生成一个 Row + Icon + Text 的 idiomatic Compose 代码。这种语义级的转换，是脚本做不到的。

Meta 分享的思路里，AI 承担的主要是三类工作：XML 到 Composable 的初稿生成、状态提升的建议、以及常见模式的批量替换。人负责的是审核、边界情况处理和性能调优。这个分工的核心逻辑是：让 AI 做它擅长的模式匹配，让人做需要判断力的决策。

2.3 迁移节奏的把控

我见过太多团队一上来就搞"迁移冲刺"，两周内把所有页面都转完，结果线上 crash 率飙升，又花一个月回滚和修 bug。正确的节奏应该是小步快跑：

• 第一周：选 2-3 个简单页面做试点，跑通工具链，建立代码规范
• 第二到四周：批量迁移简单页面，每周 review 一次转换质量
• 第五周起：处理中等复杂度页面，同步补充 Compose 的测试用例
• 复杂页面单独排期，不设硬性 deadline

这个节奏的关键是先建立标准再规模化。试点阶段产出的代码规范、命名约定、状态管理模板，会成为后续批量迁移的基准，AI 的提示词也是基于这些规范来写的。

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

3.1 AI 转换的提示词设计

这是整个流程里最容易被忽视但最影响效果的环节。很多人直接把 XML 丢给 AI 说"转成 Compose"，出来的代码能跑但质量堪忧。好的提示词需要包含几个要素：

你是一个资深 Android 开发者，请将以下 XML 布局转换为 Jetpack Compose 代码。 要求： 1. 使用 Material3 组件，优先用 Scaffold、Column、Row、Box 等基础布局 2. 状态用 remember + mutableStateOf 管理，需要跨重组共享的用 ViewModel 3. 列表用 LazyColumn/LazyRow，不要用 Column + forEach 4. 图片加载用 Coil 的 AsyncImage 5. 保留原有的 id 命名，转换为 Compose 的语义化命名 6. 颜色和尺寸引用现有的资源文件，不要硬编码 7. 输出完整的 @Composable 函数，包含 Preview XML 布局： [粘贴 XML]

这个提示词里每一条要求都有讲究。比如"优先用基础布局"是为了避免 AI 生成一堆嵌套的 Surface 和 Card；"列表用 Lazy"是因为很多人转出来的代码用 Column 包 forEach，性能直接崩掉；"保留 id 命名"是为了后续排查问题时能对应上。

实测下来，加了这些约束之后，AI 生成代码的可用率能从 50% 左右提升到 80% 以上。剩下的 20% 主要是边界情况和业务逻辑相关的部分，本来也需要人工处理。

3.2 状态管理的迁移是重头戏

XML 时代的界面状态大多散落在 Activity/Fragment 里，通过 findViewById 拿到 View 再 setText、setVisibility。Compose 是声明式的，状态驱动 UI，这个思维转变是迁移中最难的部分，也是 AI 最容易出错的地方。

我的做法是分两步走。第一步让 AI 把 XML 转成"哑" Composable，所有数据通过参数传入，不涉及状态管理。第二步再单独处理状态提升，把原来 Activity 里的状态逻辑迁移到 ViewModel 或者 remember 里。

// 第一步：AI 生成的哑组件 @Composable fun UserProfileCard( name: String, avatarUrl: String, isVerified: Boolean, onFollowClick: () -> Unit ) { Card(modifier = Modifier.fillMaxWidth().padding(16.dp)) { Row(verticalAlignment = Alignment.CenterVertically) { AsyncImage( model = avatarUrl, contentDescription = null, modifier = Modifier.size(48.dp).clip(CircleShape) ) Column(modifier = Modifier.weight(1f).padding(start = 12.dp)) { Text(text = name, style = MaterialTheme.typography.titleMedium) if (isVerified) { Text(text = "已认证", style = MaterialTheme.typography.bodySmall) } } Button(onClick = onFollowClick) { Text("关注") } } } }

// 第二步：状态提升到 ViewModel class UserProfileViewModel : ViewModel() { private val _uiState = MutableStateFlow(UserProfileUiState()) val uiState: StateFlow<UserProfileUiState> = _uiState.asStateFlow() fun onFollowClick() { viewModelScope.launch { // 业务逻辑 } } } @Composable fun UserProfileScreen(viewModel: UserProfileViewModel = viewModel()) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() UserProfileCard( name = uiState.name, avatarUrl = uiState.avatarUrl, isVerified = uiState.isVerified, onFollowClick = viewModel::onFollowClick ) }

这个两步走的好处是职责清晰。AI 只负责 UI 结构的转换，状态逻辑由人来设计，避免了 AI 把状态管理写成一团乱麻。

3.3 自定义 View 的处理策略

项目里总有一些自定义 View，比如进度条、图表、特殊手势控件。这些 AI 基本转不了，硬转出来的代码还不如重写。我的策略是分三类处理：

• 能用 Compose 原生组件替代的：比如简单的圆形进度条，直接用 CircularProgressIndicator，别留恋自定义 View
• 逻辑复杂但绘制简单的：用 Canvas 重写，Compose 的 Canvas API 比 View 的 onDraw 简洁不少
• 绘制和手势都复杂的：用 AndroidView 包一层，先保证功能，后续再考虑重写

// 用 AndroidView 桥接复杂自定义 View @Composable fun LegacyChartView( data: List<Float>, modifier: Modifier = Modifier ) { AndroidView( factory = { context -> CustomChartView(context).apply { layoutParams = ViewGroup.LayoutParams( ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.WRAP_CONTENT ) } }, update = { view -> view.setData(data) }, modifier = modifier ) }

注意：AndroidView 里的 View 生命周期和 Compose 不完全一致，update 回调可能被频繁调用，setData 这类方法要做好幂等处理，否则容易出现性能问题。

3.4 资源引用的迁移

XML 里的颜色、尺寸、字符串引用，迁移到 Compose 后引用方式变了。这块 AI 经常出错，需要重点检查。

这里有个坑：colorResource 和 stringResource 都是 @Composable 函数，不能在非 Composable 上下文调用。如果 AI 把它们写在了普通函数里，编译直接报错。我一般会在 review 时全局搜一下这几个函数，确认调用位置正确。

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

4.1 环境准备和工具链搭建

动手之前，先把基础设施搭好。这部分工作看起来琐碎，但能省掉后面大量的返工。

首先是依赖配置。在 app 模块的 build.gradle 里加上 Compose 相关的依赖：

android { buildFeatures { compose = true } composeOptions { kotlinCompilerExtensionVersion = "1.5.8" } } dependencies { val composeBom = platform("androidx.compose:compose-bom:2024.02.00") implementation(composeBom) implementation("androidx.compose.ui:ui") implementation("androidx.compose.material3:material3") implementation("androidx.compose.ui:ui-tooling-preview") debugImplementation("androidx.compose.ui:ui-tooling") implementation("androidx.activity:activity-compose:1.8.2") implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.7.0") implementation("androidx.lifecycle:lifecycle-runtime-compose:2.7.0") implementation("io.coil-kt:coil-compose:2.5.0") }

用 BOM 管理 Compose 版本是个好习惯，避免各个库版本不一致导致的兼容问题。lifecycle-runtime-compose 是为了 collectAsStateWithLifecycle，这个比 collectAsState 更安全，能在页面不可见时自动停止收集。

然后是建立迁移规范文档。这个文档不用很长，但要把团队约定写清楚：Composable 命名用大驼峰、状态类用 UiState 后缀、事件回调用 on 开头、Preview 函数统一加 @Preview 注解等。这些约定会直接写进 AI 的提示词里，保证批量生成的代码风格一致。

4.2 单个页面的完整迁移流程

拿一个典型的用户列表页举例，走一遍完整流程。

第一步：分析原 XML 结构。原布局是一个 ConstraintLayout 包了一个 RecyclerView，顶部有个搜索框，底部有个加载更多按钮。这种结构在 Compose 里对应的是 Column + LazyColumn + 底部组件。

第二步：准备 AI 提示词并转换。把 XML 和提示词一起发给 AI，得到初稿。初稿通常能覆盖 80% 的结构，但搜索框的 TextField 状态、列表项的点击事件、加载更多的分页逻辑需要人工补充。

第三步：状态设计。定义 UiState：

data class UserListUiState( val searchQuery: String = "", val users: List<User> = emptyList(), val isLoading: Boolean = false, val isLoadingMore: Boolean = false, val hasMore: Boolean = true, val errorMessage: String? = null )

第四步：ViewModel 实现。把原来的网络请求、分页逻辑迁移过来，用 StateFlow 暴露状态。这里要注意的是，原来 RecyclerView 的 Adapter 里的逻辑，现在要拆成两部分：列表项的 UI 在 Composable 里，数据操作在 ViewModel 里。

第五步：Composable 实现。把 AI 生成的哑组件和 ViewModel 对接起来：

@Composable fun UserListScreen( viewModel: UserListViewModel = viewModel() ) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() Column(modifier = Modifier.fillMaxSize()) { SearchBar( query = uiState.searchQuery, onQueryChange = viewModel::onSearchQueryChange ) LazyColumn( modifier = Modifier.weight(1f), contentPadding = PaddingValues(16.dp), verticalArrangement = Arrangement.spacedBy(8.dp) ) { items( items = uiState.users, key = { it.id } ) { user -> UserItem( user = user, onClick = { viewModel.onUserClick(user.id) } ) } if (uiState.isLoadingMore) { item { Box( modifier = Modifier.fillMaxWidth().padding(16.dp), contentAlignment = Alignment.Center ) { CircularProgressIndicator() } } } } if (uiState.hasMore) { Button( onClick = viewModel::loadMore, modifier = Modifier.fillMaxWidth().padding(16.dp) ) { Text("加载更多") } } } }

第六步：Preview 和测试。给每个 Composable 加上 Preview，方便在 Android Studio 里直接看效果。同时补充 UI 测试，用 createComposeRule 写测试用例。

4.3 批量迁移的自动化脚本

单个页面跑通之后，就可以考虑批量处理了。我写了一个简单的 Python 脚本，扫描项目里的 layout 目录，把 XML 文件批量提取出来，配合提示词调用 AI 接口，生成对应的 Composable 文件。

import os import re from pathlib import Path def extract_layouts(layout_dir): """扫描 layout 目录，提取所有 XML 文件""" layouts = [] for root, dirs, files in os.walk(layout_dir): for file in files: if file.endswith('.xml'): filepath = os.path.join(root, file) with open(filepath, 'r', encoding='utf-8') as f: content = f.read() layouts.append({ 'name': file.replace('.xml', ''), 'path': filepath, 'content': content }) return layouts def generate_prompt(xml_content, screen_name): """生成 AI 转换提示词""" return f"""你是一个资深 Android 开发者，请将以下 XML 布局转换为 Jetpack Compose 代码。 屏幕名称：{screen_name} 要求： 1. 使用 Material3 组件 2. 状态用 remember + mutableStateOf 3. 列表用 LazyColumn/LazyRow 4. 图片用 Coil 的 AsyncImage 5. 输出完整的 @Composable 函数，包含 Preview XML 布局： {xml_content} """ if __name__ == '__main__': layouts = extract_layouts('app/src/main/res/layout') for layout in layouts: prompt = generate_prompt(layout['content'], layout['name']) # 调用 AI 接口，保存结果 print(f"处理: {layout['name']}")

这个脚本的价值不在于多复杂，而在于把重复劳动标准化。每个 XML 都走同样的提示词，生成结果的质量更稳定，review 起来也更快。

4.4 迁移后的验证清单

代码转完不代表迁移完成，验证环节同样重要。我整理了一份检查清单，每次迁移完一个页面都过一遍：

• 布局在不同屏幕尺寸下的表现是否正常
• 深色模式下的颜色是否正确
• 列表滚动性能是否达标（用 Layout Inspector 看重组次数）
• 状态恢复是否正常（旋转屏幕、进程被杀后恢复）
• 无障碍支持是否完整（contentDescription、语义化标签）
• 内存泄漏检查（尤其是 AndroidView 桥接的部分）

这份清单里，重组次数是最容易被忽视的。Compose 的性能问题往往不是出在单次重组慢，而是重组次数过多。用 Layout Inspector 的 recomposition counts 功能，能直观看到哪些 Composable 在频繁重组，针对性地加 remember 或者调整状态读取位置。

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

5.1 AI 生成代码的典型问题速查

5.2 状态不刷新的排查思路

这是迁移后最高频的问题，没有之一。表现是数据变了但界面没动。排查顺序是这样的：

先确认状态是不是用了 mutableStateOf 或者 StateFlow。如果是普通变量，Compose 根本感知不到变化。然后确认读取状态的位置对不对，Compose 只追踪 Composable 函数执行期间读取的状态，如果状态是在 lambda 里读的，可能不会被追踪到。

// 错误：状态在 lambda 里读取，可能不触发重组 Button(onClick = { val text = uiState.buttonText // 这里读状态没用 doSomething(text) }) // 正确：状态在 Composable 作用域读取 val buttonText = uiState.buttonText Button(onClick = { doSomething(buttonText) })

还有一个常见坑是 List 的更新。直接 list.add() 不会触发重组，因为 List 的引用没变。要用 list = list + newItem 或者 mutableStateListOf。

5.3 性能问题的定位方法

迁移后如果发现页面卡顿，先别急着改代码，用工具定位。Android Studio 的 Layout Inspector 能看重组次数，Profiler 能看 CPU 和内存。我一般按这个顺序排查：

第一步看重组次数。如果某个 Composable 的重组次数远超预期，说明它的状态依赖有问题，可能是读取了不该读的状态，或者父组件重组导致它跟着重组。

第二步看有没有不必要的对象创建。Compose 里在 Composable 函数里直接创建对象（比如 new 一个 Modifier 链、new 一个 lambda）会导致每次重组都创建新对象，虽然 Compose 有优化，但大量创建还是会影响性能。用 remember 缓存这些对象。

第三步看 LazyColumn 的 key 设置。没设 key 的话，列表项复用时状态会错乱，而且性能也差。key 要保证唯一且稳定，一般用数据项的 id。

5.4 团队协作中的经验教训

迁移不是一个人的事，团队协作的顺畅程度直接影响进度。踩过的坑里，有两个特别值得说。

一个是代码规范不统一。早期没定规范的时候，有人用 ViewModel 管状态，有人用 remember，有人用 rememberSaveable，代码 review 起来头大。后来统一了：跨页面共享的状态用 ViewModel，页面内临时状态用 remember，需要跨配置变更的用 rememberSaveable。规范定下来之后，AI 提示词也跟着更新，生成代码的一致性好了很多。

另一个是迁移和业务开发并行。有段时间一边迁移老页面，一边开发新功能，结果新功能也用 View 写，迁移完又得重写。后来调整了策略：新功能一律用 Compose 写，老页面按优先级迁移，两条线互不干扰。

提示：迁移期间最好冻结大范围的 UI 重构，否则迁移的基准一直在变，AI 转换的结果也要跟着改，得不偿失。

6. 迁移收益的量化与后续演进

6.1 怎么衡量迁移到底值不值

迁移做完不能只凭感觉说"快了"或者"好维护了"，得有数据。我一般看几个指标：

代码行数减少是因为 Compose 的声明式写法本身就比 XML + Adapter 简洁。开发时间减少主要来自不用再写 findViewById、Adapter、ViewHolder 这些模板代码。crash 率下降是因为 Compose 的类型安全在编译期就拦掉了很多问题。测试覆盖率提升是因为 Composable 比 View 好测，不用起 Activity 就能测。

6.2 AI 辅助迁移的边界在哪里

用了大半年，我的体会是 AI 在迁移里能帮的忙大概占 60%-70%，剩下的还是得人来。AI 擅长的是模式化的转换、重复性的代码生成、常见问题的修复建议。它不擅长的是业务逻辑的理解、性能的深度调优、以及那些"只可意会"的代码风格判断。

所以正确的定位是：AI 是加速器，不是替代品。把它当成一个不知疲倦的初级工程师，能帮你把脏活累活干掉，但关键的决策和质量把关还得自己来。指望 AI 一键完成迁移，目前还不现实，但用它把迁移效率提升一倍，是完全可以做到的。

6.3 后续可以继续做的优化

迁移完成只是第一步，后面还有不少可以打磨的地方。比如把设计系统沉淀成一套 Compose 组件库，新页面直接复用；比如把常用的交互模式（加载、空状态、错误重试）封装成通用 Composable；再比如用 Compose 的测试 API 把 UI 测试自动化程度提上去。

我最近在试的一个方向是用 AI 做迁移后的代码审查，把 Compose 的最佳实践整理成检查规则，让 AI 定期扫描代码库，找出不符合规范的地方。这个思路还在验证阶段，但初步效果不错，能发现一些人工 review 容易漏掉的问题。

最后分享一个我踩过的坑：迁移初期别追求 100% 的 Compose 化，留一些 AndroidView 桥接的页面完全没问题。我见过有团队为了"纯粹"把所有自定义 View 都重写，结果花了三个月，性能还不如原来。迁移的目的是提升开发效率和代码质量，不是为了技术而技术。能跑、好维护、团队用得顺手，比什么架构纯洁性都重要。