Android Performance

这篇置顶页只做一件事：把我长期维护、正在推进、已经公开和暂未公开的项目集中到一个地方。范围包括 Android 性能分析、Perfetto 工具、AI 自动化、iOS App、Android Demo、测试套件、博客系列、社群和各个平台账号。

第一次来到这个博客，可以按需求直接跳转：学 Android 性能分析，看 Perfetto / Systrace 系列；找工具项目，看 SmartPerfetto、TraceFix、Android App Memory Analysis；了解 AI 如何参与知识管理和日常工作，看 OpenClaw 与 AI Field Notes；联系我或查看其它平台账号，看文末。

项目按四条线划：性能分析方向有 SmartPerfetto、Android App Memory Analysis、TraceFix、Perfetto Auto-Pin 这类工具，以及 High Performance Friends Circle 社群；AI 与自动化方向有 OpenClaw、AI Field Notes、Gracker Skills、Open Design；正在做的 App 包括 100Years、iBattery、Juju 三款 iOS 项目；内容项目则是博客、Android Weekly、知识星球三处主阵地。下面每个项目都会注明状态：日常维护、近期重点、还是已经暂停。

本博客内容主要集中在 Android 开发和优化相关的话题，包括一些性能工具的使用、Android App 优化知识、Android Framework 知识讲解，性能理论知识讲解等，这里整理了一份目录供大家参考，大家可以挑感兴趣的部分来看。这里不仅仅包含博客中的内容，一些我在 知乎 或者 知识星球 - The Performance 的回答也会放到这里，不过这个目录里面放的都是我原创的博客，另外还收集了一些优秀文章，我也会不定期更新 Android 性能优化必知必会。

这篇文章记录了 Android 性能优化所必须掌握的知识（主要是对应的优秀文章、公众号、博客、技术团队等），涵盖性能优化相关的方方面面。本文会持续更新，欢迎各位自荐或者推荐。

SmartPerfetto 已经完整开源。打开仓库能看到当前可运行的主干工程：Perfetto UI fork、后端 agentv3、MCP 工具、YAML Skill、场景策略、脚本和文档。没有保留私有核心模块，也没有只放一层 demo 壳。

这个项目来自一个很具体的日常场景：手里有一条 trace，Perfetto 已经把事实摆出来，但从事实到判断还要翻表、写 SQL、对线程、看 FrameTimeline、找 Binder 对端，再回到时间线上确认一遍。SmartPerfetto 想把这些重复动作固化成工具，让性能工程师把时间花在判断上。

它还处在开发阶段。现在放出来，是因为 trace 分析靠真实样本长出来：真实设备、真实厂商差异、真实业务 trace、真实 PR，都会改变 Skill 和策略该怎么写。等所有能力都稳定后再单向发布，反而会错过最需要样本的阶段。

如果你日常会打开 Perfetto 看滑动卡顿、启动、ANR、Binder、CPU 调度或渲染管线，SmartPerfetto 提供的是一个带 AI Assistant 的 Perfetto UI：加载 trace 后，用自然语言提问，后端查询 trace_processor_shell、调用 YAML Skill、组织证据，再把结论和数据表格流式显示在浏览器里。

项目地址：

• 主仓库：https://github.com/Gracker/SmartPerfetto
• Perfetto UI fork：https://github.com/Gracker/perfetto

普通试用只需要看主仓库。Gracker/perfetto 是 perfetto/ submodule 对应的前端 fork，主要给需要改 AI Assistant 插件 UI 的开发者使用。

前两篇技术文档更适合想看工程细节的读者：

• 从 Trace 到洞察：SmartPerfetto AI Agent 的 Harness Engineering 实战：SmartPerfetto AI Agent 的架构和 Harness Engineering 过程。
• SmartPerfetto 架构文章 Q&A：8 个深度技术问答：围绕 Agent、Workflow、YAML Skill 的问答。

前两篇把内部架构讲得比较细，但源码放出来以后，读者更关心的是仓库里到底有什么、能不能跑、哪些地方还没稳。这篇主要补开源这件事：开放了什么、当前能做什么、内部怎么分工、怎样在本地跑起来、哪些地方适合一起改。

以 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。你如果只把它当聊天机器人，能用到的只是其中一小部分能力。

本文是 Perfetto 系列的第十篇文章，聚焦 Binder 这一 Android 跨进程通信的核心机制。Binder 承载着大部分系统服务与应用的交互，也常常是性能瓶颈的源头。本文站在系统开发与性能调优的视角，结合 linux.ftrace（binder tracepoints + sched）、thread_state 轨道，以及 ART 的 Java Monitor Contention（通过 atrace 的 dalvik 类别采集）等信号，给出一套可直接使用的诊断流程，帮助初学者和进阶开发者定位耗时、线程池压力与锁竞争等问题。

