Android Performance

以 2026 年 4 月 27 日郭明錤关于 OpenAI 手机的产业链消息为起点，从 Android 手机从业者视角，推演手机与 AI 融合之后的系统形态。

引言：这不是一台新手机的问题

郭明錤这条消息最值得关注的地方，不在 2028 年量产这个时间点，也不在联发科、Qualcomm、立讯分别处在什么供应位置。

它把问题推到了系统层：

如果用户的主要目的从打开 App 转向完成任务，手机操作系统应该长什么样？

这句话听起来像 UI 变化，但站在 Android 从业者视角，它牵动的是一整套系统结构：Launcher、通知、权限、IPC、App 能力声明、模型运行时、TEE、端云同步、任务状态机、审计记录、支付确认、开发者分成，都会被重新审视。

过去几年，AI 手机的讨论大多停在功能层。厂商讲 AI 修图、AI 消除、AI 摘要、AI 搜索、AI 助手、AI 简报，这些都能放进现有 Android 或 iOS 架构里。

OpenAI 如果真的按 AI Agent 手机去做，它会把问题从“手机里还能塞多少 AI 功能”，推到“手机的第一入口还要不要从 App icon 开始”。

主线是：Agent OS 更像移动 OS 在图形界面之后的一次结构迁移。前台从 App 网格迁移到任务流，后台从 App 独占能力转为可授权能力，系统从管理进程和窗口转向管理任务、上下文与责任。

OpenAI 做手机不一定基于 Android，但概率很高，因为它能继承硬件适配、驱动、应用兼容和供应链经验。但如果 OpenAI 想完全按 Agent OS 设计第一屏、权限和任务流，它也可能走一条“Android 兼容但不完全是 Android”的路，甚至用 Linux 自建系统，再用 Web、云端执行和应用兼容层补齐服务。

不同 OS 选择会改变进入市场的速度，却不会改变 Agent OS 必须解决的五件事：

1. 手机要持续理解用户的当前状态。
2. App 要从前台入口变成后台能力提供者。
3. 系统要有可恢复、可取消、可审计的任务运行时。
4. 端侧与云端要按数据敏感度和实时性分工。
5. 所有跨 App、跨设备、跨云的执行都要有权限、责任和回滚边界。

这五件事没有完成，AI 手机就只是“手机里装了一个 AI 助手”；它们一旦形成系统约束，手机才会朝 Agent OS 走。

这篇文章收集了《从 Trace 到洞察：SmartPerfetto AI Agent 的 Harness Engineering 实战》发布后收到的技术问题。它不重复正文的大段叙述，而是把最容易追问的设计点单独拆开。如果你已经读过正文，这里更适合作为二次阅读和交叉检索。

这篇文章记录了 SmartPerfetto 从零到可用过程中的关键技术决策。重点放在每次架构取舍背后的约束、失败案例和修正过程，而不是功能清单。如果你也在做 AI Agent 应用，或者在做 Perfetto 这类性能分析工具，这些工程折返点应该能直接参考。

文章按三层展开：先说清楚为什么 LLM 不能直接吃 Trace，包括上下文装不下、数值计算不可靠、领域知识用不上来三个原因；然后是从 Workflow 到 Agent 的迁移过程，附带 9 轮审查里挖出的冷启动 4 层联动 Bug 和 Ghost MCP Query 这类异步生命周期错配的具体案例；最后是 Scene Classification 按需加载、Artifact Store 控制返回数据量、三层验证从误判中迭代这三个关键决策为什么这么定。

上一篇 OpenClaw 实战复盘发出去之后，后台留言和群里讨论最多的就是这几个方向的问题：Token 消耗、能干什么、本地模型、隐私安全、使用体验。今天挑出被问频率最高的五个，一个一个说清楚。

最近这段时间，我一直在本地重度使用 OpenClaw。最开始我把它当成一个 AI 工具，但真正把它接进 Telegram、Obsidian、定时任务、本地模型和内容工作流之后，我发现它更像一套持续运转的工作系统。它能接消息、调工具、跑定时任务、调用不同模型、维护长期记忆、把结果回写 Obsidian，还能把复杂任务分发给别的 Agent。你如果只把它当聊天机器人，能用到的只是其中一小部分能力。

主线程上出现一段长 Binder 调用，慢的可能是服务端处理，也可能是事务派发、服务端线程排队或锁等待。这篇从一次调用出发，用 Perfetto 的 Binder 事件、线程状态和 Java monitor contention，把等待时间逐段分开。

这些信号需要在抓 Trace 时启用；看到主线程 Sleeping 或一个 futex 栈，只能确定它在等待，不能直接写成「Binder 慢」或「Java 锁慢」。

