直接切入正题：有段时间我一直在追一个“邪门”的卡顿问题，帧率曲线图里掉帧位置完全随机，CPU、内存看着都正常，折腾了两三天毫无头绪。后来硬着头皮把Android显示链路从头到尾捋了一遍，才意识到问题根本不在我盯着的那个环节。从那以后我就有个习惯：遇到任何显示相关的诡异问题，先把“从APP到屏幕”这条完整链路在脑子里过一遍，再决定在哪个环节下刀子。
写这篇东西，就是想把这条链路的全貌讲清楚。不管你是刚接触Android开发的初学者，还是已经被SurfaceFlinger折磨过几轮的老人，只要搞懂这条链路里每个环节“生产什么、交给谁、怎么交接”，绝大多数显示问题都能快速定位到具体的那一环。
1. 一张图先看清Android显示完整链路
很多人聊到显示流程，第一反应就是“不就是把View画出来嘛”。实际上，从你在代码里调一个setText()，到屏幕像素真正发生变化，中间要经过UI线程、RenderThread、进程间通信、合成器、硬件显示控制器，中间隔着好几道工序和缓冲区。我习惯把它分成三段来看：生产、交接、消费。
1.1 链路全景：生产、交接、消费三段论
生产段发生在APP进程内部。你的UI线程负责执行View的measure、layout、draw，把界面状态变成一堆绘制指令；紧接着RenderThread接手，把这些指令交给GPU执行，最终渲染结果写入一块共享内存。这块共享内存，就是“交接”段的起点。
交接段的核心是一套叫BufferQueue的机制。APP写入的缓冲区通过Binder跨进程交给系统这边的SurfaceFlinger，SurfaceFlinger把所有APP的缓冲区收集起来，决定怎么拼合成一帧画面。
消费段由SurfaceFlinger和HWC（Hardware Composer）完成。SurfaceFlinger负责把多个图层合成一张完整画面，HWC则参与把最终结果送到显示器。
这里有张经典的分层图我一直存在笔记里：上层是APP进程的View系统、RenderThread，中间是BufferQueue，下层是SurfaceFlinger、HWC、Display。整个链路无论出什么问题，先判断它发生在哪一层。
1.2 链路里的“角色分工”：每个环节都在忙什么
为了不让概念停留在纸面上，我把每个核心角色用最直白的语言解释一遍。
- UI线程（主线程）：APP的门面担当。负责处理输入事件、执行
onMeasure、onLayout、onDraw，产出DisplayList。它干得越久，你的界面就越“卡”在第一步。 - RenderThread（渲染线程）：从Android 5.0开始引入，专门接管UI线程的渲染脏活。UI线程只负责生成绘制指令，RenderThread负责把这套指令提交给GPU。
- DisplayList：不是像素，而是一张“绘制命令清单”。比如“在坐标(10,20)画一个圆，半径5，红色”。它最大的意义是可以被缓存和重放，不用每帧都从头再执行一遍View的逻辑。
- Surface：一块画布，更准确说是BufferQueue的生产端接口。每个Window对应一个Surface，你的APP往Surface上画东西。
- BufferQueue：生产者和消费者之间的缓冲区队列，经典的生产者-消费者模型。一边是APP在往队列里填缓冲区，另一边是SurfaceFlinger从队列里取缓冲区。
这几个角色串起来就是：UI线程写“菜谱”→RenderThread炒菜→菜（缓冲区）装盘→服务员（BufferQueue）端给客人（SurfaceFlinger）。
1.3 为什么非要分三层理解这条链路，而不是只盯某个阶段
因为我踩过大跟头。早先排查性能问题，我只看主线程的耗时，觉得“主线程不卡=界面流畅”。后来发现有些掉帧场景主线程耗时才5ms，画面却肉眼可见地顿挫。反过来也有主线程跑了50ms，但因为有缓冲区和异步渲染兜底，用户压根没感知。
这就是分层理解的意义：每一层都有自己的缓冲和异步机制，单看某一层永远得不出整体结论。只有同时盯着“生产耗时”“交接是否顺畅”“消费是否及时”三个维度，才能解释“为什么主线程不卡但掉帧”或者“为什么明明掉帧但用户没感觉”这类看似矛盾的现象。
2. 链路起点：APP侧怎么“生产”一帧画面
整条链路的源头是APP进程里的View绘制。这里也是大多数Android开发者最先接触、最好干预的一环。
2.1 View三件套：measure、layout、draw到底在干嘛
一个View从被加入ViewGroup到显示出来，必须经历三个阶段。
measure是量尺寸。系统从根View开始，递归调用每个子View的onMeasure，核心是确定MeasureSpec（父View对子View的尺寸约束），然后通过setMeasuredDimension记录自己想要的尺寸。这一步看着简单，但特别容易出幺蛾子：嵌套多层、match_parent和wrap_content混用、自定义View里没有正确遵循MeasureSpec，都会导致measure阶段反复执行，耗时翻倍。
layout是定位置。父View一个个调用子View的layout(l, t, r, b)，把子View摆放到确定的坐标上。这一步经常被忽略，但布局嵌套越深，递归次数越多，耗时自然就上去了。
draw是真正把内容画出来。过程分为几步：绘制背景、绘制自身内容、绘制子View、绘制装饰（比如滚动条）。值得多说一句的是，draw阶段的耗时大头往往不是onDraw本身，而是View的“脏区域”计算和图层分层。
这三步都在UI线程执行。也就是说，你代码里任何一步的耗时，都会直接占用“生产帧”的时间预算。Android一帧的预算一般是16.6ms（60Hz刷新率下），超了就得等下一个Vsync，表现在视觉上就是掉帧。
2.2 DisplayList与RenderThread：UI线程只“下令”，不“干活”
Android 5.0之后，绘制模型有了一个关键变化：View的draw不再直接发OpenGL命令，而是把绘制操作记录成DisplayList。这就像老板（UI线程）只负责在工单上写“这里砌墙、那里刷漆”，然后交给施工队（RenderThread）去执行。
RenderThread拿到DisplayList后，通过Skia或OpenGL（现在也支持Vulkan）把指令翻译成GPU能执行的渲染命令。这一步更靠近系统底层，如果项目中用了硬件加速（默认开启），大部分“画”的活其实在RenderThread和GPU上完成。
这个机制带来的好处很明显：UI线程的onDraw只是记录指令，而不是真的执行渲染，所以即使页面很复杂，UI线程也能快速结束；DisplayList还可以跨帧缓存，View内容没变时根本不需要重新生成指令。
但注意，这套机制有个经典坑：如果你在onDraw里创建了大量对象，或者调用了本来不需要的invalidate()，会让DisplayList频繁重建，等于让UI线程白白重复记录指令，性能照样崩。
2.3 生产端的掉帧现场：主线程耗时如何影响整条链路
在生产端出问题的情况我见过几类：
- 布局层级过深，measure递归耗时爆炸，尤其LinearLayout嵌套导致多次measure（weight权重尤其致命）。
- onDraw里做了重活，比如直接绘制大量Bitmap、频繁创建Paint对象、或者做了图片缩放。
- 主线程被别的任务抢占，比如SharedPreferences的同步提交、主线程网络请求、或者一个很野的第三方SDK在埋点里做同步磁盘IO。
这些都是老生常谈，但我要说一个容易忽略的点：主线程耗时对掉帧的“加成”不是线性的。因为UI线程产出的DisplayList只是“命令”，真正执行是在RenderThread。如果UI线程超过16.6ms，但RenderThread很快，画面可能只是轻微延迟；如果UI线程刚好在临界点，而RenderThread又慢了，那就会叠加出灾难性的掉帧。排查时一定要看两个线程的时间线，别只盯着主线程。
3. 中间枢纽：Surface和BufferQueue怎样交接画面
APP侧完成“生产”，紧跟着就要把画面交出去。这里的关键角色是Surface和BufferQueue，它们决定了生产端和消费端之间怎么协作，才不会互相牵制。
3.1 Surface：APP和合成器之间的“画板”
说到Surface，最容易联想到的是SurfaceView。实际上每个Window都对应一个Surface，它是APP绘制内容的载体——你画到Surface上的内容，最终会被合成器读取。
可以这样理解：Surface是一块“画板”的正面，APP拿着笔画画；画板的背面，SurfaceFlinger在等着拿“画好的画”。APP侧通过Surface.lockCanvas()拿到底层缓冲区（Buffer），画完后unlockCanvasAndPost()提交。两步之间夹着的就是一块块Buffer。
这里有个实际开发常用的点：为什么SurfaceView适合播放视频？因为它有独立的Surface，可以走后端合成的专用通道，不占主界面的图层合成份额，效率和灵活性都更高。理解了Surface的角色，这类API设计的意图就很明显了。
3.2 BufferQueue：三个缓冲区轮流上岗，避免生产消费互相等待
BufferQueue是整条链路交接段的“调度中心”，核心是一个生产者-消费者模型。APP是生产者，SurfaceFlinger是消费者。队列里一般维持三个缓冲区：一个正在被APP写入，一个正在被SurfaceFlinger合成，还有一个闲置待命。
这就是经典的**三缓冲（Triple Buffering）**机制。为什么要三缓冲？因为双缓冲下，如果生产者和消费者节奏稍微错位，APP很可能要等合成器释放缓冲区，一等待就掉帧。三缓冲给生产端多留了一块“周转空间”，即便某一帧节奏乱了，APP也能立刻拿到一块空闲缓冲区继续画。
第一代手机上的“掉帧感”很大程度上就是缓冲区不够引发的连锁反应。引入三缓冲后，同等条件下掉帧概率明显降低。我自己的实测经验是：三缓冲对低帧率场景（比如30帧视频）的流畅度提升尤其明显。
3.3 Vsync：整条链路的“节拍器”
缓冲区转起来了，还得有节奏。这个节奏由**Vsync（垂直同步信号）**来控制。屏幕每刷新一次，硬件就产生一个Vsync信号，它像一个节拍器，提醒“该生产下一帧了”“该合成下一帧了”。
APP侧收到Vsync后，UI线程才开始执行measure/layout/draw并生成DisplayList；SurfaceFlinger收到Vsync后，才把各APP的缓冲区拿过来合成。整个链条都踩着同一个节拍走，避免生产端和消费端各干各的导致撕裂（画面上下半部分来自不同帧）。
这也解释了一个常见问题：为什么游戏里帧率会被锁在屏幕刷新率的整数倍？因为Vsync的节拍就在那里，你就算生产得再快，也得等节拍器“哔”一声才能上场。
4. 消费中枢：SurfaceFlinger和HWC怎么拼出最终画面
APP把帧交出去了，接下来是系统层面的“合成”阶段。SurfaceFlinger这个名字，字面意思就是“图层合成器”。
4.1 SurfaceFlinger：把所有APP的图层“拼”成一张画面
现在的手机屏幕上同时显示的东西可不止一个APP。状态栏、导航栏、桌面、某个应用的前台界面，甚至还有壁纸层，它们各自都有独立的Surface。SurfaceFlinger的工作就是把这些图层按顺序叠起来，决定谁在上面谁在下面，然后把结果输出给屏幕。
比如你的屏幕上显示微信聊天界面，叠加的状态栏是从系统拿的，微信的界面是从微信进程通过Binder传过来的Surface缓冲区。SurfaceFlinger计算所有图层的Z轴顺序，处理透明度和裁剪关系，用OpenGL（或者Vulkan）执行一次合批，合成出一帧最终的画面。
这里最关键的流程是：
- SurfaceFlinger通过BufferQueue拿到各APP最新提交的缓冲区。
- 遍历所有图层，根据Z序计算最终的合成区域。
- 将合成结果提交给HWC或走GPU合成。
- 最终送显。
4.2 HWC硬件合成器：不是所有图层都非得GPU合一遍
如果所有合成都在GPU里做，耗电和发热肯定吃不消。于是HWC（Hardware Composer）出现了。它是显示硬件（Display Controller）的抽象层，专门处理“哪些图层可以交给硬件直接叠加，哪些必须GPU先合成”。
简单说：
- 如果一个图层没太多特效（不需要圆角、模糊、旋转），HWC可以直接告诉显示控制器：“这一层显示在屏幕左上角那一块”，硬件自己就搞定了，GPU不用参与。
- 如果有复杂效果（比如弹窗阴影、动画中的缩放），SurfaceFlinger会先在GPU里合成一次，再把合成结果交给HWC。
判断哪条路更优，是SurfaceFlinger每帧都要做的“合成策略决策”。这台决策机直接影响功耗和帧率表现。假如图层数太多、或者每个图层都在变化，GPU参与合成的比例会明显上升，功耗和发热也随之走高。
这也是为什么我平时写布局时会刻意减少“独立图层”的个数。每多一个图层（比如用elevation阴影、半透明窗口、动态模糊），SurfaceFlinger的合成负担就重一分。
4.3 DISPLAY与屏幕刷新：最后一步的“像素搬运工”
合成完的帧最终要显示到屏幕。这里涉及两个概念：Display和屏幕刷新率。
显示控制器从SurfaceFlinger手里拿到合成结果后，按照屏幕的分辨率和刷新率，把画面一行一行地扫描到物理屏幕上。LCD靠背光透过液晶分子成像，OLED靠每个像素自发光的明暗变化成像。无论哪种，最终一个共同点是：屏幕刷新是周期性的，以固定的频率从顶部到底部逐行更新。
链路走到这里，“一张图看懂”就该画上句号了：APP生产出帧，缓冲区交接给合成器，合成器拼好图，显示控制器把图刷到屏幕上。缺了任何一环，你看到的画面就可能是黑屏、撕裂、或者一顿一顿的“卡”。
5. 从链路图到实战：经典问题如何按图索骥
知道链路长什么样，下一步是拿它去对付实际问题。我梳理了几个最常见的显示问题，按照链路分段来定位，效率会高很多。
5.1 掉帧（Jank）怎么查：先判断掉在哪一段
掉帧是显示优化里最头疼的问题。按链路分段，排查思路就很清晰了。
- 生产端问题：主线程耗时长、RenderThread耗时长。常见症状是CPU跑满、方法耗时明显。优先抓主线程和RenderThread的耗时，用Systrace/Traceview看哪个阶段超预算。
- 交接端问题：缓冲区申请等待、BufferQueue里的buffer不够用。典型症状是
Choreographer的doFrame被延迟。可以抓SurfaceFlinger的日志，看是不是有“waiting for buffer”的等待。 - 消费端问题：SurfaceFlinger合成太慢，或者HWC僵住了。常见症状是帧率正常但屏幕显示异常，抓取SurfaceFlinger的时间线能发现合成耗时的异常波动。
这里有个实操经验：抓Systrace时不要只抓APP进程，要把surfaceflinger进程也一起抓上。很多掉帧问题的根因不在APP，而在合成端。只看APP侧trace会得出完全错误的结论。
5.2 刷新率、帧率、触控采样率：别再把三个数混为一谈
- 刷新率是屏幕硬件每秒刷新的次数，常见60Hz、90Hz、120Hz，决定“屏幕最多能给你看多少帧不同画面”。
- 帧率是APP实际每秒生产多少帧，受性能瓶颈限制。
- 触控采样率是触摸屏每秒采集触摸信号的频率，影响滑动跟手度的感知。
手机标称“120Hz”不代表APP就能跑到120帧。帧率=刷新率是理想情况，实际如果某帧掉到60帧，你会明显觉得“这手机没发挥120Hz的优势”。排查跟手度问题时，先确认刷新率设置，再追帧率，最后看触控采样率，别先用玄学归因。
触控采样率低会带来一个经典现象：屏幕是120Hz，但手指滑动的轨迹“跟不上手”，看着像帧率不够。这时候查APP帧率其实是满的，问题在输入采样阶段。
5.3 图层数量和透明区域：日常开发就能控制的合成压力
做APP开发时，很多影响显示链路性能的因素其实在写布局时就能规避：
- 减少不必要的图层。每个有独立Surface的窗口/View都是合成负担。能用
merge合并布局就合并，能少用elevation就少用。 - 避免大面积的透明区域叠加。全屏透明的Dialog、动画中的半透明遮罩，都会逼着SurfaceFlinger做更多alpha混合，比不透明图层贵很多。
- 谨慎使用
SurfaceView之外的“浮层”方案。比如用WindowManager.addView做悬浮窗，本质上是新增了一个独立的合成图层，频繁更新内容对链路压力很大。
这几点做下来，有时候掉帧问题不需要深入系统就能优化百分之六七十。我一直觉得，上层开发者最好的性能优化，是让系统底层的合成压力从一开始就变小。
5.4 功耗视角：显示链路里的每一帧都要花电
最后聊一个容易被忽略的点：显示链路决定功耗的一部分。GPU合成、SurfaceFlinger合成、屏幕硬件刷新，每一步都耗电。高刷新率之所以被很多人关掉，不止因为感知不强，更重要的是耗电明显。
功耗优化的基本思路跟性能优化高度重合：减少无谓的合成、降低无效帧率、避免亮屏时做无意义的全屏刷新。比如有些APP在页面静止时依然持续提交新帧（录屏轮询、动画循环没停），SurfaceFlinger就得持续合成。这类问题用adb shell dumpsys SurfaceFlinger看一眼提交帧率就能发现。
6. 我记这张图时踩过的坑和沉淀下来的心得
写到这儿，链路讲完了。最后分享几个我在实际工程里反复验证过的心得，不算教程，就是干活的经验，供各位参考。
心得一：用“链路思维”替代“单点思维”排查问题。以前遇到显示问题我第一反应是“是不是我代码写错了”，现在会先确认问题发生在哪一段。比如黑屏问题，可能不是APP没有绘制，而是SurfaceBuffer一直没有被提交，或者SurfaceFlinger合成异常。链路思维能帮你不被表面现象牵着走。
心得二：务必学会看Systrace的全链路时间线。我见过太多人只会看主线程的耗时，忽略了RenderThread和SurfaceFlinger。学会同时拉取APP进程和surfaceflinger进程的时间线，对齐Vsync，分辨掉帧到底发生在生产的哪一步、交接是否顺畅、合成有没有瓶颈，这比任何调试技巧都重要。
心得三：三缓冲不是万能的，不要迷信它。三缓冲提升了交接端的容错，但生产端慢仍是硬伤。很多设备上三缓冲反而会稍微增加延迟（因为缓冲区多了，帧在队列里排队的时间变长了）。对于指哪打哪的游戏场景，二缓冲+严格Vsync反而可能更跟手。工程上没有银弹，全链路分析才是最能打的方案。
最后再补一个快速上手工具：adb shell dumpsys gfxinfo <包名>能看到APP侧的帧耗时直方图；adb shell dumpsys SurfaceFlinger --latency能看到合成和提交的时间戳。这两个命令搭配着看，五分钟内就能判断问题大体出在生产端还是消费端。把链路图和这两个命令记在脑子里，显示问题基本都能快速剖开看个底朝天。