本系列的目标，就是通过 Perfetto 这个工具，从一个全新的图形化视角，来审视 Android 系统的整体运行，同时也提供一个学习 Framework 的新途径。或许你已经读过很多源码分析的文章，但总是对繁杂的调用链感到困惑，或者记不住具体的执行流程。那么通过 Perfetto，将这些流程可视化，你可能会对系统有更深入、更直观的理解。

本文是 Perfetto 系列的第九篇文章，主题是 Perfetto 中的 CPU 信息分析。Perfetto 提供了远超 Systrace 的数据可视化与分析能力，理解 CPU 相关信息是定位性能瓶颈、分析功耗问题的基础。

本系列的目标，就是通过 Perfetto 这个工具，从一个全新的图形化视角，来审视 Android 系统的整体运行，同时也提供一个学习 Framework 的新途径。或许你已经读过很多源码分析的文章，但总是对繁杂的调用链感到困惑，或者记不住具体的执行流程。那么通过 Perfetto，将这些流程可视化，你可能会对系统有更深入、更直观的理解。

本篇是 Perfetto 系列文章的第八篇，主要深入介绍 Android 中的 Vsync 机制及其在 Perfetto 中的表现形式。文章将从 Perfetto 的角度来分析 Android 系统如何基于 Vsync 信号进行帧渲染和合成，涵盖 Vsync、Vsync-app、Vsync-sf、VsyncWorkDuration 等核心概念。

随着高刷新率屏幕的普及，理解 Vsync 机制变得更加重要。本文将以 120Hz 刷新率为主要叙事线，帮助开发者理解现代 Android 设备中 Vsync 的工作原理，以及如何在 Perfetto 中观察和分析 Vsync 相关的性能问题。

注：本文内容基于 Android 13~16 的公开实现与演进；文中代码以 AOSP main 的“签名对齐精简摘录”为主，少量位置使用 ... 省略非主线逻辑，请以当前分支源码为准。

本篇是 Perfetto 系列文章的第七篇，主要介绍 Android App 中的 MainThread 和 RenderThread，也就是大家熟悉的主线程和渲染线程。文章会从 Perfetto 的角度来看 MainThread 和 RenderThread 的工作流程，涉及卡顿、软件渲染、掉帧计算等相关知识。

随着 Google 正式推出 Perfetto 工具替代 Systrace，Perfetto 在性能分析领域已经成为主流选择。本文将结合 Perfetto 的具体 trace 信息，帮助读者理解 MainThread 和 RenderThread 的完整工作流程，让你在使用 Perfetto 分析性能问题时能够：

• 准确识别关键 trace tag：知道 UI Thread、RenderThread 等关键线程的作用
• 理解帧渲染的完整流程：从 Vsync 信号到屏幕显示的每个步骤
• 定位性能瓶颈：通过 trace 信息快速找到卡顿和性能问题的根因

本文是 Android Perfetto 系列的第六篇，主要介绍 Android 设备上 120Hz 刷新率的相关知识。如今，120Hz 已成为 Android 旗舰手机的标配，本文将讨论高刷新率带来的优势和挑战，以及从系统角度解析 120Hz 的工作原理。

在过去的几年中，移动设备的屏幕刷新率经历了从 60Hz 到 90Hz，再到现在普遍的 120Hz 的演进过程。这种提升不仅带来了更流畅的视觉体验，也对系统架构和应用开发提出了新的要求。通过 Perfetto 工具，我们可以更直观地理解高刷新率设备上帧渲染的过程和性能表现。

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

Choreographer 的引入主要是配合 Vsync，为上层应用的渲染提供稳定的 Message 处理时机。当 Vsync 信号到来时，系统通过对 Vsync 信号周期的调整，控制每一帧绘制操作的时机。目前主流手机的屏幕刷新率已达到 120Hz，即每 8.3ms 刷新一次，系统为配合屏幕刷新频率，相应调整 Vsync 周期。每个 Vsync 周期到来时，Vsync 信号唤醒 Choreographer 执行应用的绘制操作，这正是引入 Choreographer 的主要作用。了解 Choreographer 还可以帮助应用开发者深入理解每一帧的运行原理，同时加深对 Message、Handler、Looper、MessageQueue、Input、Animation、Measure、Layout、Draw 等核心组件的认识。许多 APM（应用性能监控）工具也利用了 Choreographer（通过 FrameCallback）、FrameMetrics/gfxinfo framestats（底层依赖 FrameInfo）、MessageQueue（通过 IdleHandler）和 Looper（通过自定义 MessageLogging）这些组合机制进行性能监测。深入理解这些机制后，开发者可以更有针对性地进行性能优化，形成系统化的优化思路。