本博客内容主要集中在 Android 开发和优化相关的话题，包括一些性能工具的使用、Android App 优化知识、Android Framework 知识讲解，性能理论知识讲解等，这里整理了一份目录供大家参考，大家可以挑感兴趣的部分来看。这里不仅仅包含博客中的内容，一些我在 知乎 或者 知识星球 - The Performance 的回答也会放到这里，不过这个目录里面放的都是我原创的博客，另外还收集了一些优秀文章，我也会不定期更新 Android 性能优化必知必会。
这篇文章记录了 Android 性能优化所必须掌握的知识（主要是对应的优秀文章、公众号、博客、技术团队等），涵盖性能优化相关的方方面面。本文会持续更新，欢迎各位自荐或者推荐。
以 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 必须解决的五件事：
- 手机要持续理解用户的当前状态。
- App 要从前台入口变成后台能力提供者。
- 系统要有可恢复、可取消、可审计的任务运行时。
- 端侧与云端要按数据敏感度和实时性分工。
- 所有跨 App、跨设备、跨云的执行都要有权限、责任和回滚边界。
这五件事没有完成，AI 手机就只是“手机里装了一个 AI 助手”；它们一旦形成系统约束，手机才会朝 Agent OS 走。
这篇文章收集了《从 Trace 到洞察：SmartPerfetto AI Agent 的 Harness Engineering 实战》发布后收到的技术问题。它不重复正文的大段叙述，而是把最容易追问的设计点单独拆开。如果你已经读过正文，这里更适合作为二次阅读和交叉检索。
这篇文章记录了 SmartPerfetto 从零到可用过程中的关键技术决策。重点不是功能清单，而是每次架构取舍背后的约束、失败案例和修正过程。如果你也在做 AI Agent 应用，或者在做 Perfetto 这类性能分析工具，这些工程折返点应该能直接参考。
昨天那篇 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）这些组合机制进行性能监测。深入理解这些机制后，开发者可以更有针对性地进行性能优化，形成系统化的优化思路。
本篇是 Perfetto 系列文章的第四篇，如何使用 trace_processor_shell 在本地打开超过 2G 的大文件。在实际的问题分析过程中，我们经常会碰到非常大的 Trace 文件（大于 2GB），直接扔进 ui.perfetto.dev 是没法打开的，这是因为浏览器内存的限制。这时候我们就需要使用官方提供的 trace_processor_shell 工具来本地打开大文件。
随着 Google 宣布 Systrace 工具停更，推出 Perfetto 工具，Perfetto 在我的日常工作中已经基本能取代 Systrace 工具。同时 Oppo、Vivo 等大厂也已经把 Systrace 切换成了 Perfetto，许多新接触 Android 性能优化的小伙伴对于 Perfetto 那眼花缭乱的界面和复杂的功能感觉头疼，希望我能把之前的那些 Systrace 文章使用 Perfetto 来呈现。
本文为 Android App ANR 系列的第三篇，主要分享几个 ANR 的案例，系列文章目录如下
