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 分析套路和关键 Log 介绍，系列文章目录如下
本篇是 Perfetto 系列文章的第三篇，前两篇介绍了 Perfetto 是什么以及 Perfetto Trace 怎么抓，本篇主要是在网页端打开 Perfetto Trace 之后，面对复杂的 Perfetto 信息该怎么看。
Android 官方将 Systrace 列为 legacy 工具，并推荐在 Android 10 及以上使用 Perfetto。写下本文时，Perfetto 在我的日常工作中已基本取代 Systrace，我接触到的 OPPO、vivo 团队也在迁移，因此用这个系列继续介绍如何观察 Android 系统。
技术核查：2026-10-14。 保留 2024 年界面与案例截图，快捷键和分析语义按官方文档及 v58.3（
11fbaed83636）源码补充。原始案例 Trace 未随文提供，图中的唤醒链和数值不当作新版本实测结果。
上一篇文章 Android Perfetto 系列 1：Perfetto 工具简介 介绍了 Perfetto 是什么，这篇简单介绍一下 Perfetto 的抓取。
Android 官方将 Systrace 列为 legacy 工具，并推荐在 Android 10 及以上使用 Perfetto。写下本文时，Perfetto 在我的日常工作中已基本取代 Systrace，我接触到的 OPPO、vivo 团队也在迁移，因此希望把原来的 Systrace 分析方法用 Perfetto 再讲一遍。
技术核查：2026-10-14。 本文以 Android 12+ 设备为主要示例，保留 2024 年截图；旧系统与新版 UI 的差异在对应段落说明。命令和配置按官方文档、脚本核对，本文未新增真机采集结果。
本篇是 Perfetto 系列文章的第一篇，主要是简单介绍 Perfetto 工具，包括 Perfetto 的历史、发展，以及 Perfetto 能做什么。
Android 官方将 Systrace 列为 legacy 工具，并推荐在 Android 10 及以上使用 Perfetto。写下本文时，Perfetto 在我的日常工作中已经基本取代 Systrace，我接触到的 OPPO、vivo 团队也在迁移。许多新接触 Android 性能优化的小伙伴面对复杂的界面和功能，希望我能把之前的 Systrace 文章用 Perfetto 来呈现。
技术核查：2026-10-14。 本文初稿和截图来自 2024 年，保留当时的使用体验。下面补充 Android 10/11/12 的数据源边界，以及 Perfetto v48.0/v49.0 的 UI 更新；具体可见数据仍取决于设备、采集配置和工具版本。
Perfetto 在我的日常工作中已基本替代旧的 Systrace 工作流。Android 官方建议在 Android 10 及以后使用 Perfetto，并将 Systrace 命令行工具列为 legacy。许多新接触 Android 性能优化的小伙伴觉得 Perfetto 的界面和功能复杂，希望我能把之前的 Systrace 文章用 Perfetto 重新呈现，于是有了这个系列。
2023 年，公开研究披露了某款 Android App 中的漏洞利用代码和动态下发的 DEX。我想看看这些代码尝试调用哪些系统能力，于是有了这篇文章。当时准备仓促，有些代码没有仔细看；下面保留分析过程，并修正能从截图和 AOSP 源码确认的问题。原始文章和代码链接如下：
我不是安全方面的专家。关于漏洞背景，可以参考 Android 反序列化漏洞攻防史话。本文不复现漏洞链，也不把某个接口调用直接等同于已获得 root。
2022.3.25 ，周五晚上九点，The Performance 知识星球(付费版本)举办了第一次线上茶话会，3 位星球主理人 + 5 位星球嘉宾，50 多位球友参加，非常感谢各位！
第一次茶话会没有预设主题，预计 1 个小时就可以结束，结果聊了 2 个半小时，光是主理人和嘉宾的个人介绍就花了一个小时。平时大家在群里和星球里交流很多，但是通过语音在线交流还是第一次，再者大家的公司基本上涵盖了 Android 上下游：既有 App 大厂的大佬，也有一线手机厂商的系统大咖，也有芯片公司和造车新势力的资深专家。所以在每个人自我介绍的时候，会聊一些公司相关的东西，再发散一下，其他人再问一些问题，时间就过去了。
当时我们还计划不定期举办星球茶话会，把主题定得更明确，也邀请更多嘉宾一起聊，不局限于技术。考虑到隐私问题，这次没有录屏；下面的文字稿根据聊天内容部分还原，不涉及各位的隐私。
本文是 Systrace 线程 CPU 运行状态分析技巧系列的第三篇，本文主要讲了使用 Systrace 分析线程状态时遇到的 Sleep 与 Uninterruptible Sleep 状态的原因排查方法与优化方法，它们常见于正常等待，也可能拖慢关键路径，需要结合等待条件和依赖关系判断。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。Systrace 基础和实战系列大家可以在 Systrace 基础知识 - Systrace 预备知识 或者 博客文章目录 这里看到完整的目录
本文是 Systrace 线程 CPU 运行状态分析技巧系列的第二篇，主要分析了 Systrace 中线程的 Running 状态出现的原因和 Running 过长时的一些优化思路。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。Systrace 基础和实战系列大家可以在 Systrace 基础知识 - Systrace 预备知识 或者 博客文章目录 这里看到完整的目录
本文是 Systrace 线程 CPU 运行状态分析技巧系列的第一篇，主要分析了 Systrace 中线程的 Runnable 状态出现的原因和 Runnable 过长时的一些优化思路。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。Systrace 基础和实战系列大家可以在 Systrace 基础知识 - Systrace 预备知识 或者 博客文章目录 这里看到完整的目录
2021 已经过去，趁着元旦假期，回顾一下 2021，随意一些，想到哪里写哪里吧。主要是对 2021 年的一个回顾，以及 2022 年的展望，2021 年当了爸爸，换了工作（中间还居家无聊了好久），收获了更多的朋友，也算是过的还可以
不过在个人成长方面，甚至感觉有点退步，这让我觉得有点慌，学如逆水行舟，不进则退，2022 年是需要好好深耕的一年，希望能和看到这篇文章的同学一起进步，共勉
另外也盘点了一下知识分享相关的数据，分享了一下这方面的收入，个人新增和推荐的硬件、个人推荐的软件等，感兴趣的可以自取
最近读了一本新书：《打造流畅的 Android App》，京东链接：https://item.jd.com/10035215362170.html 。因为书名所以买了这本书，读完之后觉得有必要写一篇文章，让还没有买此书的同学了解一下
我个人的建议是：如果你是个老鸟，不建议买，这本书里面没有介绍太多原理性的东西，对于 Android 流畅性也没有一个比较全面的介绍；如果你是新手，这本书用来当做开阔视野 + 查漏补缺还可以，想更深入的了解 Android 流畅度还是差了点东西
之所以我会这么建议，是因为这本书确实没有讲太多性能或者流畅度相关的东西，也没有比较深入的原理部分，篇幅更多在讲静态代码审查、AS Profiler 的使用、App 架构、保活、网络性能优化、APK 大小优化、App 耗电等，内容也不深，浅尝辄止
在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 常被放在一起。它们可能有共同原因，也可能同时出现，但不是按严重程度划分的三个等级。用户说“卡”，还需要分清是动画不连贯、操作后等得太久，还是系统触发了无响应判定。
动画或列表滚动的不连贯通常称为 Jank；应用启动、亮灭屏或场景切换耗时过长属于 响应慢（slow response / high latency）；ANR 则由具体的系统超时条件触发。掉帧率、启动耗时和 ANR 率各有测量口径，分析时要分开。
本文是响应速度系列的第三篇，主要是讲在使用 Systrace 分析应用响应速度问题的时候，其中的一些延伸知识，包括启动速度测试、Log 输出解读、Systrace 状态解读、三方启动库等内容
在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 常被放在一起。它们可能有共同原因，也可能同时出现，但不是按严重程度划分的三个等级。用户说“卡”，还需要分清是动画不连贯、操作后等得太久，还是系统触发了无响应判定。
动画或列表滚动的不连贯通常称为 Jank；应用启动、亮灭屏或场景切换耗时过长属于 响应慢（slow response / high latency）；ANR 则由具体的系统超时条件触发。掉帧率、启动耗时和 ANR 率各有测量口径，分析时要分开。
本文是响应速度系列的第二篇，主要是以 Android App 冷启动为例，讲解如何使用 Systrace 来分析 App 冷启动
在讨论 Android 性能问题的时候，卡顿、响应速度、ANR 常会一起出现，部分原因也会重叠，但它们不是按严重程度划分的同一个问题。画面节奏异常、操作反馈延迟和具体超时机制触发的 ANR，需要分别确认。用户说“手机卡”或“App 卡”时，可以先把它当作宽泛的体验描述，再问清发生了什么、从哪个动作到哪个结果变慢。
动画播放或列表滑动不连贯，通常称为 Jank；应用启动、亮灭屏或场景切换耗时较长，可描述为 响应慢（slow response / high latency）；ANR 则是 Application Not Responding。这些说法帮助组织问题，不是互斥分类；高延迟也可能同时伴随卡顿，ANR 还要按具体触发类型分析。
另外在 App 或者厂商内部，卡顿、响应速度、ANR 这几个性能指标都是有单独的标准的，比如 掉帧率、启动速度、ANR 率等，所以针对这些性能问题的分析和优化能力，对开发者来说就非常重要了
本文是响应速度系列的第一篇，主要讲响应速度相关的理论知识，包括性能工程概述、响应速度涉及到的知识点，以及分析方法。
不同的人对流畅性(卡顿掉帧)有不同的理解，对卡顿阈值也有不同的感知，所以有必要在开始这个系列文章之前，先把涉及到的内容说清楚，防止出现不同的理解，也方便大家带着问题去看这几篇问题，下面是一些基本的说明
- 对手机用户来说，卡顿包含了很多场景，比如在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操作没有反应然后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟我们开发人员所理解的卡顿还有点不一样，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差异，这一点在处理用户(或者测试人员)的问题反馈的时候尤其需要注意
- 对开发人员来说，可以先按 流畅度（画面节奏不连贯）、响应速度（操作后等待过长）和 稳定性（崩溃、ANR 等）整理反馈。这些现象可能重叠；点击没有响应不一定是稳定性故障，需要结合输入、应用状态和日志进一步分类。
- 技术上，这三类问题并不是同一个 Message 超时机制的不同阈值。主线程长任务会同时影响输入和绘制，但 GPU、SurfaceFlinger、显示链路、线程调度或远端服务也可能造成延迟。ANR 由具体输入/组件等超时规则触发，崩溃则另有异常或信号等原因；不能仅凭一次长 Message 判定它们。
- 流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容之后，再去分析响应速度和稳定性问题会事半功倍
- 流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之所以 Systrace 为切入点，是因为影响流畅度的因素很多，有 App 自身的原因、也有系统的原因。而 Systrace(Perfetto) 工具可以从一个整机运行的角度来展示问题发生的过程，方便我们去初步定位问题
不同的人对流畅性(卡顿掉帧)有不同的理解，对卡顿阈值也有不同的感知，所以有必要在开始这个系列文章之前，先把涉及到的内容说清楚，防止出现不同的理解，也方便大家带着问题去看这几篇问题，下面是一些基本的说明
- 对手机用户来说，卡顿包含了很多场景，比如在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操作没有反应然后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟我们开发人员所理解的卡顿还有点不一样，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差异，这一点在处理用户(或者测试人员)的问题反馈的时候尤其需要注意
- 对开发人员来说，可以先按 流畅度（画面节奏不连贯）、响应速度（操作后等待过长）和 稳定性（崩溃、ANR 等）整理反馈。这些现象可能重叠；点击没有响应不一定是稳定性故障，需要结合输入、应用状态和日志进一步分类。
- 技术上，这三类问题并不是同一个 Message 超时机制的不同阈值。主线程长任务会同时影响输入和绘制，但 GPU、SurfaceFlinger、显示链路、线程调度或远端服务也可能造成延迟。ANR 由具体输入/组件等超时规则触发，崩溃则另有异常或信号等原因；不能仅凭一次长 Message 判定它们。
- 流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容之后，再去分析响应速度和稳定性问题会事半功倍
- 流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之所以 Systrace 为切入点，是因为影响流畅度的因素很多，有 App 自身的原因、也有系统的原因。而 Systrace(Perfetto) 工具可以从一个整机运行的角度来展示问题发生的过程，方便我们去初步定位问题
不同的人对流畅性(卡顿掉帧)有不同的理解，对卡顿阈值也有不同的感知，所以有必要在开始这个系列文章之前，先把涉及到的内容说清楚，防止出现不同的理解，也方便大家带着问题去看这几篇问题，下面是一些基本的说明
- 对手机用户来说，卡顿包含了很多场景，比如在 滑动列表的时候掉帧、应用启动白屏过长、点击电源键亮屏慢、界面操作没有反应然后闪退、点击图标没有响应、窗口动画不连贯、滑动不跟手、重启手机进入桌面卡顿 等场景，这些场景跟我们开发人员所理解的卡顿还有点不一样，开发人员会更加细分去分析这些问题，这是开发人员和用户之间的一个认知差异，这一点在处理用户(或者测试人员)的问题反馈的时候尤其需要注意
- 对开发人员来说，可以先按 流畅度（画面节奏不连贯）、响应速度（操作后等待过长）和 稳定性（崩溃、ANR 等）整理反馈。这些现象可能重叠；点击没有响应不一定是稳定性故障，需要结合输入、应用状态和日志进一步分类。
- 技术上，这三类问题并不是同一个 Message 超时机制的不同阈值。主线程长任务会同时影响输入和绘制，但 GPU、SurfaceFlinger、显示链路、线程调度或远端服务也可能造成延迟。ANR 由具体输入/组件等超时规则触发，崩溃则另有异常或信号等原因；不能仅凭一次长 Message 判定它们。
- 流畅性这个系列主要是分析流畅度相关的问题，响应速度和稳定性会有专门的文章介绍，在理解了流畅性相关的内容之后，再去分析响应速度和稳定性问题会事半功倍
- 流畅性这个系列主要是讲如何使用 Systrace (Perfetto) 工具去分析，之所以 Systrace 为切入点，是因为影响流畅度的因素很多，有 App 自身的原因、也有系统的原因。而 Systrace(Perfetto) 工具可以从一个整机运行的角度来展示问题发生的过程，方便我们去初步定位问题
本文是 Systrace 系列文章的第五篇，主要是对 SurfaceFlinger 的工作流程进行简单介绍，介绍了 SurfaceFlinger 中几个比较重要的线程，包括 Vsync 信号的解读、应用的 Buffer 展示、卡顿判定等，由于 Vsync 这一块在 Systrace 基础知识 - Vsync 解读 和 Android 基于 Choreographer 的渲染机制详解 这两篇文章里面已经介绍过，这里就不再做详细的讲解了。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
本文是 Systrace 系列文章的第十二篇，主要是对 Systrace 中的 CPU 信息区域(Kernel)进行简单介绍，简单介绍了如何在 Systrace 中查看 Kernel 模块输出的 CPU 相关的信息，了解 CPU 频率、调度、锁频、锁核相关的信息
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
本文是 Systrace 系列文章的第十一篇，主要是对 Systrace 中的 Triple Buffer 进行简单介绍，简单介绍了如何在 Systrace 中判断卡顿情况的发生，进行初步的定位和分析，以及介绍 Triple Buffer 的引入对性能的影响
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
本文是 Systrace 系列文章的第十篇，主要是对 Systrace 中的 Binder 和锁信息进行简单介绍，简单介绍了 Binder 的情况，介绍了 Systrace 中 Binder 通信的表现形式，以及 Binder 信息查看，SystemServer 锁竞争分析等
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
本博客内容主要集中在 Android 开发和优化相关的话题，包括一些性能工具的使用、Android App 优化知识、Android Framework 知识讲解，性能理论知识讲解等，这里整理了一份目录供大家参考，大家可以挑感兴趣的部分来看。这里不仅仅包含博客中的内容，一些我在 知乎 或者已停止运营的 The Performance 社群中的历史回答也会放到这里，不过这个目录里面放的都是我原创的博客，另外还收集了一些优秀文章，我也会不定期更新 Android 性能优化必知必会。
文章索引在前，工具、App 和内容项目集中在后面的个人项目。新增：AIW 开源介绍 · AIW GitHub 仓库。
本文是 Systrace 系列文章的第七篇，主要是是介绍 Android 中的 Vsync 机制。文章会从 Systrace 的角度来看 Android 系统如何基于 Vsync 每一帧的展示。Vsync 是 Systrace 中一个非常关键的机制，虽然我们在操作手机的时候看不见，摸不着，但是在 Systrace 中我们可以看到，Android 系统在 Vsync 信号的指引下，有条不紊地进行者每一帧的渲染、合成操作，使我们可以享受稳定帧率的画面。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些
本文是 Systrace 系列文章的第九篇，主要是是介绍 Android App 中的 MainThread 和 RenderThread，也就是大家熟悉的主线程和渲染线程。文章会从 Systrace 的角度来看 MainThread 和 RenderThread 的工作流程，以及涉及到的相关知识：卡顿、软件渲染、掉帧计算等
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些
本文是 Systrace 系列文章的第六篇，主要是对 Systrace 中的 Input 进行简单介绍，介绍其 Input 的流程； Systrace 中 Input 信息的体现 ，以及如何结合 Input 信息，分析与 Input 相关的问题
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
这篇文章记录的是 2019 年遇到的后台动画问题：应用界面不可见了，进程里却仍有动画工作在执行。但是当用户知道一个 App 退到后台之后还在持续做无效的动画，而这个动画完全是无意义的，而且用户还不知道他在做动画，消耗用户那可怜的电量的时候，轻则被多任务杀掉，禁止后台运行，重则直接卸载。
这个问题容易被忽略。当时我使用 Systrace ，在多开应用后退回桌面，左右滑动并抓取 Systrace ，发现部分已离开的应用仍在频繁执行动画回调。复查时应固定操作和应用版本，并记录界面可见性，不能把“打开很多应用”当成必要或充分条件。
这里讨论的是界面已不可见、业务也不再需要，却仍持续推进的动画。它会增加不必要的工作；但进程还活着不等于能无限制使用 CPU，现代系统还可能冻结 cached 进程。往 Choreographer 提交动画回调的入口很多，最终要结合具体调用栈、播放状态和库版本定位，不能仅凭一个 animation slice 判定原因
本文介绍了 App 开发者不经常接触到但是在 Android Framework 渲染链路中非常重要的一个类 Choreographer。包括 Choreographer 的引入背景、Choreographer 的简介、部分源码解析、Choreographer 与 MessageQueue、Choreographer 和 APM，以及手机厂商基于 Choreographer 的一些优化思路
Choreographer 让动画、部分输入处理和 View 更新围绕显示时序协调执行。它在有待处理工作时请求帧回调，而不是每个物理刷新周期都无条件唤醒 App。2019 年常见的 60Hz 屏幕刷新间隔约为 16.67ms；90Hz、120Hz 分别约为 11.11ms、8.33ms，现代设备还可能动态切换刷新率。回调及时不等于画面已经呈现，后续还涉及 RenderThread、GPU 和合成显示链路。了解这套流程，也有助于理解 Message、Handler、Looper、MessageQueue、Measure、Layout 和 Draw。
写这篇文章的契机是因为一个实际遇到的问题, 这个问题其实不难, 不过在分析了这个问题然后写日记的时候, 我突然觉得这个问题分析的过程有必要记录一下, 分享给大家 . 分析过程中有用到一些工具, 一些方法, 也从另外一个聪明的小伙伴梅明那里学到了一些分析技巧和工具的使用技巧 .
这篇文章中分析过程包括我之前在Android 中的卡顿丢帧原因概述 - 方法论 里面提到的一些工具, 包括 : 复现视频 \ Event Log \ Android Studio 源码和 App Debug \ Android Studio Profile \ Systrace \ Dumpsys \ PS 等 . 大多数工具大家都在开发过程中使用过, 这次分析正是使用了这些工具相互配合, 最终找到的问题的原因.
大家看下来可能会觉得, 这么简单一个问题还需要写一篇文章 ? 我写这篇文章的目的一是为了记录给自己, 二是觉得分析过程比较有普遍性, 包括分析思路和工具的使用, 如果可以帮助到大家, 那么最好不过了, 如果你也有好的思路或者独家调试技巧, 欢迎大家扫描关于我 里面的讨论群二维码加入群聊, 共同进步!
技术复核 · 2026-10-13。 保留 2019 年原图、线程列表与作者观点。技术核对基线为 AOSP
android-9.0.0_r1、android-16.0.0_r1；补充 API 31 帧时序与 DataStore 1.2.1 等现代入口。截图不是当前应用版本的测试结果，本次未做原设备或完整 Trace 复现。
在Android 中的卡顿丢帧原因概述 - 系统篇 这篇文章中我们列举了系统自身原因导致的手机卡顿问题, 这一篇文章我们主要列举一些由于 App 自身原因导致的卡顿问题. 各位用户在使用 App 的时候, 如果遇见卡顿现象, 先别第一时间骂手机厂商优化烂, 先想想是不是这个 App 自己的问题.
手机厂商和 App 团队会使用 Matrix 或自有方案收集线索，系统权限可增加可见信息，但数据范围仍取决于构建、采集配置和平台支持。
平均 FPS 不能单独代表流畅度。相同的 55 FPS 可以有不同的帧间隔和停顿分布；分析时需要目标节奏、实际呈现和输入响应，不能把 60→55 直接当作具体掉帧原因。本系列四篇如下：
技术复核 · 2026-10-13。 本文案例与截图来自 2019 年。此次按 Android 8.1/9/16 的相关源码、Linux v6.6 文档及现行 Android 文档核查，保留原始图片和作者经验；修正将长 slice、核号、内存回收或输入节奏直接等同根因的结论。没有重新运行原设备或回放完整 Trace，缺少的现场条件不作补造。
在应用篇中，我们列举了应用侧的卡顿问题。这一篇沿系统服务、显示、调度和内存路径整理案例。各设备的硬件、内核与厂商实现不同，定位时应保留系统版本和具体配置。
手机厂商和 App 开发者通常会通过优化组、Matrix 或自有监控方案收集线索。系统权限有助于获取更多数据，但采集范围仍受构建类型、内核配置和数据源开关影响。
流畅度不能仅等同于平均 FPS。60 Hz 下的一秒平均 55 FPS，无法说明延迟集中在哪几帧，也不能直接代表所有人的感知；应检查目标节奏、实际呈现间隔和输入响应。静止界面不需要每个刷新周期提交新内容。本系列四篇如下：
技术复核 · 2026-10-13。 本文保留 2019 年厂商优化组的工作经验与当时的行业观点。技术部分补充 Android 12（API 31）FrameTimeline、JankStats 与 Macrobenchmark 的适用边界；Looper 日志语义按 AOSP
android-9.0.0_r1/android-16.0.0_r1核对，Matrix 功能以 v2.1.0 文档为版本示例。本文未进行新的设备测量。
Android 手机使用中的卡顿问题，手机厂商和 App 开发商都会重视，内部一般会有基础组或者优化组负责分析和优化。
第三方工具如腾讯 Matrix 可以提供应用侧性能线索。厂商也会有自己的监控方案，借助系统源码和相应调试权限获取更深层数据；实际可见范围仍取决于系统版本、内核配置、构建类型和采集开关。
流畅度不能只用一秒内的平均 FPS 表示。相同的平均 55 FPS，可能包含一次明显停顿，也可能是较均匀的帧间隔，体验并不相同。要结合目标更新节奏、实际呈现间隔和输入响应看问题。60/90/120 Hz 的刷新间隔分别约为 16.67/11.11/8.33 ms，但它们不是所有线程合计的固定 CPU 时间预算；静止界面也不需要每个刷新周期都提交新内容。
引起卡顿的原因可能来自 App、系统、内核或显示链路。本系列分为四篇：
技术复核 · 2026-10-13。 本文保留 2019 年四种启动模式的操作记录，按 AOSP
android-9.0.0_r1、android-16.0.0_r1核对任务选择、affinity 与最近任务行为，并补充 Android 12（API 31）的 singleInstancePerTask。旧记录未注明设备完整版本，本次没有真机重跑，不能当作当前系统的逐步实测。
Android 中的 Activity 有几种重要的启动模式：standard、singleTop、singleTask、singleInstance。网上讲这些模式的文章不少，我这里写了个 Demo，想从任务中的 Activity 排列给大家看它们的区别；较新的 singleInstancePerTask 放在后面补充。
普通任务内导航通常后进先出。下方 A -> B 表示操作顺序；“栈内容”按顶部在前列出实际排列。留意每一步之后的变化，边操作边对照会好理解一些。重复发起启动不一定增加实例。Task 是系统管理的任务，不等于进程，也不等于最近任务列表中的一张卡片。
Demo 我也放到了 GitHub：AndroidLunchModeTest。本次核对的快照为 eaa1f987e332e0f85187a911ad9ae01cd20fff05。工程 compile/target SDK 29、min SDK 26；源码包名为 com.example.lunchmodetest，与下方保留的旧日志 com.example.launchmodetest 不同。
运行前需要按每个案例核对所有跳转目标：快照中 MainActivity.startSingleTopActivity 实际跳到 SingleTaskActivity，StandardActivity 默认跳到 SingleInstanceWithAffinityActivity，仅改一个目标无法自动跑完全部案例。类名 WithAffinity 表示旧命名，实际 manifest 配置为空 affinity；SingleTopWithAffinityActivity 甚至未声明 singleTop，不能凭类名判断模式。本次只核查代码，没有改动或编译这个示例工程。
下面先按同一用户、普通前台 Activity 发起、无额外 Intent flags 的条件解释。若把旧工程升级到 target SDK 31+，还需为带 intent-filter 的组件显式配置 android:exported，其中 Launcher 入口设为 true。
技术复核 · 2026-10-13。 本文 2019 年的截图和日志保留为历史案例，不代表当前设备的性能。源码以 AOSP android-9.0.0_r1、android-16.0.0_r1 为核对基线。缓存原理仍有参考价值；原文关于逐帧重新分配、固定性能排序、用 gfxinfo 推断 CPU 负载的说法已修正。案例六与案例一整段日志重复，测量来源尚不能确认。
硬件加速与软件加速很多人会把 Android 中的硬件加速和 Hardware Layer 搞混，以为启用了硬件加速，就是启用了 Hardware Layer。所以在说 Hardware Layer 之前，我们先说一下硬件加...
2026-10-13 技术更新：本文保留 2019 年起积累的旧 Systrace 截图，其中也有后补的案例。颜色与快捷键属于 legacy UI；Linux 状态说明参照 v6.6 文档，现代入口核对到 Perfetto UI v58.3（11fbaed83）。原图里的 Self Time、唤醒及调度状态注释有几处不准确，已在相邻正文说明；截图不等于本次设备实测。
本文是 Systrace 系列文章的第二篇，主要是讲解一些分析 Systrace 的预备知识, 有了这些预备知识, 分析 Systrace 才会事半功倍, 更快也更有效率地找到问题点.
本文介绍了如何查看 Systrace 中的线程状态, 如何对线程的唤醒信息进行分析, 如何解读信息区的数据, 以及介绍了常用的快捷键. 通过本篇文章的学习, 相信你可以掌握进程和线程相关的一些信息, 也知道如何查看复杂的 Systrace 中包含的关键信息
2026-10-13 技术更新：保留原有历史截图和代码。文中代码片段已对照 AOSP
android-10.0.0_r1，现代差异以android-16.0.0_r1为例；这不表示原截图运行的就是这些版本，原始 Trace、ROM 和构建信息并未附上。窗口动画归属、StartingWindow 与线程相互影响的旧说法已在下文修正。
本文是 Systrace 系列文章的第四篇，主要是对 SystemServer 进行简单介绍，介绍了 SystemServer 中几个比较重要的线程，由于 Input 和 Binder 比较重要，所以单独拿出来讲，在这里就没有再涉及到。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
2026-10-13 技术更新：原文发表于 2019 年，旧 Systrace HTML 和脚本步骤保留作历史参考。现代抓取示例以 Android 11 / API 30+ 为起点；应用 Trace API、权限和数据源的版本边界另行注明。本文同时区分设备端
atrace、主机端systrace.py与perfetto，参数不能混用。
本文是 Systrace 系列文章的第一篇，主要是对 Systrace 进行简单介绍，介绍其简单使用方法；如何去看 Systrace；如何结合其他工具对 Systrace 中的现象进行分析。
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
2026-10-13 技术更新：本文原发表于 2019 年，以 60 Hz 设备解释帧节奏。60 FPS 不是所有 Android 设备的固定标准；旧文中的统一 16.67 ms 预算、帧率不匹配及功耗结论已在下文修正，并补充 Android 11 / API 30、Android 12 / API 31 起的适配与分析入口。
本文是 Systrace 系列文章的第三篇，解释一下为何大家总是强调 60 fps。这里的 FPS 指应用画面的帧率，Hz 指屏幕刷新率，两者统计的对象不同，可以参考这篇文章：新的流畅体验，90Hz 漫谈
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 的运行，从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
本文先分清帧率与刷新率，再讨论帧节奏、功耗和响应延迟。到了 90 Hz、120 Hz 设备上，仍需要让内容更新与显示时序配合，但不再把 60 FPS 或 16.67 ms 当成统一标准。
2026-10-13 技术更新：本页原标注日期为 2019 年，保留了更早教程的更新记录。旧 Systrace 工具流程已过时；历史截图、源码和实验按各篇注明的 Android 版本阅读，不能直接当作当前系统实现。新抓取与分析流程从下方 Perfetto 系列开始。
随着 Systrace 的功能越来越完善，加上 Android 版本的更迭，之前写的 Systrace 系列教程已经有点过时；另外随着自己技能的完善，从 Systrace 里挖掘了更多的信息，对解决各种性能问题很有帮助。这些技能我需要记录下来，增强自己的总结和归纳的能力，如果能帮助到看文章的人，也是极好的
本系列的目的是通过 Systrace 这个工具，从另外一个角度来看待 Android 系统整体的运行，同时也从另外一个角度来对 Framework 进行学习。也许你看了很多讲 Framework 的文章，但是总是记不住代码，或者不清楚其运行的流程，也许从 Systrace 这个图形化的角度，你可以理解的更深入一些。
版本说明（2026-10-13 核查）：本文写于 2019 年，机型评价、“90 Hz 是当时较好选择”和购机展望保留为历史看法，不是当前购买建议。下文修正刷新率、帧率和输入处理的解释，补充 Android 11/API 30 与 Android 15 QPR1 等版本的变化。原 Trace 裁图没有完整采集条件，不作为新设备实测。
PC 上高刷新率屏幕很早就出来了，但是 Android 上高刷新率屏幕出现在 Android 手机上还只是这两年的事情，尽管雷蛇在 2017 年就推出了 120Hz 屏幕的手机，但是反响平平；而个人认为今年努比亚的红魔 3 和 OnePlus ...
现象
版本说明（2026-10-13 核查）：这是 2019 年的历史案例，原文未保留完整 Trace、ROM 构建号或相关应用版本。旧调用链以下文链接的 AOSP android-9.0.0_r1 为参照，不能据此认定原设备就是该标签；另补 android-16.0.0_r1 的差异。结论限定于当时的配置和观察，不代表所有无障碍服务或这些应用的当前版本。
有用户反馈，手机在滑动的时候, 列表会一抖一抖的, 滑动桌面或者设置（只要是可以滑动的），都会出现，但是这个并不是必现，而是某些用户会出现，某些用户则不会出现。
吃瓜群众可以直接拉到下面看 罪魁祸首和自检 ，对分析问题比较感兴趣的可...
我们经常说 iOS 整机体验要比 Android 好，这里有第三方软件的功劳（iOS 版本质量要高于 Android 版本质量），当然也归功于苹果对 iOS 的封闭系统的管控。应用想上 App Store，就得先过审核，不合规就给你打回来。
今天我们要说的是系统在应用内容就绪前提供的启动过渡画面。Android 常称之为 StartingWindow，iOS 的对应概念是 Launch Screen；两者不能等同于应用启动后自己展示的广告 Activity 或业务首页。
我原先把 iOS 启动画面说成“必须是一张图片”，这里说错了：Xcode 6 发布说明明确记录 iOS 8 起支持 XIB/Storyboard 启动画面。它们帮助系统尽早给出反馈，但“点击后零延迟”不是可保证的时序。Android 的旧实现允许通过主题影响启动预览，也有禁用预览或透明窗口的路径；具体规则要看系统版本。
前言
本篇文章是自己的一个学习笔记，记录了 Android 5.0 中 hwui 中的 RenderThread 的简单工作流程。由于是学习笔记，所以其中一些细节不会太详细，我只是将大概的流程走一遍，将其工作流标注出来，下次遇到问题的时候就可以知道去哪里查。
下图是我用 Systrace 抓取的应用启动时 RenderThread 第一次 Draw 的历史 Trace。它能帮助观察线程内的执行顺序，但 DrawFrame 区间结束不等于画面已显示：还需要核对 GPU 完成、缓冲区消费、合成和显示的时点。启动期间可能先看到 StartingWindow，它的退出也不能仅凭这段 CPU Trace 判断。
技术复核（2026-10-13）：本文原写于 2015 年。Systrace 的事件时间线仍有参考价值，Eclipse / Device Monitor 入口已过期；旧脚本参数以下文核对的 AOSP
android-5.0.0_r1为准。新增命令以 Android 11 / API 30 及以上的 Perfetto 为例，旧系统差异另列。后续文章见 Android Perfetto 系列目录。
| 旧流程 | 现在的对应方式 |
|---|---|
| Eclipse / Device Monitor 的 Systrace 按钮 | Android 9 / API 28 起可用设备端 System Tracing；也可通过 ADB 采集 |
systrace.py 调用 atrace 并生成 HTML |
Perfetto 采集命令生成二进制 trace；具体事件由类别或配置文件决定 |
| 浏览器直接打开旧 HTML | 使用 Perfetto UI 导入 trace，也可用 Trace Processor 做 SQL 分析 |
| 把 user 构建理解为不能采集 | user 构建可以采集系统 trace；可见数据取决于系统、数据源、应用配置与厂商策略 |
本文是Android性能优化工具系列的第一篇，这个系列主要介绍Android性能优化过程中会使用到的一些工具，以及如何用这些工具来发现问题和解决问题。在性能优化方面，Android有不少性能工具供大家来使用，按照我们一贯地 “发现问题-解决问题”的思路来看，发现问题才是最主要的，一上来就想着如何去解决问题，反而会事倍功半。
这一篇先来简单介绍一下Systrace这个工具。
Systrace 简单介绍
Systrace 随 Android 4.1 / SDK Tools R20 推出，是系统事件跟踪与可视化工具。它把 CPU 调度、SurfaceFlinger、WindowManager、View 等已启用的事件放到同一条时间线上，帮助开发者寻找系统行为之间的关系。它不会自动采样每一个 Java 方法，也不等于完整调用栈分析器。当年的 SDK Tools R20 公告
旧流程主要由三部分组成：
- 内核事件：依赖内核已启用的 ftrace 功能和可访问的事件。调度、I/O、频率等类别的可用性要在设备上确认。
- 用户态标记与采集：系统组件通过 ATrace 写入标记，
atrace配置类别并读取跟踪数据。应用添加自己的区间可使用android.os.Trace.beginSection()/endSection()；这组公开 API 从 Android 4.3 / API 18 才提供，不是从 Android 4.1 就能直接调用。 - 主机端报告：旧
systrace.py通过 ADB 调用设备的 atrace，处理数据并生成带查看器的 HTML。采集已有系统事件不要求先修改应用代码；只有自定义业务区间需要相应埋点。
当前 Perfetto 还能接入更多数据源，不能把它的全部功能概括为 ftrace 封装。android.os.Trace 的标记仍可被 Perfetto 读取，接口说明见 Trace 和 Perfetto ATrace 文档。