Instagram Adopts AI-Native Architecture with Jetpack Compose Migration

By 作者:Sergio De SimoneOriginal title: Instagram 采用原生 AI 架构对用户界面进行了现代化改造,将 token 成本降低了 33%
68AI Score

Instagram migrated its Android Direct UI to Jetpack Compose, creating an 'AI-native' codebase that halved UI code volume and reduced AI agent session token costs by 33%. The approach leverages architectural design to guide AI agents toward high-quality implementations rather than relying on AI to patch poor designs.

Full Report

Instagram 将 Android 端 Direct UI 全量迁移到 Jetpack Compose,构建 AI 原生代码库,实现代码量减半、AI 会话 token 成本降 33%。

“AI 原生架构”优先保障状态管理可预测性与边界清晰性;AI 代理天然倾向最小阻力路径,需通过架构设计使其导向高质量实现;避免用 AI 弥补不良设计,而应基于 AI 行为建模反向驱动架构演进。

适合 Android 架构师、AI 工程化负责人、前端平台工程师阅读。

Instagram Direct 将其 Android 用户界面从旧版的 Android View 系统迁移到了 Jetpack Compose,从而创建了一个 AI 原生的用户界面代码库,使 AI 编码代理更容易理解、修改和维护。据 Instagram 工程师称,这次迁移使用户界面的代码量减少了 50%,并将每个 AI 代理会话的 token 成本降低了 33%。

Instagram 工程师提出的一个关键观点是:“设计 AI 原生架构带来了显著的收益”。与其采取零敲碎打的方式(要求开发人员逐个迁移各个组件),不如把重点放在评估底层架构是否便于生成正确的实现方案上。事实上,正如他们指出的那样,“AI 工具往往会选择阻力最小的路径”,这很可能导致“隐蔽的 Bug、技术债务和性能退化”。

Instagram 的工程师们解释道,面向 AI 优化代码库,意味着在状态管理、可预测行为以及开发模式方面建立起正确的架构边界,从而使 AI 代理的“最小阻力路径”成为通向最佳转换效果的路径。他们的目标并非简单地让 AI 来弥补设计上的缺陷,而是基于对 AI 代理实际如何修改代码的理解来设计代码库:

AI 代理天生会选择阻力最小的路径,因此,在设计的时候就应该确保该路径最终生成正确且高质量的代码,同时让拙劣的设计决策难以实现且代价高昂。

另一个关键原则是最大限度地减少上下文依赖。也就是说,让 AI 代理不再依赖于特定代码库的知识,而是优先采用经过验证的最佳实践和熟悉的模式,从而帮助它们生成更可靠的结果。

这次迁移在不影响整个团队正常工作的前提下顺利完成,工程师能够在迁移期间继续发布新功能。AI 辅助工作流已经实现了标准化,这促进了一致性,并且可以确保与团队内部通用的架构规范和最佳实践保持一致。

通过这种方法,迁移到 Jetpack Compose 使 UI 代码量减少了 50%,同时将 AI 代理的执行时间缩短了 35%,每个代理会话的 token 成本降低了 33%,工程师与代理之间的交互次数减少了 32%。

一个主要的挑战是确保迁移不会导致性能退化。团队重点关注了三个关键的生产指标:交互响应时间,即打开屏幕后到其可用的时间;完全加载时间,即所有屏幕内容加载完成的时间;以及滚动性能,即衡量屏幕内容滚动的流畅程度。

在生产环境中,这些指标是通过运行时监控进行追踪,为的是能够进行 A/B 测试,可以将迁移后的 Compose UI 与旧版 UI 进行对比,并评估迁移对性能的影响。

Instagram 工程师的一个重要发现是:只有将整个屏幕迁移到 Compose 之后,才能可靠地评估性能,从而消除任何可能导致性能测量结果失真的遗留 View 组件。

这意味着 Compose UI 组件应该从其所在的框架中进行抽象,同时仍然需要与 RecyclerView 和 LazyColumn 保持兼容。同样重要的是,应该能够在运行时通过功能标志在这两者之间进行切换,以便进行 A/B 测试。

最终,团队使用 LazyColumn(Compose 中用于高效渲染可滚动列表的原生解决方案)替换了传统的 RecyclerView(最初是作为容纳新 Compose 可组合项的容器而被保留下来的)。

最后需要说明的是,这次迁移还提升了应用程序其他部分的启动性能。其中一部分原因在于,Compose 的运行时预热开销只需要在每个应用会话中承担一次,这样其他基于 Compose 的界面便可以利用已初始化的运行时环境,而不需要再次承担该开销。