先聊一个我最近在技术社群里看到的讨论。有人发帖问现在还有必要学 XML 布局吗感觉 Compose 才是趋势。底下吵了三百多楼一派说 XML 稳如老狗存量项目根本动不了一派说 Compose 大势所趋新项目谁用 XML 谁落伍。说实话两边都不完全对但也都不完全错。让我从一线开发的视角聊聊真实体感。其实从去年开始圈子里陆续流行一个说法叫A2UI——AI to UI。意思很直白用自然语言描述、设计稿截图、或者标注图直接生成一套可运行的 Compose 界面代码。这意味着以前从设计稿到手写 XML、再逐个控价适配的流程正在被整体重写。如果你现在还在用 XML 布局养老这篇文章建议耐心看完。1. 先泼一盆冷水XML 没死但它的舒适区正在缩小1.1 XML 为什么让人产生养老错觉存量项目与肌肉记忆我必须先说明XML 布局并没有被判死刑。恰恰相反市面上的存量 Android 项目里百分之七八十的主界面还是 XML 写的。大型 App 的业务模块动辄几十上百个页面全面迁移到 Compose 需要排期、需要回归测试、需要处理第三方 View 体系的历史包袱。很多团队的选择是老模块继续用 XML 维护新模块开始尝试 Compose。这本身就是一个理性决策。但理性决策和可以一直躺平是两回事。XML 之所以给不少人带来养老的错觉是因为它已经被 Android Studio 打磨得非常成熟拖拽控件、实时预览、ConstraintLayout 辅助线、Layout Inspector 调试这套工具的熟练度一旦建立写起来确实像在舒适区里滑行。再加上团队里只要有一个XML 熟练工新人上手也快维护成本看起来没那么高。问题在于舒适区是会被边界顶住的。1.2 真正让你难受的 XML 场景嵌套层级、传参、ViewBinding 的板结如果你只在简单的静态页面里用 XML你确实感受不到痛点。但稍微复杂一点的业务场景XML 的软肋就会暴露出来嵌套层级失控。为了做一个圆角卡片加阴影你需要 FrameLayout 套 LinearLayout 再套 CardView最后发现层级树比业务树还复杂。布局嵌套过深measure 和 layout 的开销成倍增长卡顿就是这么一点点积累出来的。状态和 UI 分离带来的样板代码。一个列表页面你要写 Adapter、ViewHolder、item layout XML、空布局 XML、加载更多 footer XML再手动处理 notifyDataSetChanged。UI 上的一个小改动经常要动三个文件。ViewBinding 缓解了一部分问题但没有消除绑定这个动作。你依然需要手动感知 View 的生命周期手动在 onDestroy 里置空手动处理复用逻辑。这不能说是错但在业务迭代快的团队里它确实是纯消耗。我不是为了踩 XML 而踩 XML。我想表达的其实是XML 这套体系不是不好而是它的抽象层级太低了。它把界面长什么样和界面如何跟数据互动这两件事强行用两个语言体系分开开发者的心智负担始终在切换。而 Compose 用 Kotlin 一套语言把状态、布局、交互统一起来这恰恰是面向 UI 开发效率的底层重构。2. A2UI 是什么AI 生成 Compose 界面的工作流正在成型2.1 从设计稿到 UI 代码中间那层脏活终于有人接了先解释一下 A2UI 这组缩写。我第一次听到是在一次线下 Android Meetup 上一个做前端工程化的老哥提的。他的定义是AI to UI也就是用 AI 模型把设计输入截图、PSD、Figma 链接、甚至一句需求描述直接转换成可运行的 UI 代码。它不是某个单一产品的名字而是一类工作流的统称。为什么这件事和 Compose 绑在一起说因为 Compose 本身就是 Kotlin 代码天然适合作为 AI 生成的目标语言。XML 虽然也能生成但 XML 只是布局结构你生成完还要自己去写绑定逻辑、写事件、写状态。Compose 不一样它把布局、样式、状态、交互全写在一段 Kotlin 代码里AI 一旦理解了你的设计稿它可以一次性输出一个能跑的页面而不是一张静态图。我试过几个在线 AI 生成 UI 的工具输入一张电商首页截图输出就是一段 Compose 代码顶部搜索栏是 Row OutlinedTextField商品卡片是 Card ColumnBanner 轮播是 HorizontalPager。直接粘进项目稍微调一下间距和主题色就能在模拟器里看到和设计稿八成像的页面。这个效率比起当年对着设计稿一格一格拉 ConstraintLayout 约束确实是指数级的变化。2.2 A2UI 的几种典型形态代码生成、预览驱动、注解驱动A2UI 并不是单一形态我把它分成下面几类方便你理解这个领域正在往哪些方向走形态输入方式输出典型使用场景对话式生成自然语言描述完整 Composable 函数快速搭建原型页面截图转代码设计稿/截图近似设计稿的 Compose 代码前端联调、Activity 快速搭框架预览驱动拖拽 AI 辅助实时 Compose 预览与代码同步需要精确调整布局细节注解驱动代码中加注解标签自动生成样板代码简化重复的列表、表单逻辑聊到注解驱动就必须提一下热搜里那个android compose 注解标签 中文版本。我在中文社区里见过有人把 Compose 的注解用法整理成中文速查表。什么叫注解标签简单说Compose 大量依赖 Kotlin 注解和编译器插件的协同工作比如Composable是标记一个函数可以被组合、Preview是让 Android Studio 在 IDE 里渲染预览、Stable和Immutable是告诉编译器这个类型可以安全跳过重组。AI 生成代码的时候Preview这种注解经常被漏掉结果你生成了一堆函数却没法在 IDE 里快速预览还得手动补。所以我在实际使用 A2UI 工具时第一个习惯就是检查它有没有给可组合函数加Preview。这一点说起来简单不写的话调试效率差很多。3. Compose 迁移实战从一颗按钮开始的渐进式路线3.1 渐进式迁移的关键前提Compose 和 View 可以共存很多人不敢碰 Compose是担心要么全换要么不换。这是个误解。官方从 Compose 1.0 开始就支持在既有 View 体系里渐进式接入。你可以把 Compose 塞进ComposeView也可以反过来在 Compose 里通过AndroidView添加传统 View 控件。这意味着迁移可以是一点一点来的不需要搞什么原子弹式重写。我在实际项目里看过的比较稳的迁移方案是先把不需要复杂触摸事件、不需要深度定制交互的页面切到 Compose。比如用户协议页、隐私政策页、纯展示的静态页面。这些页面用 XML 写也可能就是几个 TextView 加一个 Button换成 Compose 毫无压力而且能立刻让团队建立对 Compose 的信心。第二步把列表页迁过来。列表是 Compose 的强项LazyColumn对比 RecyclerView最大的优势是不需要 Adapter 和 ViewHolder。你只需要写一个数据集合再写一个 item 的 Composable 函数剩下的交给LazyColumn处理。少了整整一层样板代码。我见过一个社区项目把一个 20 行的 RecyclerView 列表改装成 LazyColumn代码量少了将近一半。3.2 第一批适合迁移的组件静态页面、列表、表单再具体一点我建议按这个顺序做迁移试点静态内容页聚焦在文案展示、图片展示没有复杂状态。列表页用 LazyColumn 代替 RecyclerView测试性能和状态管理的差异。表单页输入校验、按钮状态切换体验 MutableState 管理交互状态。首页 Banner 宫格需要 ViewPager 的场景Compose 用 HorizontalPager 实现代码更直观。其中表单页是最容易感受到 Compose 魅力的场景。以前用 XML 写一个登录页EditText 的背景、错误提示、登录按钮的可点击状态这些都要做 Selector 文件、写监听、手动更新 UI。Compose 里可以直接用一个MutableStateString保存输入内容用if (password.length 6)这种普通 Kotlin 表达式控制错误提示显隐UI 自动跟着状态变化。对做过多年 XML 的老开发来说第一次看到这种写法的确会有点我原来在写啥的感觉。3.3 迁移中容易踩的坑状态提升、重组、生命周期迁移不是无痛的我讲几个实际踩过的点状态提升粒度。Compose 要求状态尽可能上提避免重复持有。一开始接手时我喜欢把状态存在每个 Composable 函数内部结果多个子组件要同步同一个开关状态时只能到处传回调。后来老老实实把状态提升到父级使用remember和rememberSaveable管理。这个概念如果你没有系统学过 Compose会非常反直觉。重组不是回调。在 Compose 里界面会因为状态变化被反复执行重组。如果你在 Composable 函数体里直接做网络请求、文件读写、数据库查询重组一次就执行一次后果不堪设想。正确的做法是把副作用放进LaunchedEffect或rememberCoroutineScope里。生命周期不是 Activity 生命周期。Compose 的DisposableEffect、LifecycleEventEffect可以感知宿主生命周期但它的触发时机会比你想的更多。我在迁一个视频列表时就因为没有妥善处理DisposableEffect的清理逻辑导致页面在快速滑动时出现播放器资源未释放的警告。这类问题在 XML 时代根本不需要你想因为 View 体系的回调把时机都定义好了Compose 把这层保护去掉了你必须自己掌控。4. 我实测生成的 Compose 代码能用但要会收拾4.1 生成 UI 的常见翻车点命名、硬编码、状态缺失我特地做了一个不严谨但真实的实验拿一张外卖 App 门店列表截图喂给一个代码生成工具让它输出 Compose 实现然后把生成代码放进 Android Studio 编译运行。结论是骨架能跑细节需要人改。先说翻车点命名完全不可控。生成出来的 Composable 函数名可能是Item()、Content()这种没有信息量的名字你只能自己改成语义化的RestaurantCard()、DistanceBadge()。硬编码严重。间距 16.dp、颜色Color(0xFFF5F5F5)、字号 14.sp 全部焊死在代码里。虽然跑起来没问题但这和项目已有的主题体系完全脱节。我在项目里强制要求所有颜色从MaterialTheme.colorScheme取间距从Dimens对象取生成代码显然做不到这一点。状态处理缺失。生成出来的列表是静态的点击事件、加载状态、错误重试这些一概没有。也就是说A2UI 解决的是静态 UI 快速成型离业务可用还有相当一段距离。我整理了一个更直观的对照表方便你评估生成结果的可用度维度生成代码表现需要人工收拾的工程量布局还原度较高常见组件能识别微调间距与对齐主题与资源极低硬编码居多全面接入项目主题体系状态管理几乎没有手动设计状态与事件流可维护性低命名混乱重构函数名拆分组件特殊效果差复杂动画基本失效需要手写动画逻辑4.2 怎么把生成物改造成生产级代码我自己总结了一套收拾生成代码的流程现在分享出来也许对你也有用第一步先跑通再重构。不要一开始就去改代码风格先把生成代码粘进项目确认它能编译、能在模拟器上显示出来。跑通的前提是项目已经完成 Compose 的基础配置包括依赖、Compiler 插件、主题接入。这一步出问题的话先解决环境不要和代码较劲。第二步命名语义化。把Item()、ColumnScope.EmptyLayout()这类名字全部替换成业务可读的名称。这一步不艰难但会产生大量 diff建议用 IDE 的重构功能逐层处理。第三步资源外置。把硬编码的颜色、字体、间距抽到主题和常量里。这一步可以和设计师对齐设计规范把生成代码当作视觉基准而不是最终答案。第四步补状态与事件。确认每个可交互元素都有独立的状态管理。比如商品卡片的加号按钮要不要禁用、点击后要不要弹 Toast、数量上限是多少这些必须你写AI 帮不了你。最后一步对照设计稿走查。在Preview里渲染多种尺寸的设备或者直接用 Layout Inspector 检查实际渲染树的层级和尺寸。尤其注意文本溢出、图片缩放模式、无障碍语义这些细节。整个过程下来我通常在二十分钟到半小时能做出一版能见客户的页面。对比以前手写 XML 加适配的时间效率提升还是比较明显的。但它不能替代开发和设计师的判断力它放大的是你的生产力而不是你的思考力。5. 关于 XML 和 Compose 的最终判断不是谁取代谁而是你的技能树5.1 学习 Compose 的推荐路线按角色如果这篇文章被刚入行的同学看到我会特别想提醒一句别在 XML 上投入太多新学习精力了把时间留给 Compose 和 Kotlin 本身。这并不是说 XML 完全没有学习的价值而是同样的时间投入在 Compose 上当前的回报率明显更高。你要理解 XML 至少得会看能维护老项目但你要开发新功能Compose 是更值得的投入对象。不同角色的同学我建议这样安排学习路线应届生 / 转行新人直接学 Compose练习项目也用 Compose 写。学的时候顺带理解 View 和 XML 的概念即可因为你入职的公司大概率有存量项目不可能完全绕开 XML。重点是看得懂 XML而不是精通 XML。中级开发掌握 Compose 的remember、mutableStateOf、LaunchedEffect、derivedStateOf这几大核心把 Compose 的状态驱动思维刻进脑子里。这是和 XML 时代最大的思维差异。高级 / 架构岗关注 Compose 的稳定性、性能优化、自定义布局、Modifier底层原理。招聘的时候我看到熟练掌握 Compose 的候选人会优先考虑因为他有可能会是团队里推动 UI 基础设施改革的人。5.2 面试和简历上Compose 的分量说到招聘我接触过不少候选人的简历有个让我很在意的倾向很多人把熟悉 XML写得掷地有声但问 Compose 的时候只能答出用过 LazyColumn。这不是说 XML 经验无用而是在行业应用层面Compose 已经成为新项目的主流选择。从热搜关键词都能看出来越来越多的人开始搜索android compose 注解标签 中文版本svg → compose imagevector kotlinandroid 动态图标主题。这说明什么说明生态里的工具链正在快速从面向 View转向面向 Compose。矢量图标、主题动态化、AI 生成 UI这些新东西的原生支持几乎都是优先围绕 Compose 展开的。你现在重新去研究 XML 的高级技巧短期内也许有用但长期回报会越来越低。写到这里我想起一个真实的项目经历。去年团队里有一个老工程师写 XML 写了八年是组里最熟练的 ConstraintLayout 玩家。Z 世代产品侧要做一个新的导流活动页设计稿只给了 Figma 链接要求两天内上线。传统思路是导出切图、写 XML、调整不同机型的适配但时间太紧。另一个同事用了 A2UI 工具直接生成 Compose 代码半天就出了能交互的 Demo又花半天接入统计和接口第二天如期上线。那位老工程师后来和我说他第一次感受到手写 XML 多巴胺被真正替代了不是被某个工具替代而是被一套更高效的抽象方式替代了。我个人现在的态度是XML 是好东西它是 Android 历史上的功臣但它的抽象层级停留在静态描述阶段Compose 把 UI 变成可编程的状态流这才是面向复杂业务和高迭代速度的正确姿态。你没有必要因为热爱 XML 而排斥 Compose但如果你连 Compose 都不愿意尝试那就不是热爱而是框住自己手脚的惰性了。最后分享一个我自己的小习惯我把之前练手的 XML 项目里两个高频页面一个商品列表、一个个人中心直接用 Compose 重写了一遍把重写前后的代码量、文件数、调试时间记在笔记里。结果不是用来证明 Compose 比 XML 强而是给自己留下一份转型记录。等哪天团队需要决策是否全面迁移时这份对比数据会比情绪更有说服力。 
长河君 · 2026/10/29 9:56:34 · 阅读 1.2k XML布局渐衰而Compose成主流：A2UI如何重塑Android UI开发
先聊一个我最近在技术社群里看到的讨论。有人发帖问现在还有必要学 XML 布局吗感觉 Compose 才是趋势。底下吵了三百多楼一派说 XML 稳如老狗存量项目根本动不了一派说 Compose 大势所趋新项目谁用 XML 谁落伍。说实话两边都不完全对但也都不完全错。让我从一线开发的视角聊聊真实体感。其实从去年开始圈子里陆续流行一个说法叫A2UI——AI to UI。意思很直白用自然语言描述、设计稿截图、或者标注图直接生成一套可运行的 Compose 界面代码。这意味着以前从设计稿到手写 XML、再逐个控价适配的流程正在被整体重写。如果你现在还在用 XML 布局养老这篇文章建议耐心看完。1. 先泼一盆冷水XML 没死但它的舒适区正在缩小1.1 XML 为什么让人产生养老错觉存量项目与肌肉记忆我必须先说明XML 布局并没有被判死刑。恰恰相反市面上的存量 Android 项目里百分之七八十的主界面还是 XML 写的。大型 App 的业务模块动辄几十上百个页面全面迁移到 Compose 需要排期、需要回归测试、需要处理第三方 View 体系的历史包袱。很多团队的选择是老模块继续用 XML 维护新模块开始尝试 Compose。这本身就是一个理性决策。但理性决策和可以一直躺平是两回事。XML 之所以给不少人带来养老的错觉是因为它已经被 Android Studio 打磨得非常成熟拖拽控件、实时预览、ConstraintLayout 辅助线、Layout Inspector 调试这套工具的熟练度一旦建立写起来确实像在舒适区里滑行。再加上团队里只要有一个XML 熟练工新人上手也快维护成本看起来没那么高。问题在于舒适区是会被边界顶住的。1.2 真正让你难受的 XML 场景嵌套层级、传参、ViewBinding 的板结如果你只在简单的静态页面里用 XML你确实感受不到痛点。但稍微复杂一点的业务场景XML 的软肋就会暴露出来嵌套层级失控。为了做一个圆角卡片加阴影你需要 FrameLayout 套 LinearLayout 再套 CardView最后发现层级树比业务树还复杂。布局嵌套过深measure 和 layout 的开销成倍增长卡顿就是这么一点点积累出来的。状态和 UI 分离带来的样板代码。一个列表页面你要写 Adapter、ViewHolder、item layout XML、空布局 XML、加载更多 footer XML再手动处理 notifyDataSetChanged。UI 上的一个小改动经常要动三个文件。ViewBinding 缓解了一部分问题但没有消除绑定这个动作。你依然需要手动感知 View 的生命周期手动在 onDestroy 里置空手动处理复用逻辑。这不能说是错但在业务迭代快的团队里它确实是纯消耗。我不是为了踩 XML 而踩 XML。我想表达的其实是XML 这套体系不是不好而是它的抽象层级太低了。它把界面长什么样和界面如何跟数据互动这两件事强行用两个语言体系分开开发者的心智负担始终在切换。而 Compose 用 Kotlin 一套语言把状态、布局、交互统一起来这恰恰是面向 UI 开发效率的底层重构。2. A2UI 是什么AI 生成 Compose 界面的工作流正在成型2.1 从设计稿到 UI 代码中间那层脏活终于有人接了先解释一下 A2UI 这组缩写。我第一次听到是在一次线下 Android Meetup 上一个做前端工程化的老哥提的。他的定义是AI to UI也就是用 AI 模型把设计输入截图、PSD、Figma 链接、甚至一句需求描述直接转换成可运行的 UI 代码。它不是某个单一产品的名字而是一类工作流的统称。为什么这件事和 Compose 绑在一起说因为 Compose 本身就是 Kotlin 代码天然适合作为 AI 生成的目标语言。XML 虽然也能生成但 XML 只是布局结构你生成完还要自己去写绑定逻辑、写事件、写状态。Compose 不一样它把布局、样式、状态、交互全写在一段 Kotlin 代码里AI 一旦理解了你的设计稿它可以一次性输出一个能跑的页面而不是一张静态图。我试过几个在线 AI 生成 UI 的工具输入一张电商首页截图输出就是一段 Compose 代码顶部搜索栏是 Row OutlinedTextField商品卡片是 Card ColumnBanner 轮播是 HorizontalPager。直接粘进项目稍微调一下间距和主题色就能在模拟器里看到和设计稿八成像的页面。这个效率比起当年对着设计稿一格一格拉 ConstraintLayout 约束确实是指数级的变化。2.2 A2UI 的几种典型形态代码生成、预览驱动、注解驱动A2UI 并不是单一形态我把它分成下面几类方便你理解这个领域正在往哪些方向走形态输入方式输出典型使用场景对话式生成自然语言描述完整 Composable 函数快速搭建原型页面截图转代码设计稿/截图近似设计稿的 Compose 代码前端联调、Activity 快速搭框架预览驱动拖拽 AI 辅助实时 Compose 预览与代码同步需要精确调整布局细节注解驱动代码中加注解标签自动生成样板代码简化重复的列表、表单逻辑聊到注解驱动就必须提一下热搜里那个android compose 注解标签 中文版本。我在中文社区里见过有人把 Compose 的注解用法整理成中文速查表。什么叫注解标签简单说Compose 大量依赖 Kotlin 注解和编译器插件的协同工作比如Composable是标记一个函数可以被组合、Preview是让 Android Studio 在 IDE 里渲染预览、Stable和Immutable是告诉编译器这个类型可以安全跳过重组。AI 生成代码的时候Preview这种注解经常被漏掉结果你生成了一堆函数却没法在 IDE 里快速预览还得手动补。所以我在实际使用 A2UI 工具时第一个习惯就是检查它有没有给可组合函数加Preview。这一点说起来简单不写的话调试效率差很多。3. Compose 迁移实战从一颗按钮开始的渐进式路线3.1 渐进式迁移的关键前提Compose 和 View 可以共存很多人不敢碰 Compose是担心要么全换要么不换。这是个误解。官方从 Compose 1.0 开始就支持在既有 View 体系里渐进式接入。你可以把 Compose 塞进ComposeView也可以反过来在 Compose 里通过AndroidView添加传统 View 控件。这意味着迁移可以是一点一点来的不需要搞什么原子弹式重写。我在实际项目里看过的比较稳的迁移方案是先把不需要复杂触摸事件、不需要深度定制交互的页面切到 Compose。比如用户协议页、隐私政策页、纯展示的静态页面。这些页面用 XML 写也可能就是几个 TextView 加一个 Button换成 Compose 毫无压力而且能立刻让团队建立对 Compose 的信心。第二步把列表页迁过来。列表是 Compose 的强项LazyColumn对比 RecyclerView最大的优势是不需要 Adapter 和 ViewHolder。你只需要写一个数据集合再写一个 item 的 Composable 函数剩下的交给LazyColumn处理。少了整整一层样板代码。我见过一个社区项目把一个 20 行的 RecyclerView 列表改装成 LazyColumn代码量少了将近一半。3.2 第一批适合迁移的组件静态页面、列表、表单再具体一点我建议按这个顺序做迁移试点静态内容页聚焦在文案展示、图片展示没有复杂状态。列表页用 LazyColumn 代替 RecyclerView测试性能和状态管理的差异。表单页输入校验、按钮状态切换体验 MutableState 管理交互状态。首页 Banner 宫格需要 ViewPager 的场景Compose 用 HorizontalPager 实现代码更直观。其中表单页是最容易感受到 Compose 魅力的场景。以前用 XML 写一个登录页EditText 的背景、错误提示、登录按钮的可点击状态这些都要做 Selector 文件、写监听、手动更新 UI。Compose 里可以直接用一个MutableStateString保存输入内容用if (password.length 6)这种普通 Kotlin 表达式控制错误提示显隐UI 自动跟着状态变化。对做过多年 XML 的老开发来说第一次看到这种写法的确会有点我原来在写啥的感觉。3.3 迁移中容易踩的坑状态提升、重组、生命周期迁移不是无痛的我讲几个实际踩过的点状态提升粒度。Compose 要求状态尽可能上提避免重复持有。一开始接手时我喜欢把状态存在每个 Composable 函数内部结果多个子组件要同步同一个开关状态时只能到处传回调。后来老老实实把状态提升到父级使用remember和rememberSaveable管理。这个概念如果你没有系统学过 Compose会非常反直觉。重组不是回调。在 Compose 里界面会因为状态变化被反复执行重组。如果你在 Composable 函数体里直接做网络请求、文件读写、数据库查询重组一次就执行一次后果不堪设想。正确的做法是把副作用放进LaunchedEffect或rememberCoroutineScope里。生命周期不是 Activity 生命周期。Compose 的DisposableEffect、LifecycleEventEffect可以感知宿主生命周期但它的触发时机会比你想的更多。我在迁一个视频列表时就因为没有妥善处理DisposableEffect的清理逻辑导致页面在快速滑动时出现播放器资源未释放的警告。这类问题在 XML 时代根本不需要你想因为 View 体系的回调把时机都定义好了Compose 把这层保护去掉了你必须自己掌控。4. 我实测生成的 Compose 代码能用但要会收拾4.1 生成 UI 的常见翻车点命名、硬编码、状态缺失我特地做了一个不严谨但真实的实验拿一张外卖 App 门店列表截图喂给一个代码生成工具让它输出 Compose 实现然后把生成代码放进 Android Studio 编译运行。结论是骨架能跑细节需要人改。先说翻车点命名完全不可控。生成出来的 Composable 函数名可能是Item()、Content()这种没有信息量的名字你只能自己改成语义化的RestaurantCard()、DistanceBadge()。硬编码严重。间距 16.dp、颜色Color(0xFFF5F5F5)、字号 14.sp 全部焊死在代码里。虽然跑起来没问题但这和项目已有的主题体系完全脱节。我在项目里强制要求所有颜色从MaterialTheme.colorScheme取间距从Dimens对象取生成代码显然做不到这一点。状态处理缺失。生成出来的列表是静态的点击事件、加载状态、错误重试这些一概没有。也就是说A2UI 解决的是静态 UI 快速成型离业务可用还有相当一段距离。我整理了一个更直观的对照表方便你评估生成结果的可用度维度生成代码表现需要人工收拾的工程量布局还原度较高常见组件能识别微调间距与对齐主题与资源极低硬编码居多全面接入项目主题体系状态管理几乎没有手动设计状态与事件流可维护性低命名混乱重构函数名拆分组件特殊效果差复杂动画基本失效需要手写动画逻辑4.2 怎么把生成物改造成生产级代码我自己总结了一套收拾生成代码的流程现在分享出来也许对你也有用第一步先跑通再重构。不要一开始就去改代码风格先把生成代码粘进项目确认它能编译、能在模拟器上显示出来。跑通的前提是项目已经完成 Compose 的基础配置包括依赖、Compiler 插件、主题接入。这一步出问题的话先解决环境不要和代码较劲。第二步命名语义化。把Item()、ColumnScope.EmptyLayout()这类名字全部替换成业务可读的名称。这一步不艰难但会产生大量 diff建议用 IDE 的重构功能逐层处理。第三步资源外置。把硬编码的颜色、字体、间距抽到主题和常量里。这一步可以和设计师对齐设计规范把生成代码当作视觉基准而不是最终答案。第四步补状态与事件。确认每个可交互元素都有独立的状态管理。比如商品卡片的加号按钮要不要禁用、点击后要不要弹 Toast、数量上限是多少这些必须你写AI 帮不了你。最后一步对照设计稿走查。在Preview里渲染多种尺寸的设备或者直接用 Layout Inspector 检查实际渲染树的层级和尺寸。尤其注意文本溢出、图片缩放模式、无障碍语义这些细节。整个过程下来我通常在二十分钟到半小时能做出一版能见客户的页面。对比以前手写 XML 加适配的时间效率提升还是比较明显的。但它不能替代开发和设计师的判断力它放大的是你的生产力而不是你的思考力。5. 关于 XML 和 Compose 的最终判断不是谁取代谁而是你的技能树5.1 学习 Compose 的推荐路线按角色如果这篇文章被刚入行的同学看到我会特别想提醒一句别在 XML 上投入太多新学习精力了把时间留给 Compose 和 Kotlin 本身。这并不是说 XML 完全没有学习的价值而是同样的时间投入在 Compose 上当前的回报率明显更高。你要理解 XML 至少得会看能维护老项目但你要开发新功能Compose 是更值得的投入对象。不同角色的同学我建议这样安排学习路线应届生 / 转行新人直接学 Compose练习项目也用 Compose 写。学的时候顺带理解 View 和 XML 的概念即可因为你入职的公司大概率有存量项目不可能完全绕开 XML。重点是看得懂 XML而不是精通 XML。中级开发掌握 Compose 的remember、mutableStateOf、LaunchedEffect、derivedStateOf这几大核心把 Compose 的状态驱动思维刻进脑子里。这是和 XML 时代最大的思维差异。高级 / 架构岗关注 Compose 的稳定性、性能优化、自定义布局、Modifier底层原理。招聘的时候我看到熟练掌握 Compose 的候选人会优先考虑因为他有可能会是团队里推动 UI 基础设施改革的人。5.2 面试和简历上Compose 的分量说到招聘我接触过不少候选人的简历有个让我很在意的倾向很多人把熟悉 XML写得掷地有声但问 Compose 的时候只能答出用过 LazyColumn。这不是说 XML 经验无用而是在行业应用层面Compose 已经成为新项目的主流选择。从热搜关键词都能看出来越来越多的人开始搜索android compose 注解标签 中文版本svg → compose imagevector kotlinandroid 动态图标主题。这说明什么说明生态里的工具链正在快速从面向 View转向面向 Compose。矢量图标、主题动态化、AI 生成 UI这些新东西的原生支持几乎都是优先围绕 Compose 展开的。你现在重新去研究 XML 的高级技巧短期内也许有用但长期回报会越来越低。写到这里我想起一个真实的项目经历。去年团队里有一个老工程师写 XML 写了八年是组里最熟练的 ConstraintLayout 玩家。Z 世代产品侧要做一个新的导流活动页设计稿只给了 Figma 链接要求两天内上线。传统思路是导出切图、写 XML、调整不同机型的适配但时间太紧。另一个同事用了 A2UI 工具直接生成 Compose 代码半天就出了能交互的 Demo又花半天接入统计和接口第二天如期上线。那位老工程师后来和我说他第一次感受到手写 XML 多巴胺被真正替代了不是被某个工具替代而是被一套更高效的抽象方式替代了。我个人现在的态度是XML 是好东西它是 Android 历史上的功臣但它的抽象层级停留在静态描述阶段Compose 把 UI 变成可编程的状态流这才是面向复杂业务和高迭代速度的正确姿态。你没有必要因为热爱 XML 而排斥 Compose但如果你连 Compose 都不愿意尝试那就不是热爱而是框住自己手脚的惰性了。最后分享一个我自己的小习惯我把之前练手的 XML 项目里两个高频页面一个商品列表、一个个人中心直接用 Compose 重写了一遍把重写前后的代码量、文件数、调试时间记在笔记里。结果不是用来证明 Compose 比 XML 强而是给自己留下一份转型记录。等哪天团队需要决策是否全面迁移时这份对比数据会比情绪更有说服力。