Google I/O 2026 刚刚落幕，Android 迎来了近年来更新密度和深度最大的一次革新。Google 在大会上明确表态：Android is shifting from an operating system to an intelligence system——从操作系统，迈向智能系统。

这不是一句口号。从 UI 框架到 AI 能力，从开发工具到系统底层，本次更新涵盖了 Android 开发的方方面面。本文将从五个维度拆解这些变化：Compose 正式上位、AI Agent 全面渗透、性能工具的 Agent 化、Android 17 底层硬核优化，以及开发工具链升级。

---

一、Compose First：View 体系正式进入维护模式

一个十三年时代的终结

Google 在本次 I/O 上正式宣布：Android 现在是 Compose First，传统 View 体系进入维护模式（Maintenance Mode）。

维护模式 ≠ Deprecated。 View 体系不会被标记为废弃，短期内也不会被移除。Google 会继续提供 Bug 修复和安全补丁，RecyclerView、ConstraintLayout 等核心组件的 API 将保持稳定。

但关键在于：所有新功能投资，将只针对 Compose。具体体现在三个方面：

• 不再有新的 View 布局原语。 Compose 今年拿到了全新的 Grid API——一个原生的二维布局原语，让开发者无需嵌套复杂的 ConstraintLayout 就能实现网格布局。这一能力 View 体系不会再有。
• 不再有针对 View 的性能优化。 底层渲染引擎的改进、新硬件特性的支持，全部 Compose 独占。
• 新 Jetpack 库优先甚至仅支持 Compose。 例如 CameraXViewfinder、Media3 AI Effects 这些涉及相机和媒体的核心库。

多设备统一的战略意义

Google 做出这个决定的背后，是一个关键数字：5 亿以上的活跃非手机 Android 设备。折叠屏、平板、Wear OS 手表、车机、ChromeOS、XR 眼镜……设备形态的碎片化，让 View 体系天然的架构劣势暴露无遗。

Compose 的声明式 + 响应式模型，配合今年更新的 Compose Adaptive Layouts 库，可以用一套代码覆盖所有设备形态。例如 Jetpack Glance 已实现 API 统一，同一套代码编写的 Widget 可以运行在手机、手表和车机上。

迁移策略

Google 同步推出了 Migration Assistant，帮助团队评估和执行从 View 到 Compose 的迁移。官方推荐的策略是：不要全量重构，而是做逐屏幕的增量迁移——用 ComposeView（在 Fragment 中嵌入 Compose）和 AndroidView（在 Compose 中嵌入 View）实现渐进式过渡。

底线： 如果你的项目还没开始用 Compose，现在是最后的上车窗口了。

---

二、构建 AI 应用：从 Copilot 到 Agent

今年 I/O 的另一条主线是 AI，但叙事重心已从"AI 辅助"全面转向了 “AI Agent”。Google 给出了一套从协议到框架到运行时的完整技术栈。

2.1 AppFunctions：让 App 成为 Agent 的工具

AppFunctions 是这套技术栈的底层能力。传统的应用交互方式是用户手动操作 UI，但 Agent 不看 UI——Agent 需要的是结构化的 API 调用。AppFunctions 本质上就是让你的 App 充当一个 设备端的 MCP（Model Context Protocol）服务器。

开发者通过 AppFunctionService 定义功能接口（如"发送消息"、“查询余额”、“下单”），每个功能附带自然语言描述，系统级 Agent（如 Gemini）即可自动发现并调用。

落地案例： KakaoTalk（韩国最大即时通讯应用）已通过 AppFunctions 实现 Gemini 直接调用发送功能。目前已有 25 个应用 在多家设备制造商上完成本地场景落地。

Google 还提供了多层次的集成路径：

集成路径	描述	典型场景
零代码路径	Gemini Intelligence 的任务自动化功能，无需开发者改代码，Gemini 通过屏幕操作完成任务	已在 Galaxy S26 上线，可帮用户叫车、点外卖
AppFunctions 路径	开发者主动暴露 API，获得更精细的控制权	性能和准确度更高，适合核心业务场景

2.2 A2UI：Agent 生成原生 UI

Agent 不能只返回文本，它需要能"画 UI"。A2UI（Agent to UI）协议 正是解决这一问题的开放标准。

Agent 通过声明式 JSON 描述 UI 意图，配合今年发布的 Jetpack Compose Renderer，这些 JSON 消息可以自动渲染为原生 Compose 组件。

