在 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 的统一配置。代码省略外围状态时会明确说明，片段来自不同类，不能直接拼成可编译程序。
本文介绍了 App 开发者不经常接触到但在 Android Framework 渲染链路中非常重要的一个类 Choreographer，包括 Choreographer 的引入背景、简介、部分源码解析、与 MessageQueue 的交互、在 APM 中的应用，以及手机厂商基于 Choreographer 的一些优化思路。
Choreographer 将待执行的帧回调与显示时序协调起来，而不是自行调整屏幕刷新率。以 120 Hz 为例，刷新间隔约 8.33 ms；是否能按时交付帧还取决于 CPU 调度、GPU、Buffer 和合成管线。应用按需请求回调，不是每个物理 Vsync 都要重新绘制。本文也会区分 FrameCallback、FrameMetrics、gfxinfo、Looper 和 Perfetto 各自能观察到的范围。
本文为 Android App ANR 系列的第三篇，主要分享几个 ANR 的案例，系列文章目录如下
Perfetto 在我的日常工作中已基本替代旧的 Systrace 工作流。Android 官方建议在 Android 10 及以后使用 Perfetto，并将 Systrace 命令行工具列为 legacy。许多新接触 Android 性能优化的小伙伴觉得 Perfetto 的界面和功能复杂，希望我能把之前的 Systrace 文章用 Perfetto 重新呈现，于是有了这个系列。
本文是之前星球里 Yingyun 大佬的文章，由于星球已经关闭，所以把这个关于 OS 性能设计的系列文章发到博客上
Yingyun 是资深性能优化专家，他对于系统优化有非常深入的见解，本身在国内各个手机大厂都呆过，他本人的博客还在休整中，等休整好了我再发出来，目前他在我们的微信群里很活跃，对本文有什么建议或者意见，或者说想咨询问题的可以加我们的微信群（加我微信 553000664，备注博客加群，我会拉你进去）
新开系列文章，OS 架构设计中的各种考量因素。其实不止 OS，在设计任何大型软件都涉及到此类内容。
能力与知识面有限，而且还带了非常主观的看法，肯定有不足之处。希望听到不同的思路与观点，通过观点的碰撞进而达到更进一步的认知。
本博客内容主要集中在 Android 开发和优化相关的话题，包括一些性能工具的使用、Android App 优化知识、Android Framework 知识讲解，性能理论知识讲解等，这里整理了一份目录供大家参考，大家可以挑感兴趣的部分来看。这里不仅仅包含博客中的内容，一些我在 知乎 或者已停止运营的 The Performance 社群中的历史回答也会放到这里，不过这个目录里面放的都是我原创的博客，另外还收集了一些优秀文章，我也会不定期更新 Android 性能优化必知必会。
文章索引在前，工具、App 和内容项目集中在后面的个人项目。新增：AIW 开源介绍 · AIW GitHub 仓库。
本文介绍了 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。
我们经常说 iOS 整机体验要比 Android 好，这里有第三方软件的功劳（iOS 版本质量要高于 Android 版本质量），当然也归功于苹果对 iOS 的封闭系统的管控。应用想上 App Store，就得先过审核，不合规就给你打回来。
今天我们要说的是系统在应用内容就绪前提供的启动过渡画面。Android 常称之为 StartingWindow，iOS 的对应概念是 Launch Screen；两者不能等同于应用启动后自己展示的广告 Activity 或业务首页。
我原先把 iOS 启动画面说成“必须是一张图片”，这里说错了：Xcode 6 发布说明明确记录 iOS 8 起支持 XIB/Storyboard 启动画面。它们帮助系统尽早给出反馈，但“点击后零延迟”不是可保证的时序。Android 的旧实现允许通过主题影响启动预览，也有禁用预览或透明窗口的路径；具体规则要看系统版本。
在 Android 开发中,应用启动速度是一个非常重要的点,应用启动优化也是一个非常重要的过程.对于应用启动优化,核心思想就是在启动过程中少做事情,具体实践的时候无非就是下面几种:
不用一一去解释,做过启动优化的估计都使用过,本篇文章将详细讲解一下一种延时加载的实现以及其原理.
这种加载的实现很简单,但是其中的原理可能比较复杂,还涉及到Looper/Handler/MessageQueue/VSYNC等.以及其中碰到的一些问题,还会有一些我自己额外的思考.
本篇文章是自己的一个学习笔记，记录了 Android 5.0 中 hwui 中的 RenderThread 的简单工作流程。由于是学习笔记，所以其中一些细节不会太详细，我只是将大概的流程走一遍，将其工作流标注出来，下次遇到问题的时候就可以知道去哪里查。
下图是我用 Systrace 抓取的应用启动时 RenderThread 第一次 Draw 的历史 Trace。它能帮助观察线程内的执行顺序，但 DrawFrame 区间结束不等于画面已显示：还需要核对 GPU 完成、缓冲区消费、合成和显示的时点。启动期间可能先看到 StartingWindow，它的退出也不能仅凭这段 CPU Trace 判断。
系列文章目录：
技术复核（2026-10-13）：本文保留 2015 年视频的三色柱形图。旧图的 Update / Execute / Process 可对照 Android 4.4.4 源码；Android 6.0 与 Android 16 已有更细的分段和不同参考线实现，不能把旧图例套到所有设备。
当时的视频简介：
“If you can measure it, you can optimize it” is a common term in the computing world, and for Android’s rendering system, the same thing holds true. In order to optimize your pipeline to be more efficient for rendering, you need a tool to give you feedback on where the current perf problems lie.
And in this video, +Colt McAnlis walks you through an on-device tool that’s built for this exact reason. “Profile GPU Rendering” will help you understand the stages of the rendering pipeline, and also get a chance to see what portions of it might be taking too long, and what you can do about it for your application.
Profile GPU Rendering 是开发者选项里的快速观察工具，可以帮助找到哪些操作伴随较高的绘制耗时。它的名字虽然有 GPU，柱形图却不是 GPU 硬件执行时间的直接测量，也不能单独告诉你卡顿的全部原因。官方说明
系列文章目录：
技术复核（2026-10-13）：保留 2015 年的视频简介和九张示意图。正文已修正固定 60Hz、撕裂原因以及“VSync 复制后缓冲”的说法，并补充现代 Android 的帧率提示与分析入口。
当时的视频简介：
Unbeknown to most developers, there’s a simple hardware design that defines everything about how fast your application can draw things to the screen.
You may have heard the term VSYNC - VSYNC stands for vertical synchronization and it’s an event that happens every time your screen starts to refresh the content it wants to show you.
Effectively, VSYNC is the product of two components Refresh Rate (how fast the hardware can refresh the screen), and Frames Per Second (how fast the GPU can draw images), and in this video +Colt McAnlis walks through each of these topics, and discusses where VSYNC (and the 16ms rendering barrier) comes from, and why it’s critical to understand if you want a silky smooth application.
想要理解界面为什么流畅或卡顿，需要先区分应用产帧、系统合成和屏幕呈现。VSync（垂直同步） 用来协调这些阶段的节奏，不是刷新率与 FPS 的数学乘积，也不是一个替应用完成绘制的操作。AOSP VSync 说明
系列文章目录：
技术复核（2026-10-13）：本文保留 2015 年的视频摘录和示意图。过度绘制的概念仍然适用；下文补充默认颜色表的版本依据、透明混合的例外和删除背景的前提，不把颜色变浅直接当成性能收益。
当时的视频简介：
One of the most problematic performance problems on Android is the easiest to create; thankfully, it’s also easy to fix.
OVERDRAW is a term used to describe how many times a pixel has been re-drawn in a single frame of rendering. It’s a troublesome issue, because in most cases, pixels that are overdrawn do not end up contributing to the final rendered image. As such, it amounts to wasted work for your GPU and CPU.
Fixing overdraw has everything to do with using the available on-device tools, like Show GPU Overdraw, and then adjusting your view hierarchy in order to reduce areas where it may be occurring.
视频开头作者举了一个例子，说如果你是一个粉刷匠，你应该会知道，给墙壁粉刷是一件工作量非常大的工作，而且如果你需要重新粉刷一遍的话(比如对颜色不满意),那么第一次的粉刷就白干了. 同样的道理，如果一个不透明区域完全覆盖了前面画出的内容，前面的部分绘制就可能没有贡献。如果你想兼顾高性能和完美的设计,那么你的程序可能会出现一个性能问题:OverDraw!
Overdraw（过度绘制） 指同一帧里，同一个像素被重复绘制。例如下面重叠的卡片，不透明卡片下面被完全遮住的部分可能做了无用功；但不能把“发生重叠”一律视为浪费。半透明内容、阴影和抗锯齿边缘仍需要底下的颜色参与混合，直接删掉底层会改变画面。实际工作量也受裁剪和渲染器优化影响。官方概念说明
系列文章目录：
技术复核（2026-10-13）：本文是 2015 年视频的学习笔记，Nexus 5 的例子和工具截图保留为历史材料。下方原视频简介中的 16ms 是 60Hz 的近似说法；正文已修正刷新、掉帧和调试工具的适用范围。
当时的视频简介：
Rendering performance is all about how fast you can draw your activity, and get it updated on the screen. Success here means your users feeling like your application is smooth and responsive, which means that you’ve got to get all your logic completed, and all your rendering done in 16ms or less, each and every frame. But that might be a bit more difficult than you think.
In this video, +Colt McAnlis takes a look at what “rendering performance” means to developers, alongside some of the most common pitfalls that are ran into; and let’s not forget the important stuff: the tools that help you track down, and fix these issues before they become large problems.
当你觉得自己开发了一个改变世界的应用的时候，你的用户可能并不会这么认为，他们认为你的应用又慢又卡，达不到他们所期望的那种顺滑，更谈不上改变这该死的世界了，回收站走你！等等！明明我这个应用在我的Nexus5上非常顺滑啊？你咋能说又慢又卡呢？如果你对Android的碎片化有一定了解的话，你就应该知道，很多低配置的手机并不像Nexus5那样有强大的处理器和GPU，以及没有被怎么污染的原生系统。
如果有大量的用户投诉说你的应用又卡又慢的时候，不要总是抱怨用户的低端手机，有时候问题就出在你的应用本身，可能涉及渲染、主线程阻塞等问题，需要先测量再定位。了解问题发生的根源，才能有效地解决问题。所以了解Android渲染相关的知识，是一个Android开发者必不可少的知识。
系列文章目录：
2015 年，Google 推出了关于 Android 性能优化的短视频系列 Android Performance Patterns，原播放列表在 YouTube。官方当年的配套课程介绍也记录了这个系列。
技术复核（2026-10-13）：本文保留 2015 年的选题说明和观看经历。早期视频仍可用于理解渲染问题；旧工具、Google+ 入口及“16ms”说法需要按下面的版本条件阅读。
过度绘制、VSYNC、主线程与 RenderThread 的协作仍然值得学习，但帧间隔不是永远 16ms。60Hz 对应约 16.67ms，90Hz 约 11.11ms，120Hz 约 8.33ms；实际产帧截止时间还要看系统调度和 trace，不能把一个固定阈值套到所有设备与场景。
| 要调查的问题 | 今天的入口与适用条件 |
|---|---|
| View / Compose 的层级和属性 | 用 Layout Inspector 检查可调试应用；它也支持 Compose 重组/跳过信息，不能把层级检查等同于帧耗时测量 |
| 快速观察绘制阶段和过度绘制 | 开发者选项里的 Profile GPU/HWUI Rendering、Debug GPU Overdraw；柱形图是 CPU 侧绘制阶段信号，不是纯 GPU 执行时间，也不能覆盖所有自建渲染路径。官方说明 |
| 具体哪些帧错过期限 | 使用 Perfetto 的 FrameTimeline，要求 **Android 12 / API 31+**；再结合已采集到的线程、调度和 SurfaceFlinger 轨道定位 |
| 滑动或页面切换是否退化 | Macrobenchmark FrameTimingMetric 从 AndroidX Benchmark 1.1.0 提供；frameOverrunMs 要求 **API 31+**，与 frameDurationCpuMs 的口径不同 |
Hierarchy Viewer、Traceview 所属的旧 Android Device Monitor已在 Android Studio 3.1 弃用、3.2 移除。方法级分析使用当前 Profiler，层级检查用 Layout Inspector。做 Macrobenchmark 时按项目配置要求使用接近发布状态的 non-debuggable、profileable 目标应用，并固定设备与操作场景。
当时的官方简介（原文摘录）：
Android Performance Patterns is a collection of videos focused entirely on helping developers write faster, more performant Android Applications. On one side, it’s about peeling back the layers of the Android System, and exposing how things are working under the hood. On the other side, it’s about teaching you how the tools work, and what to look for in order to extract the right perf out of your app.
But at the end of the day, Android Performance Patterns is all giving you the right resources, at the right time to help make the fastest, smoothest, most awesome experience for your users. And that’s the whole point, right?
总之就是一系列讲解Android性能相关的视频。这些小视频的时间非常短，在3-5分钟之内，主讲人的英文语速也非常快，初期这些视频没有翻译的时候，着实考验了一把听力。当时已有中英文字幕可供参考；现在具体有哪些字幕，以各视频实际提供的轨道为准。
这些视频的时间虽然很短，但是信息量却非常大，有些他一句话带过的内容，我们却需要花费很多的时间去研究他的原理，或者研究一个调试工具如何使用。也就是说，这一系列视频并没有真正教你如何去优化你的应用，而是告诉你关于Android性能优化你需要知道的知识，这样你去优化你的Android应用的时候，知道该用什么工具，该采取什么样的步骤，需要达到什么样的目标。
技术复核（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 随 Android 4.1 / SDK Tools R20 推出，是系统事件跟踪与可视化工具。它把 CPU 调度、SurfaceFlinger、WindowManager、View 等已启用的事件放到同一条时间线上，帮助开发者寻找系统行为之间的关系。它不会自动采样每一个 Java 方法，也不等于完整调用栈分析器。当年的 SDK Tools R20 公告
旧流程主要由三部分组成：
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 文档。