1. 先搭骨架：一条帧数据到底走了哪四站
做Android性能优化或者系统开发的人，十有八九都被一个问题拷打过：我UI上明明改了颜色，屏幕上那一块像素到底是怎么变红的？点一下屏幕到画面刷新，中间隔了层了什么神仙操作？我把这些年的track和调试经验重新梳理了一遍，整理成了一条完整链路，四个站点，每一站都有独立的角色和分工，搞懂它们，你再回头看那些掉帧、黑屏、多屏适配的问题，基本一眼就能锁定凶手。
1.1 链路全景图：App、SurfaceFlinger、HWC、屏幕的四级流水线
整条链路本质上是一条产线，一头是App进程里的UI代码，另一头是物理显示屏。中间经过四个核心站点。
第一站是App进程。这一站负责最开始的"原材料加工"：把你写的Kotlin/Java代码，把XML布局，把各种Drawable，全部变成一张又一张的位图数据。注意，这里的位图还只是躺在内存里的RGB数组，它会被塞进一块叫Surface的缓冲区域里。这一站的关键角色是Choreographer、ViewRootImpl、RenderThread。
第二站是系统级的SurfaceFlinger。这是一个独立的系统进程，负责"采买质检"：App把画好的缓冲数据通过Binder扔给SurfaceFlinger，SurfaceFlinger拿着所有App窗口的缓冲数据，结合窗口的Z轴顺序、透明度、裁剪区域，把多张图层（Layer）合成成一张最终要上屏的画面。所有窗口的Layer都在这个进程里被统一管理，任何一个App崩溃掉帧，都不会直接弄花别的窗口，就是靠这一层挡住的。
第三站是Hardware Composer（HWC）。这里可以理解成"代工厂调度中心"。SurfaceFlinger虽然合成了画面，但具体用GPU合成还是硬件模块合成，是直接送显还是先回读，这取决于HWC给出的"排产方案"。HWC是硬件厂商实现的，它最清楚底层屏幕上那几百条扫描线现在什么状态。
第四站才是物理显示屏。LCD屏需要背光和液晶偏转，OLED屏需要像素自发光，这都属于硬件电路的事了。驱动把HWC送来的帧数据按行扫描刷到屏幕上，这个过程受刷新率控制——60Hz就是每秒刷60帧，120Hz就是每秒刷120帧。
这四站连起来，就是"App画图 → SurfaceFlinger合成 → HWC调度 → 屏幕显示"。你后续看任何关于Android显示的文章、源码、trace，百分之九十九的概念都能归到这个四站模型里。
1.2 一次帧刷新从触发到上屏的完整时间线
很多人对这条链路懵，不是因为不知道那几个名词，而是不知道一次完整的刷新事件在时间上是如何串起来的。我用一次手指滑动列表的场景来走一遍时间线。
某个瞬间触屏事件到达App主线程，事件处理中调用invalidate()，但真正的绘制并不是马上开始的。App侧的调度中枢Choreographer在下一个Vsync信号到达时才会回调doFrame，然后触发View的测量、布局、绘制。这里的关键是：Vsync像一个发令枪，所有App的绘制都是跟着它同步起跑的，而不是谁想画就画。
doFrame里完成的主线程工作，是把View树中所有需要更新的节点生成DisplayList（显示指令列表），注意这里还没有真正执行GPU绘制。之后主线程把DisplayList交给RenderThread，RenderThread通过OpenGL/Vulkan API把它转成GPU指令，真正调用硬件渲染，渲染输出的颜色数据写到Surface对应的Buffer里，这一步叫dequeueBuffer和queueBuffer。
紧接着，App通过Binder调用SurfaceFlinger的commitTransaction，把这个Buffer连同元数据一起提交。SurfaceFlinger收到后，会等待所有参与该帧合成的layer都提交完成，然后根据Vsync信号触发合成任务。合成结果是给到HWC，HWC决定哪些Layer直接交给硬件混流器叠加，哪些丢给GPU做处理。最后，帧数据到达显示驱动，等待下一个物理刷新周期扫描上屏。
从手指滑动到像素更新，时间上大概要经过2到3个VSYNC周期。60Hz设备上约33ms到50ms，这也是为什么总有人说"App端动画画得再好，系统一个Vsync错过就多等一帧"——这句话背后就是这个时间线。
2. 第一站：App端是怎么把UI变成像素的
2.1 View树的三角色：测量、布局、绘制
每个Activity窗口的内容，根本结构是一棵以DecorView为根的View树。画这棵树不是一次性完成的，而是每帧重复三遍角色扮演：测量（Measure）、布局（Layout）、绘制（Draw）。
测量阶段，根View（DecorView）拿着MeasureSpec——它包含了父View给的尺寸约束——遍历整棵树。每个子View根据父约束和自身layout_width/layout_height算出自己想要的尺寸。这个过程我提醒一句：测量是"自下而上确定尺寸需求"，父View把约束往下传，子View把期望尺寸往上报。很多人一开始理解反了，导致自定义View老是写出测量死循环。
布局阶段则是"自上而下分配位置"。父View拿到所有子View测量后的尺寸，把它们逐个摆放，通过layout(l,t,r,b)确定每个View的最终坐标。到这一步，所有View的位置和大小都定了。
真正让屏幕显示内容的是绘制阶段。每个View调用onDraw往Canvas上画东西，但是要注意，这里的Canvas是有状态的，画的内容不会立刻变成像素。它变成的是一堆绘制指令，被记录成DisplayList节点。比如你画了一个圆角矩形，DisplayList里记录的是"drawRoundRect(…)这条命令"，而不是那一块的像素数组。这是整个渲染体系性能好的根基——指令可以缓存，可以重放，还可以被GPU直接消费。
绘制顺序也有讲究：先画背景，再画自己，然后递归画子View，最后画前景（foreground）和滚动条。如果你的页面有重叠区域，后绘制的会盖住先绘制的，这是View和View之间遮挡关系的来源。
2.2 DisplayList与RenderThread：渲染移出主线程
Android 5.0之前，View的绘制指令会在主线程直接通过OpenGL提交给GPU，主线程一忙，页面立刻卡成PPT。5.0之后引入了RenderThread，这就是一个把渲染从主线程摘出去的经典设计。
主线程完成View树的测量、布局、绘制指令生成之后，DisplayList被同步给RenderThread。RenderThread常驻运行，它拿到DisplayList后，把它翻译成真正的GPU命令，调用底层图形库（Skia/OpenGL/Vulkan），执行绘制并提交帧缓冲。这样一来，主线程画完就立刻可以去处理下一次触摸事件、动画或者布局，而GPU侧的实际渲染开销被RenderThread吃掉。
这条设计极其重要，它决定了你在主线程里执行invalidate()的代价其实很低，真正的开销在RenderThread里。用Systrace或者Perfetto抓trace时，主线程那一排的Choreographer#doFrame段只是指令生成，后面RenderThread里的DrawFrames才是实际渲染。
很多日常开发遇到的"卡顿"，打开trace一看主线程很轻松、RenderThread反而占了满满一条，就是渲染指令太复杂，比如超大Bitmap模糊、复杂阴影、嵌套层级太多。这时候优化思路就要放到降低绘制指令复杂度上。
2.3 Surface与BufferQueue：应用和系统之间的缓冲通道
画好的指令经过GPU执行后，像素到底写到哪？答案是写到Surface背后的Buffer里。每个窗口都对应一个Surface，Surface内部是BufferQueue——这名字很直白，就是一个装着图形缓冲区的队列，生产者（App的RenderThread）往里放，消费者（SurfaceFlinger）从里面取。
BufferQueue默认情况下会预先分配多个缓冲区。早期是双缓冲：一个currentBuffer（正在显示的），一个pendingBuffer（正在绘制的）。如果生产者绘制速度过快，两个Buffer交替不过来，就发生阻塞，这就是掉帧；如果生产者来不及填充，消费者取到的是旧Buffer，画面重复显示，这就叫"丢帧但画面不撕裂"。
再往深一层，App端的RenderThread调用dequeueBuffer从BufferQueue里拿走一个空闲Buffer，用GPU渲染内容填满它。渲染完成后调用queueBuffer把它排入队列，并通过Binder通知SurfaceFlinger："我这边有一帧好了，你拿去合成吧"。SurfaceFlinger则通过acquireBuffer取回这个Buffer参与合成。
所以记住这个核心模型：生产者是App内部的一堆线程，消费者是SurfaceFlinger，中间的仓库就是BufferQueue。任何显示相关的黑屏、花屏、卡顿问题，先问一句：是Buffer生产慢了，还是消费堵住了？这一个问题能帮你砍掉一半的排查路径。
3. 第二站：SurfaceFlinger是怎么把多个窗口合成一帧的
3.1 Layer堆叠与Z轴排序
SurfaceFlinger进程里管理着一个又一个Layer，每个Layer里面装着某个App窗口（或系统窗口）的Surface内容，以及它的元数据：宽高、变换矩阵、透明度、裁剪区域等。所有这些Layer按Z轴顺序叠在一起，最终合成一张屏幕画面。Z轴顺序的来源是窗口管理服务WMS，它说了算，谁在上谁在下，和焦点、Activity状态、Dialog类型都有关系。
举个例子，你在桌面上弹了个悬浮窗，桌面Activity是一个Layer，悬浮窗是另一个Layer，它们的Z值不同，SurfaceFlinger按Z值从低到高逐个合成。悬浮窗为什么能盖住桌面？不是靠"画的晚"，而是靠Layer在合成队列里的位置靠前。
合成时的关键概念是覆盖区域：一个Layer可能完全覆盖另一个，那被覆盖的Layer根本不需要参与最终合成。SurfaceFlinger会做可见性计算，能省则省，这就是为什么你把一个不透明的Activity盖在底下那个Activity上时，底层Activity的更新其实是可以被跳过的。
3.2 合成策略：GPU合成与硬件合成（HWC）的取舍
SurfaceFlinger拿到一堆Layer后，并不是自己撸起袖子全用GPU合成就完事了。它会先问一下HWC："老哥，这些Layer你的硬件模块能直接叠出来不？"HWC是硬件厂商提供的，它知道屏幕对应的硬件混流器（Overlay Engine）有多少层物理叠加能力。
如果Layer数量少、叠加关系简单，HWC会直接说"这些我全包了"，那么所有Layer都不进GPU，直接被硬件叠加送到显示器。这种方案功耗低、性能好。如果Layer多了，或者有变形、阴影、颜色变换等奇怪操作，HWC只包一部分，剩下的丢给SurfaceFlinger用GPU合成为一个"合成好的Layer"，再交给HWC去叠加。
这套协商机制叫合成策略选择，每次帧变化时都会重新评估。开发中为什么说半透明效果、圆角背景这类操作费电？就是因为它们会打破HWC的"全包"计划，被迫走GPU合成。反过来，尽量让页面不透明，用硬件加速能直接叠加的路径，对流畅度是有好处的。
3.3 帧提交与掉帧：为什么卡顿总是发生在这一层
SurfaceFlinger是全网节奏的控制者之一，但它有自己的苦衷。每一帧的合成必须在收到所有参与合成的layer的buffer之后才能开始，而各个App提交buffer的时间是有先后的，有的App在Vsync前几毫秒才提交，有的因为绘制超时还没提交。
这里就诞生了"等帧"机制：SurfaceFlinger会设定一个提交截止时间，超过这个时间还没等到的layer，要么用旧buffer继续合成，要么干脆把这帧合成整体推迟到下一个周期。等帧导致的现象就是你看到的卡顿——列表滚动时画面有可能突然"跳一下"，因为某一帧合成晚了，中间被硬生生跳过去了。
排查帧问题最有效的工具是FrameTimeline或者Systrace里的SurfaceFlinger段。重点看每个Layer的queueBuffer时间点和composition时间点之间的差值。差值超过16.6ms，说明这里产生了合成排队的延迟，比App端掉帧更隐蔽，我早年排查一个第三方输入法卡顿问题，官方App侧trace干净得很，最后就是定位到SurfaceFlinger的合成等待上，输入法那个窗口的Layer每几帧就会迟到几毫秒，把帧节奏彻底打乱。
4. 第三站：Vsync与刷新节奏——流畅度的底层密码
4.1 Choreographer：App侧的帧调度器
Android系统里有一个"心跳"信号叫Vsync。硬件在每次屏幕刷新前后产生一个脉冲，驱动层把它上报给系统，系统再把它分发给需要同步的进程。App侧的Choreographer就是专门接收这个心跳的。
当你调用了View.invalidate()，其实只是向Choreographer注册了一个"下一帧我要干活"的callback。真正开始干活是在下一个Vsync到达时，Choreographer回调doFrame，依序执行三种回调：首先是input事件（处理触摸），然后是animation（动画插值），最后是traversal（测量布局绘制）。这三步全部做完，这一帧的主线程工作才算完。
这个设计意味着：所有App的帧节奏都被Vsync统一指挥。大家同拍起步，GPU的利用率才能最大化。如果某个App在主线程里执行了耗时操作盖过了Vsync窗口——比如一个列表里做了JSON解析，大文件的IO读写——等到Choreographer回调整体回调队列时已经错过好几个Vsync，掉帧就是必然。
所以优化App流畅度，本质是优化主线程在每个Vsync周期内的执行时间。你打开Profile GPU Rendering（开发者选项->GPU渲染模式分析），那个条形图上的横线，就是16.6ms的目标线，超了就说明这个Vsync周期内工作没干完。
4.2 双缓冲与三缓冲：一帧到底需要几个缓冲区
屏幕刷新率是60Hz时，一个Vsync周期16.6ms。理论上App必须在16.6ms内完成全部绘制和提交，否则buffer就供给不上。但现实中App的活儿经常超过16.6ms，于是就产生了缓冲区的博弈。
双缓冲初期只有两个缓冲区：一个叫back buffer（后台绘制区），一个叫front buffer（前台显示区）。App在后台画，画完了交换——注意Android里的"交换"不是推翻指针，而是通过BufferQueue的dequeue/queue机制让SurfaceFlinger取走刚画完的，并还给App一个空的。但如果App画一帧要20ms，这就和16.6ms的刷新周期错位，App偶尔会卡在dequeueBuffer上等空Buffer，表现为掉帧。
为了缓解这个问题，Android默认在多数设备上启用了三缓冲：BufferQueue里多一个Buffer。App可以连续画两帧,不必等第一个被消费完才能画第二个。三缓冲的本质是用内存换延迟，它不会提升帧率的物理上限，但能让"偶发超时"不至于立刻断流。代价是内存占用多一份全屏尺寸的像素数据。
实用经验：在开发者选项的"调试GPU过度绘制"之外,"帧计时"能直观看到双缓冲和三缓冲的区别。三缓冲治标不治本，它只是缓冲了主线程的超时，真正解决还是要让doFrame里的活少干。
4.3 刷新率、帧率与掉帧的换算关系
这块很多人眉毛胡子一把抓。刷新率是屏幕物理属性，单位Hz，它决定屏幕每秒可以刷多少帧。Android 11之前App侧的Choreographer默认跟着刷新率走。帧率是实际成功上屏的帧量，单位fps。二者不相等时，就出现了掉帧。
假设备60Hz，如果App每帧耗时都小于16.6ms，那一秒正好60帧。如果有一帧耗时30ms，那么它跨越了一个半Vsync周期，最终结果是这一秒里只有50帧左右甚至更低，掉帧10帧。注意这个掉帧不是均匀分布的，而是集中在那一帧前后造成可见的"卡"一下。
120Hz高刷屏上，一个Vsync周期是8.3ms，要求每帧完成时间减半，这对主线程的压迫更强。但高刷不是单纯为了顺滑，它更是为触控跟手度服务——触摸响应到刷新的延迟从几十毫秒降到几毫秒。做高刷适配时,要检查整个链路的耗时预算，而不是只盯着App主线程：SurfaceFlinger合成、HWC处理、驱动传输都占时间，总延迟必须控制在单个Vsync周期内。
5. 第四站：从HWC到屏幕，物理显示与帧的最终归宿
5.1 HWC如何决定合成方案
HWC这个模块平时不显山不露水，但整条链路的"最终决策"其实在它手里。它收到SurfaceFlinger的合成请求后，会去检查自己管理的硬件叠加层（Hardware Overlay Planes）是否足够。
每一块显示器控制器都有一组物理Overlay层，可以不用GPU直接把多个layer源数据叠在一起输出。如果layer数量不超过Overlay层数，而且每个layer的格式、缩放、旋转参数都在硬件支持范围内，HWC就会选择"全硬件合成"，SurfaceFlinger只当一个调度者。反之如果HWC评估后认为某些layer没法用硬件叠加，它会开启一个client合成槽位，让SurfaceFlinger用GPU先把这些layer合成为一个纹理，再把这一个结果纹理送到硬件Overlay。
这个协商结果不是一成不变的，会随Layer数量、窗口变换、分辨率变化而动态调整。比如你在画中画模式看电视直播时，内容是缩放过的视频层，Chromecast会频繁调整合成策略，从硬件直接合成切到GPU合成再到混合。开发中如果发现视频场景突然GPU占用飙升，大概率就是某个图层把HWC的全硬件方案给破坏了。
5.2 色彩管理与Display接口
帧数据到了Display层面，还要过一遍颜色管理。Android 8.0之后引入了色彩管理框架，App侧声明的色彩空间（sRGB、Display P3等）会被记录在Layer元数据里，SurfaceFlinger和HWC在合成时会把它们统一转换到显示器原生的色彩空间（常见的是Display P3或sRGB），保证不同App的色彩不会串味。
如果你的应用涉及图像编辑或视频播放，别忘了在Window的ColorSpace上做声明。我调过的一个真实case：某视频App在P3屏上播放HDR内容，结果画面泛灰，就是因为EGLSurface创建时没指定合适的色彩空间，链路最末端的Display转换把它当成了sRGB来解析，所有高光细节都给压没了。
5.3 一图流总结：把前面四站串成一张图
嘴上说了这么多，现在你把整个链路在脑子里画成一张图，从左上角到右下角，依次是：
App进程（主线程的Choreographer-doFrame测量布局绘制DisplayList → RenderThread渲染 → BufferQueue dequeue/queue） → Binder → SurfaceFlinger（Layer列表和Z轴排序 → Vsync触发合成 → GPU部分合成或全硬件直接合成） → HWC（Overlay协商和分配） → Display驱动 → 物理屏幕逐行刷新。
再把时间线叠上去：第N个Vsync触发App绘制指令生成，第N个Vsync周期内RenderThread完成渲染并提交，第N+1个Vsync触发SurfaceFlinger合成，第N+1或N+2个Vsync的显示刷新把真实像素扫到屏幕上。从请求绘制到肉眼看到，大概走2到3帧，也就是33到50ms。
这张图里任何一个环节的时间超预算，都会以"卡顿"的形式出现在用户面前。抓trace的时候按这个顺序从上往下看，先看App主线程doFrame，再看RenderThread，然后SurfaceFlinger合成段和HWC提交段，基本不会漏掉问题。
6. 实战排查：链路哪一环最容易出问题
6.1 卡顿掉帧的定位方法
卡顿排查我一般按三步走。第一步开开发者选项里的GPU渲染模式分析，先看柱状图确认是主线程超时还是渲染线程超时。绿色横线是16.6ms基准，柱状图超过红线的部分，点击datetime能看到具体哪一帧的耗时构成。
第二步抓Perfetto或Systrace。重点抓三个区域：App主线程里的Choreographer#doFrame段里是否有耗时超长的子树（一堆inflate、layout、draw），RenderThread的DrawFrames里是否有高负载的draw指令，以及SurfaceFlinger侧是否有合成等待。如果App侧干净，SurfaceFlinger侧的Waiting for Layer就是元凶。
第三步看DropFrame。通过dumpsys SurfaceFlinger --latency可以拿到最近帧的呈现时间戳，矩阵里的pending列超过屏幕刷新率对应时间的就是卡顿帧。这个命令还能看到三缓冲的占用情况，如果pending频繁接近0，说明buffer饥渴。
6.2 黑屏和花屏的排查思路
黑屏是"画面没出来"，链路里至少有三处可能导致：App进程侧Surface没有创建成功——通常是SurfaceView或者TextureView的Surface生命周期管理出错，代码里提前释放了Surface；BufferQueue丢帧太多——画了一帧但合成端一直没收到；HWC处于Idle状态——底层显示器没被点亮，常见于休眠唤醒场景接错回调。
花屏则和缓冲区的数据不完整或格式错位强相关。之前遇到一个OA办公App在部分ARM设备上花屏，最后查到是EGL环境初始化时RED_SIZE/GREEN_SIZE/BLUE_SIZE设置和SurfaceFlinger预期的RGBA8888格式不一致，渲染出来的数据在合成端解析错位，直接变成花屏。这类问题先看dumpsys SurfaceFlinger里的Layer格式，再对比EGL配置，十有八九能对上。
6.3 高刷新率下的常见坑
高刷设备普及后，最常见的问题是帧节奏混乱。很多App用固定16.6ms的动画插值器，在120Hz设备上看起来"太快了"或者"跳帧"。正确做法是使用Choreographer的帧时间戳来计算动画进度，或者使用ValueAnimator这种基于系统时钟的动画器，它们天然适配刷新率。
另一个坑是SurfaceFlinger掉到60Hz。部分机型在高负载的场景下会把刷新率整体切回60Hz，如果App侧动画还在按120Hz走，就产生了掉帧假象。排查时需要dumpsys display查看当前的DisplayMode，确认是不是被系统限频。如果是，那优化重点就不在App，而在于减少整机功耗，比如降低后台Activity的绘制频率，避免无意义的invalidate。
写到最后的一点体会
这些年我把这条链路反复看烂了，最大的感受是：Android显示链路本质上就是一条井然有序的工业化流水线，每个环节都有明确的分工，也有清晰的交接协议。理解了它，你再去看那些玄学卡顿、偶发黑屏、颜色发灰的问题，都变成了"查流水线上某个工位的作业记录"。很多问题在你打开Perfetto/Systrace的那一瞬间就已经猜到了七七八八，剩下的只是按链路顺序验证。遇到看不懂的trace段，就回到这四站模型里问一句：这是App的活，还是SurfaceFlinger的活，还是HWC/驱动的活？方向对了，答案基本也就浮出来了。最后再提醒一句：自己动手在模拟器或真机上抓一次完整的frame trace，把每一段的耗时亲手标一遍，比看十篇文章都管用。