举个场景：你问 Agent"帮我查一下明天的航班"，Agent 不是返回一段纯文本，而是直接渲染出一个包含航班信息的卡片——带有可交互按钮的原生界面，动态生成，不是预先写好的模板。

更重要的是，A2UI 是跨平台的——同样的 Agent 输出，在 React、SwiftUI、Compose 上都能原生渲染。

2.3 ADK for Android：端云协同的多 Agent 框架

ADK（Agent Development Kit）for Kotlin 在 I/O 上发布了 0.1.0 版本，是 ADK 从 Python 生态拓展到 Android 的第一步。ADK 解决的核心问题是 多 Agent 协同——一个旅行助手 Agent 可能需要调用航班查询、酒店预订、行程规划等多个子 Agent，它们之间需要编排、共享上下文、管理会话状态。

ADK 的关键设计包括：

• 混合编排： 强大的云端模型（如 Gemini Flash）作为主编排器，根据任务复杂度和隐私要求，把子任务下发给设备端的 Gemini Nano。
• Session 和 Memory： 内置短期记忆（Session State）和长期记忆（Memory Service），并支持 OpenTelemetry 遥测。
• 极简开发体验： 用 @Tool 和 @Param 注解定义工具函数，配置 Agent 只需几行 Kotlin 代码。

示例代码：

val travelAgent = LlmAgent(
    name = "TravelAssistant",
    model = Gemini(name = "gemini-nano"),
    instruction = Instruction("你是一个旅行助手..."),
    tools = listOf(myTravelTools),
    subAgents = listOf(bookingSubAgent)
)

2.4 设备端 AI 基座升级

支撑 Agent 能力的底层基座也迎来了重要更新：

• Gemini Nano 4： 下一代设备端模型，更擅长数据提取和摘要类任务，预计 2026 年底随旗舰设备推出。
• 结构化输出 API： 强制模型按预定义 JSON Schema 返回结果，生产环境必备。
• 前缀缓存（Prefix Caching）： 复用 Prompt 共享部分的中间状态，显著降低推理延迟。
• Firebase AI Logic 混合推理： 提供设备端和云端模型间的自动路由，开发者可设置 PREFER_ON_DEVICE、ONLY_CLOUD 等策略。

---

三、性能分析工具的 Agent 化革命

今年 Android Studio 的更新主题也是 Agent——不是帮你写代码的 Agent，而是帮你 分析性能问题 的 Agent。

3.1 Perfetto Agent：像和同事讨论一样分析 Trace

Android Studio 新增了 Android Performance Analyzer（APA），它是 GPU Inspector 的继任者，整合了 CPU、GPU、内存和功耗的统一追踪。APA 的追踪渲染速度比旧版快了 26 倍。

APA 集成了两个关键的 Agent Skill：

Perfetto Analysis Skill

你可以直接问 Agent："我的应用启动花了 1 秒多，为什么？"Agent 会激活 Perfetto 查询引擎，下载 Trace Processor，执行 SQL 查询——先查主线程是否长时间阻塞，再查类加载是否过多，逐个排除假设。它做的事和一个有经验的性能工程师完全一样，只是速度快得多。

Perfetto SQL Skill

能自动生成复杂的 Perfetto SQL 查询来定位瓶颈，省去了开发者手写查询的繁琐过程。将性能分析从"凭经验看火焰图"升级为"用自然语言问 Agent"。

3.2 LeakCanary 内嵌 Android Studio

LeakCanary——Android 社区最流行的内存泄漏检测库——现在直接集成进了 Android Studio Profiler。工作流变为：

1. 在 IDE 中一键以 LeakCanary 模式运行应用
2. 检测到泄漏时在 IDE 内直接展示泄漏路径
3. 点击旁边的 “Fix with Agent” 按钮
4. Agent 分析泄漏原因并尝试自动修复代码

从发现问题到修复代码，整个流程无需离开 IDE。

3.3 R8 Configuration Analyzer

R8 是 Android 的代码混淆和优化工具，但大多数项目的 R8 配置都是一团乱麻——你自己写了一些 keep 规则，每个依赖库又各自带了一堆 keep 规则，互相冲突覆盖，最终导致大量代码无法被优化。

新的 R8 Configuration Analyzer 能将所有 keep 规则的来源可视化，告诉你"这条规则导致了 200 个类无法被优化掉，而且这条规则来自某个你可能已经不需要的库"。

它还提供三个维度的优化评分：

• Obfuscation（混淆度）
• Optimization（优化度）
• Shrinking（瘦身度）

