Android 原生的 Compose A2UI 也来了，你还抱着 XML 养老吗？

Andorid Compose 的 A2UI 终于正式落地 AndroidX 了这个我们在 Flutter 已经聊过很多次了这次还是官方第一次通过 Compose Renderer 的形态落地到 Android。也就是 Android 原生也可以接收 A2UI 协议然后通过 Agent 描述交互界面再渲染成Native Compose Component同时执行 Agent 生成的逻辑代码。可能很多人说这玩意浪费 Token 又慢有什么用这个其实 Flutter 的时候就讲过了首先它一些 UI 可以根据用户数据提前在后端生成在使用之前就匹配好也可以 Cache真正用的时候直接就可以渲染出来就行其次还有 Client-Side Functions也就是逻辑也可以根据 UI 一起绑定动态生成类似于Catalog可以同时持有CatalogItem和ClientFunction生成 capabilities 时每个 function 会暴露name、description、parameters和returnType然后生成完整 Catalog Schema 时会把每个函数变成一个合法的FunctionCallschema。所以实际上在 A2UI 场景模型其实拥有的是一张“能力菜单”它知道有哪些函数知道函数需要什么参数也知道返回值是什么但真正的实现还是在 App 手里具体实现模型不关心它只关心需要组合成什么UI UI 需要加载什么逻辑。然后现在这套逻辑可以用在 Android Compose 上面了官方 Compose Renderer 已经有协议解析、Schema Validation、Surface State、Compose Runtime 和 Component Catalog。Agent 发来的结构化 UI 更新进入A2uiMessageProcessor对应 Surface 更新后Compose 只重组真正变化的组件而且它还支持反向事件所以用户操作原生 Button、Picker 后结果可以沿着 A2UI Client Event 回到 Agent。而这里 Jetpacker 源码里的核心初始化其实很简单初始化之后界面会直接消费这些activeSurfaces交给A2uiSurface渲染。private val messageProcessor A2uiMessageProcessor( catalogs listOf(bookingAssistantCatalog()) ) ​ val activeSurfaces messageProcessor.activeSurfaces不过目前的 Jetpacker 还没有做到完全的「ADK Agent 直接吐标准 A2UI Tree」目前看BookingAssistantViewModel.kt是通过 Cloud Run 后端 SSE 发来的是 ADK Event其中还夹着类似time_selection、seat_map、ticket_selection这样的业务语义然后 Android 的parseAndApplyEvent()再把它们转换成InteractiveOptionPicker、SeatSelectionPicker、BookingConfirmation之类的A2uiComponentPayload所以 A2UI 暂时只是解决了客户端的结构化 UI Runtime但 Jetpacker 这个 Sample 里Agent Runtime 与 A2UI 之间还存在一层业务 Adapter。然后就和之前聊的 Flutter A2UI 一样生成的权限会被 Component Catalog 卡得很死 App 开发者先定义一个 Component CatalogAgent 只能用这里声明过的 Component、Property 和 Client Function。Android 官方把 Catalog 叫做 formal contract比如你的 App 可以开放Text、Card、Button也可以像 Jetpacker 一样增加自己的SeatSelectionPicker、BookingStatus、BookingConfirmation然后 Agent 能决定“现在需要一个 SeatSelectionPicker标题是什么、座位选项是什么”。之后真正的 Compose 实现、主题、交互能力能说客户端提供而且 AndroidX 会在 Payload 进入 Compose UI Tree 前做 Schema Validation如果 Agent 幻觉出一个不存在的 Component会变成 Error State 并回报给 Agent。比如 Jetpacker 目前同时有两段航班、一个酒店、一个博物馆和一个餐厅Android 把这些行程发给 Cloud Run 上的 Python ADK Backend然后服务端的ItineraryOrchestratorAgent先按类型拆成 Flight、Hotel、Museum、Restaurant 几组然后塞进 ADK 的ParallelAgent每一组内部如果有多个项目还可以继续创建多个子 Agent 并行跑在这个过程里Agent 先生成一个起飞时间发送time_selection随后直接停在await session.pause_events[title].wait()Android 收到 SSE 后把这个状态变成 A2UI 的InteractiveOptionPicker然后用户在手机上点 Confirm客户端事件里带着具体agentId和选择结果回到/respond服务端把结果写进 Session再调用对应的session.pause_events[pause_key].set()再之后刚才被挂起的那个 Flight Agent 才继续执行下一步 Seat Selection酒店会停下来等待 Reservation Confirmation博物馆等待 Ticket Confirmation餐厅等待人数选择而其余没有被用户卡住的 Agent 会继续执行也就是用户可以在多个动态 A2UI 之间并行操作并行处理这种能力其实在 AI 手机场景上还是有些用的至少能可以同步处理多个事件然后通过可交互 UI 的方式来让用户决策不然每次都让用户看一堆文字的体验去试试不咋地所以 A2UI 也是 Tibo 说的场景之一也许未来代码根本不需要每次发版只需要根据场景动态生成就好了