ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Meta 分享怎么用 AI 迁移 Compose 项目不烧心

Meta 分享怎么用 AI 迁移 Compose 项目不烧心 最近 Meta 的分享了 Instagram Direct 迁移 Jetpack Compose 的经验感觉还挺有意思的不过确实有种都到了「大千世界」了然后你才分享「焚决」的意思这次 Meta 公布的迁移数据是迁移后的 UI 代码量减少 50%AI Agent 执行时间下降 35%工程师与 Agent 的往返次数减少 32%单次 Agent Session 的 Token 成本降低 33%。但是这些都不是重点数据看了也没啥意义这里还是有一些「焚决」在哪里的首先是 Meta 弄了个 AI-native codebase 工程化不一味地给 Agent 塞越来越长的 rules、skills 和项目知识它选择改代码结构让 Agent 不容易偷懒走偏其次是 Meta 没有简单地把RecyclerView里的 XML 换成 Composable它非常有精力的做了一层可以同时跑在RecyclerView和LazyColumn上的 UI 抽象然后这让几百种消息组件可以逐步迁移同时还能做线上 A/B而且这里还有一个有意思的细节Meta 给代码文件维护了一套 risk score当文件风险分数翻倍的时候Agent 在传统 Android Views 代码上的资源效率会下降约 30%Compose 代码只下降约 9%也就是说 Compose 带来的优势在简单页面里可能只是少写一些代码但是到了历史包袱很重、状态很多、抽象很多的代码里差距居然可以会进一步拉开在 Instagram Direct 里面一个会话页面要处理超过 200 种 message type单个 UI Component 有 160 多种状态组合。我挺喜欢里面的这个说法意思大概就是AI 遇到阻力的时候会想办法绕过你的规则继续完成任务只靠 Skills、提示词和工程规范是不能保证它长期生成正确的代码。所以 Meta 给出的解决办法是让架构本身承担这部分约束。这个其实现在很多团队做 AI Coding 的方式正好能形成对照现在通常是旧项目一动不动然后不断往 Agent 上面叠东西AGENTS.md、rules、architecture skill、state-management skill、各种“请不要这样写”的说明这些东西每次都可能进入 Context本身就消耗 Token而且 Agent 真正在代码里碰到一个奇怪的历史抽象的时候还是可能选择那个最容易编译通过的方案。Meta 也说了Skills 本身存在 Context 成本加载过多规则反而降低 Agent 的表现。比如 Instagram Direct 在最初的时候代码里有 XML 和 Compose 直接混用的情况下 AI 经常分不清 XML 和 Compose 的边界Meta 官方举了一个非常简单的例子比如 Agent 要给聊天 Item 增加一个“置顶”状态AI 很容易写成这样的结构class ChatItem(...) { var isPinned false ​ Composable fun Content(uiState: ChatUiState) { Button( onClick { isPinned !isPinned } ) { ... } } }这么看起来代码挺自然的也能用但这里的isPinned跟 RecyclerView Item 实例生命周期绑定了Item 被重新 bind、复用到另一行之后这个状态就可能跟着对象一起活下来然后就出现类似“偶现、滚几下才出来、怎么都不好复现”的状态泄漏问题。所以 Meta 后来保留了项目需要的ChatItem这层抽象但是 Composable 内容被限制在构造时传入的 lambda 里UI 能看到的东西基本只剩uiState、显式依赖和事件 callback也就是成员字段不能是一个随手就能藏 mutable state 的地方大概类似这样ComposeItemChatUiState( content { state - PinButton( pinned state.isPinned, onClick { onPin(!state.isPinned) } ) } )类似这样的实现后续如果 Agent 想偷懒也不行了要改变isPinned最顺手的路径就是调onPin()然后状态经过正常的数据流重新进入ChatUiState正确的数据流同时也是代码里阻力最小的数据流这就是这套 AI-native architecture 的意思。在代码设计上就要把隐藏状态变成显式输入降低项目私有语义的数量这样就可以把错误写法从「需要规范禁止」的规则变成「结构上很难表达」的问题因为 AI 一用就报错。其实就是减少不确定性少让 AI 自由发挥这在迁移适配的过程里是一个很有用的规则也是你 Review 代码的时候需要介入调整的地方不然 AI 固执的程度决定了它走歪之后你再三强调它也是会继续走歪。所以 AI 写代码、做迁移、搞适配在中大型项目里不是写写 Spec 列一些规则就能能搞定的工程设计上如果没做好最后写出来的代码照样烧心。链接https://android-developers.googleblog.com/2026/09/jetpack-compose-ai-native-ui-instagram-direct.html
返回列表