真实案例： 英国数字银行 Monzo 仅通过优化 R8 配置，就减少了 35% 的 ANR（应用无响应）。这说明很多性能问题并非代码逻辑问题，而是构建配置问题。

---

四、Android 17 底层硬核优化

Android 17（API 37）的系统级更新堪称"硬核"，其中最重磅的是对消息机制和垃圾回收的架构级重写。

4.1 无锁 MessageQueue（DeliQueue）

MessageQueue 是 Android 消息机制的核心，所有 UI 事件、Handler 消息、主线程任务调度都经过它。自 Android 诞生以来，其内部实现一直使用 单一监视器锁（Monitor Lock）。

问题在于 优先级反转：当低优先级后台线程往 MessageQueue 插消息并持有锁时，高优先级的主线程也需要操作 MessageQueue 就必须等待。如果中间还有中等优先级线程抢占 CPU，低优先级线程释放不了锁，主线程就被无限期阻塞——直接导致掉帧、卡顿。

Android 17 用全新的 DeliQueue 架构彻底重写了 MessageQueue，核心思路是将消息插入和处理完全分离：

组件	机制	优势
入队：Treiber Stack	无锁链式栈，所有线程通过原子 CAS 操作推消息，插入 O(1)	无需任何锁，彻底消除优先级反转
处理：本地最小堆	Looper 线程独占一个最小堆，从 Treiber Stack 批量取消息，按执行时间排序	堆是 Looper 私有的，完全不需要同步

此外还有两个硬核的细节优化：

• 原子指令集优化： ART 现在能自动检测处理器是否支持 ARMv8.1 LSE（Large System Extensions），如果支持就用 LDADD 等单指令原子操作替换传统的 LL/SC 循环。在高竞争场景下速度提升约 3 倍。
• 无分支编程： 消息比较逻辑放弃传统 if-else（会导致 CPU 分支预测失败），改用算术位移实现。基准测试中带来了 5 倍 的性能提升。

4.2 分代 GC

ART 的 Concurrent Mark-Compact 收集器现在支持 分代垃圾回收。核心思想是经典的"大部分对象都是短命的"——用更频繁但开销更小的年轻代回收，减少 Full GC 的触发频率，让 UI 更流畅。

4.3 其他值得关注的变化

• 联系人选择工具和取色器 API： 最小化敏感权限的使用
• 后台音频安全加固和短信动态密码保护： 安全方面的行为变更
• 大屏设备强制调整尺寸： 以 API 37 为目标的应用必须支持大屏尺寸调整
• 默认证书透明度： 提升网络安全

---

五、开发工具链升级速览

5.1 Android CLI 1.0 Stable

Google 发布了统一的命令行工具 Android CLI 1.0 Stable，取代了以前分散的 adb、emulator、avdmanager 等工具。更关键的是，它是为 AI Agent 和 LLM 设计的——Agent 可以通过 Android CLI 管理设备、安装应用、运行测试，实现 Agent 驱动的开发流程。

5.2 Google AI Studio 生成原生应用

开发者可以在 Google AI Studio 的浏览器端直接用 Prompt 生成 Android 应用，内置 Kotlin 和 Compose 最佳实践。生成的应用可以在嵌入式模拟器中直接预览，然后导入 Android Studio 做进一步开发，甚至可以直接部署到物理设备或发布到 Google Play 的内测轨道。

5.3 Android XR

Android XR SDK 开发者预览版 4 发布，核心库（Jetpack SceneCore、适用于 Jetpack XR 的 ARCore）即将进入 Beta。Google 还通过 Android XR Developer Catalyst 计划 开放硬件申请，开发者可以申请 XREAL 的 Project Aura 眼镜开发套件。

---

总结与行动建议

三个关键判断：

1. Compose 不再是可选项，而是唯一选项。 View 进入维护模式意味着所有新能力都是 Compose 独占的。还没迁移的项目，现在必须认真规划迁移路径了。

2. Agent 不是未来，是现在。 从 AppFunctions 到 ADK，从 A2UI 到 Gemini Intelligence，Google 给出了一套完整的 Agent 技术栈。你的 App 要么成为 Agent 的工具提供者，要么在 Agent 时代被绕过。

3. 性能优化的门槛正在被 AI 拉低。 Perfetto Agent、LeakCanary 集成、R8 分析器，让性能分析从"看经验"变成"问 Agent"。Android 17 的底层优化——无锁 MessageQueue、分代 GC——则从系统层面保证了更流畅的体验。