App 主线程没有按时处理一帧时，先分清它在 Running、Runnable 还是 Sleep；这三种状态对应的下一步调查完全不同。这篇用 Perfetto 的 CPU 调度、频率、空闲状态和采样数据，把「CPU 慢」拆成可核对的现象。

文中的核编号、频率和调度策略都要按目标设备确认。同一条线程运行在小核上，不足以单独证明调度错误。

在 Perfetto 里看到 vsync-app、vsync-sf 和 App 的 doFrame，很容易把三条轨道当成同一个时刻。这篇沿一次帧请求看 VSync 怎样从 SurfaceFlinger 的调度进入 App，接着怎样和 RenderThread、Buffer、FrameTimeline 对齐。

示例以 120 Hz 设备为主。相位配置、是否启用硬件 VSync，以及 App 是否请求下一帧都会改变轨道形态；本文先分清每个信号代表什么，再谈延迟。

版本说明（2026-10 核查）：Java、JNI 和调度代码按 android-16.0.0_r1 核对；app/appSf 的分工另引用 Android 13 源码。截图保留历史设备样例，不把它们视为 Android 16/17 的统一配置。代码省略外围状态时会明确说明，片段来自不同类，不能直接拼成可编译程序。

一次滑动卡顿，主线程可能在处理布局，也可能早已把绘制命令交给 RenderThread。这篇用 Perfetto 截图对照两条线程、Buffer 提交和 SurfaceFlinger，找出等待发生在哪一步。

先沿截图读一帧，再看 ActivityThread、RenderThread 和 BLASTBufferQueue 的职责。Trace 能缩小调查范围；帧最终是否上屏，还要核对 FrameTimeline 与合成侧记录。

120 Hz 把显示刷新间隔从 60 Hz 的约 16.67 ms 缩短到约 8.33 ms，但屏幕刷新率、App 产帧率和用户看到的帧并不是同一个数字。这篇从一份 Perfetto Trace 出发，解释三个数字怎样对应，以及高刷新率给渲染和功耗带来的取舍。

第 5 篇已经介绍 Choreographer 的回调顺序，这里重点看更短的显示周期。文中的设备截图只说明那次采集，不能代表所有 120 Hz 机型的调度配置。

本文介绍了 App 开发者不经常接触到但在 Android Framework 渲染链路中非常重要的一个类 Choreographer，包括 Choreographer 的引入背景、简介、部分源码解析、与 MessageQueue 的交互、在 APM 中的应用，以及手机厂商基于 Choreographer 的一些优化思路。

Choreographer 将待执行的帧回调与显示时序协调起来，而不是自行调整屏幕刷新率。以 120 Hz 为例，刷新间隔约 8.33 ms；是否能按时交付帧还取决于 CPU 调度、GPU、Buffer 和合成管线。应用按需请求回调，不是每个物理 Vsync 都要重新绘制。本文也会区分 FrameCallback、FrameMetrics、gfxinfo、Looper 和 Perfetto 各自能观察到的范围。

本篇是 Perfetto 系列文章的第四篇，如何使用 trace_processor_shell 在本地打开超过 2G 的大文件。在实际的问题分析过程中，我们经常会碰到非常大的 Trace 文件（大于 2GB），直接扔进 ui.perfetto.dev 可能会因浏览器内存限制而打不开；这里的限制是解析时的内存占用，并不是文件超过 2GB 就一定打不开。这时候我们就可以使用官方提供的 trace_processor_shell 工具来本地打开大文件。

写下这个系列时，Perfetto 在我的日常工作中已经基本取代 Systrace，我接触到的 OPPO、vivo 团队也在迁移。许多刚做 Android 性能优化的小伙伴觉得 Perfetto 界面眼花缭乱、功能复杂，希望我能把之前的 Systrace 文章用 Perfetto 再讲一遍。

本文为 Android App ANR 系列的第三篇，主要分享几个 ANR 的案例，系列文章目录如下

1. Android App ANR 系列 1 ：理解 Android ANR 设计思想
2. Android App ANR 系列 2 ：ANR 分析套路和关键 Log 介绍
3. Android App ANR 系列 3 ：ANR 案例分享

本文为 Android App ANR 系列的第二篇，主要分享 ANR 分析套路和关键 Log 介绍，系列文章目录如下

1. Android App ANR 系列 1 ：理解 Android ANR 设计思想
2. Android App ANR 系列 2 ：ANR 分析套路和关键 Log 介绍
3. Android App ANR 系列 3 ：ANR 案例分享

本文为 Android App ANR 系列的第一篇，主要是从系统的角度来剖析 Android ANR 的设计思想，系列文章目录如下

1. Android App ANR 系列 1 ：理解 Android ANR 设计思想
2. Android App ANR 系列 2 ：ANR 分析套路和关键 Log 介绍
3. Android App ANR 系列 3 ：ANR 案例分享