EN

Android Performance

闻道有先后,术业有专攻,如是而已

loading
「置顶」我做了什么

这篇置顶页只做一件事:把我长期维护、正在推进、已经公开和暂未公开的项目集中到一个地方。范围包括 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 性能优化必知必会

SmartPerfetto 两周更新:从 Perfetto AI Assistant 到可复用的 Trace 分析平台

SmartPerfetto 更新封面

4 月 29 日写 SmartPerfetto 开源介绍时,重点还是“在 Perfetto UI 里放一个能查 SQL、跑 Skill、生成报告的 AI Assistant”。两周后的仓库状态已经变了不少:功能从单条 trace 的问答,扩到了分析结果复用、多 trace 横向比较、Claude/OpenAI 双 runtime、SQL guardrail、证据来源索引、免安装包、渲染管线教学和更完整的 Provider 诊断。

本文基于 2026 年 5 月 17 日的 SmartPerfetto 当前仓库状态,补一篇新的功能说明。读者看完应该能知道三件事:这两周新增了什么、现在完整功能边界在哪里、报 bug 时该提供哪些信息。

项目地址:

SmartPerfetto 开源:面向 Android Trace 分析的 Perfetto AI Assistant

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、组织证据,再把结论和数据表格流式显示在浏览器里。

项目地址:

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

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

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

万字长文推演:手机不再从 App 开始,Agent OS 如何接管任务入口

以 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 跑在本地三周后,发现它根本不是聊天机器人

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

Android Perfetto 系列 10 - Binder 调度与锁竞争

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

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

Android Perfetto 系列 9 - CPU 信息解读

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

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

Android Perfetto 系列 8:深入理解 Vsync 机制与性能分析

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

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

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

Android Perfetto 系列 7 - MainThread 和 RenderThread 解读

本篇是 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 系列 6:为什么是 120Hz?高刷新率的优势与挑战

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

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