企业官网建设流程全解析

看到"Android显示完整链路"这个标题，可能有的朋友第一反应是：这玩意儿太底层了，跟我平时写页面有什么关系？我过去也这么想，直到连续处理过几个诡异问题——列表滑动偶尔卡一下、启动时黑屏时间忽长忽短、明明主线程很闲但画面就是不跟手——最后排查到底，全部都要回到这条链路上找答案。Android显示完整链路不是一个"了解即可"的知识点，它是所有性能问题的最终归属地。

这篇作为系列的第一篇，我不打算上来就贴一堆源码，而是先给一张能装进脑子里的完整的图。这张图由三段组成：App侧怎么把UI变成像素、系统侧怎么把所有像素拼成一帧画面、硬件侧怎么把画面按节奏刷到屏幕上。把这三段和他们之间的交接方式搞清楚，以后无论做应用优化还是读framework代码，你都会比大多数人看得更远。

1. 先建立全局地图：从setText到屏幕像素点亮，中间隔了几道工序

我先说结论：完整链路不是一条直线，而是"App生产像素"、"系统合成像素"、"硬件显示像素"三个接力区，中间靠共享内存和垂直同步信号来完成交接。每一段都有自己的主人：App进程管不了系统怎么合成，SurfaceFlinger也管不了屏幕什么时候刷新。很多优化之所以做不透，就是因为只在自己的地界里使劲，不知道上家和下家怎么想。

1.1 三句话概括整条Android显示完整链路

用最朴素的话讲一遍，你以后跟人解释这条链路时可以直接用这套话术：

• App把UI变成像素请求。你在XML里写的布局、代码里调的setText、动画里改的属性，最终都会通过Measure、Layout、Draw这三步，变成一批绘制指令，画到一块叫Surface的画布上。
• 系统把各App的像素拼成屏幕画面。所有App的Surface都提交到一个叫SurfaceFlinger的系统服务里，它把所有图层按层级、透明度、位置关系合成起来，生成一帧完整的屏幕画面。
• 硬件把画面按节奏刷新到显示器。合成好的帧数据交给硬件合成器HWC和显示控制器，由它们在固定的刷新周期内把像素真正点亮到屏幕上。

这三句话合在一起，就是"一条Pixel的旅程"。你可以把整个过程想象成快递发货：商家（App）打包好包裹，放到快递驿站（Surface），驿站把不同商家的货按片区合并装车（SurfaceFlinger合成），最后由配送员（HWC/Display）按固定班次（Vsync）送到买家手里。任何一个环节堵车，用户感受到的都是同一个词——卡。

1.2 各段链路的"老板"和交接物

我建议把这条链路记成一张表，排查问题的时候先问一句"这段归谁管"：

这里最关键的认知是：帧数据的移交靠的是共享内存，而不是跨进程拷贝。App写好的像素放在一块共享内存里，SurfaceFlinger直接去读，省掉了复制开销。这套机制在后面的BufferQueue部分还会展开，现在先记住"不拷贝"这个特性就够用了。

2. App侧三件套：Measure、Layout、Draw到底把活干到哪一步

现在把镜头推到App进程内部，看第一段。很多人写过自定义View，知道有onMeasure、onLayout、onDraw这三个回调，但不清楚它们是在什么上下文里被调起的。我简单梳理一下这部分的完整脉络。

2.1 ViewRootImpl：所有UI操作的入口

每次你setText()导致界面变化，系统最终会通过ViewRootImpl来组织一次完整的绘制流程。ViewRootImpl是View和WindowManager之间的桥梁，它以DecorView为根节点，自顶向下调度整棵View树的三个过程：

• Measure（测量）：父View根据父容器给的MeasureSpec和自己想要的尺寸，确定每个子View宽高。这个过程可能递归多次，所以复杂布局的measure开销不容小觑。
• Layout（布局）：确定每个View在屏幕上的坐标位置。到这里，每个View的"框"已经定好了，但还没有内容。
• Draw（绘制）：真正把背景、文本、图形等画出来。开启硬件加速后，这里的"画"并不是直接把像素写到Surface，而是生成一系列绘制命令。

值得注意的是，这三个阶段不是由开发者主动调用的，而是由Choreographer在垂直同步信号到达时触发。也就是说，App侧绘制的启动节拍，本质上是跟着屏幕刷新走的。关于这个节拍器，后面单独讲。

2.2 硬件加速之后，Draw去了哪儿

这是很多人误解最深的一处。Android从5.0开始默认开启硬件加速，我遇到不少同学还在用软件渲染时代的思维理解draw，以为onDraw里用Canvas画的每一笔都直接写进了像素。实际上，在硬件加速条件下，Canvas.drawXxx()方法做的是把绘制操作封装成DisplayList指令，然后交给一个叫RenderThread的独立渲染线程。

RenderThread拿到这批DisplayList后，会通过Skia或OpenGL/Vulkan后端把它们翻译成GPU能执行的渲染命令，最终由GPU完成真正的像素填充。这个过程是异步的，主线程不需要干等GPU执行完。为什么这很重要？因为这意味着：

提示：出现"主线程不卡但画面掉帧"的情况，问题可能出在RenderThread或GPU侧，而不是主线程。不要只盯着主线程的耗时看。

2.3 一个常被忽略的交接点：DisplayList的更新开销

既然draw阶段生成的是DisplayList，那么"View重绘"的开销就不能简单理解成"重新执行onDraw里那几行代码"。每次调用invalidate()，系统会把该View对应的RenderNode标记为脏，然后重新执行它的draw来更新DisplayList。如果View的draw实现很重——比如在onDraw里频繁分配对象、做复杂Path测量——RenderThread和GPU侧的负担就会变大。

我举个例子：曾经优化过一个折线图控件，原实现每帧在onDraw里new一个Paint、创建一个Path，还做了一次字符串格式化画坐标轴。看起来主线程耗时只有2~3ms，但把Perfetto拉出来看，RenderThread每帧都在重新生成DisplayList，GPU片元着色器负载很高。改成只在数据变化时更新数据Path、把静态坐标轴做成独立View后，帧时间直接从22ms降到10ms。所以记住：onDraw里的每一行代码，最终都会变成GPU命令，写的时候要想清楚它是不是真的每帧都需要。

3. Surface与BufferQueue：App和系统之间的像素交接暗号

App画好一帧内容之后，要交给SurfaceFlinger去合成，这一步交接靠的是BufferQueue。它是整条Android显示完整链路里最容易理解也最容易被忽视的一环，很多掉帧问题其实就发生在"App画完了但交不出去"的瞬间。

3.1 生产者和消费者的共享内存模型

BufferQueue本质是一个生产者/消费者队列，App侧的生产者是Surface，消费者是SurfaceFlinger，缓冲区里放的都是GraphicBuffer——一块可以供CPU/GPU同时访问的共享内存。

正常情况下，一帧的流转是这样的：

1. App需要画新帧时，调用dequeueBuffer()从队列里取一块空闲buffer。
2. App在buffer上完成绘制，调用queueBuffer()把buffer放进队列。
3. SurfaceFlinger从队列里取走这块buffer，读取里面的像素内容进行合成。
4. 合成完成后，buffer被释放回队列，等待下一轮使用。

这里有个细节值得注意：BufferQueue通常不止一块buffer，常见的是三缓冲。为什么需要三块？因为如果只有一块，App画的时候SurfaceFlinger没法同时读，二者只能互相等，性能会非常差。三缓冲让App、GPU、SurfaceFlinger三方都能有一个buffer在手，谁都不用干等别人。代价是输入到显示的延迟会略增，但对现代设备来说，流畅度优先是更合理的取舍。

3.2 队列满的时候会发生什么：背压与掉帧

如果App生产帧的速度持续大于SurfaceFlinger消费的速度，队列里的buffer就会全部处于占用状态。此时App再去dequeueBuffer()，就会被阻塞住，也就是我们常说的背压。一旦阻塞发生，App的绘制节奏被打断，表现为掉帧。

理解这一点对排查问题很有帮助：有时候你在trace里看到App侧dequeueBuffer耗时几百毫秒，不要只当App的问题看，要往下追——SurfaceFlinger是否消费不过来？GPU是否超负荷？屏幕刷新率是否过高导致单帧预算太短？我在一台高分辨率高刷设备上遇到过类似现象，App每帧draw只有5ms，但dequeueBuffer经常卡100ms以上，最后定位到是GPU合成负载过高，SurfaceFlinger排队，把App的生产节奏也拖垮了。这就是背压传导。

3.3 Surface只是"一块画布"吗

在framework语境里，Surface经常被人当成"画布"，这种说法对，但不够准确。更准确地说，Surface是BufferQueue生产端的门面。每个Window都对应一个Surface，每个Surface背后都挂着一个BufferQueue。你用Surface.lockCanvas()或者RenderThread来绘制，本质都是从这个队列里拿buffer、往里写内容、再放回去。

我在实际开发里发现，很多人把Surface理解成"View的成员"，这是方向性错误。Surface是App进程和系统进程共享的接口，View绘制的终点是它，SurfaceFlinger合成的起点也是它。搞清楚这一点以后，再看SurfaceView、TextureView这些特殊View，会容易很多——它们无非是在"把内容送进Surface"这件事上选择了不同的路径和时间点而已。

4. Vsync与Choreographer：这套链路的节拍器藏在哪

Android的显示是"节拍驱动"的，不是"谁想画就画"。驱动整个Android显示完整链路的节拍，就是Vsync（垂直同步信号）。屏幕以固定频率刷新，每刷新一次就发出一个脉冲，各模块都要跟上这个脉冲的节奏。谁跟不上，谁就会掉拍。

4.1 Vsync从哪里来

屏幕硬件会持续产生Vsync信号，比如60Hz屏幕每16.6ms一次，90Hz每11.1ms一次，120Hz每8.3ms一次。Android系统把这个硬件信号通过SurfaceFlinger加工成两种软件Vsync：App Vsync（用于驱动App侧绘制）和SF Vsync（用于驱动SurfaceFlinger合成）。

这里有个有意思的编排：系统在时间上做了偏移，先给App留出绘制时间，再给SurfaceFlinger留出合成时间，避免二者同时挤在一帧里抢资源。对开发者来说，不需要手动管理这些偏移，但理解它有助于看懂Perfetto里Vsync相关的区间在干什么。

4.2 Choreographer：App侧的节拍器

App侧每一帧的启动，不是应用自己定的，而是Choreographer收到App Vsync后发出的。它会回调doFrame()，并在这次回调里依次处理三件事：

• 输入事件：处理触摸、按键等Input事件，因为输入会改变UI状态。
• 动画：推进Choreographer驱动的动画（如属性动画）。
• 视图遍历：也就是我们前面说的measure、layout、draw。

这三件事都做完之后，一帧内容才算提交到Surface。所以你看，主线程的耗时、遍历深度、绘制量，都会直接影响一帧能否在下一个Vsync到来前完成。

4.3 错过节拍：早到和晚到的连锁反应

如果App侧在一个Vsync周期内没画完，就会错过当前帧，画面沿用上一帧，下一帧顺延到下一个周期。这就是"掉帧"的直观含义。此时用户看到的是卡顿，开发者工具里看到的是"跳帧数"增加。

值得强调的是，掉帧的锅不一定在App主线程。我总结过三种常见局面：

判断方法很简单：拉一段trace，看那一帧的耗时柱状图到底在哪一段变长了，而不是猜。很多时候我只需要看一眼"UI Thread、RenderThread、GPU、SF"这几个区间的分布，就能确定接下来该优化谁。

5. SurfaceFlinger：把所有窗口拼成一张屏的中央厨房

当所有App都往自己的Surface里画好内容后，屏幕上并不是直接显示这些Surface，而是由SurfaceFlinger统一"做菜"：它拿到所有窗口对应的Layer（图层），按照Z序、透明度、裁剪区域和变换关系，把它们合成成一张完整的屏幕画面，最后交给显示硬件。这里藏着另一大堆性能问题的根源。

5.1 SurfaceFlinger到底在合成什么

每块Surface在SurfaceFlinger里都对应一个Layer，Layer上还带着各种属性——位置、缩放、旋转、透明度、圆角裁剪等。正常情况下，你在桌面上看到的所有东西，包括状态栏、导航栏、各个App窗口、壁纸，都是Layer。SurfaceFlinger的职责就是决定哪个Layer在上、哪个在下、哪些可见、哪些被遮挡，然后生成最终帧。

一个常见误区：以为SurfaceFlinger只按像素叠图。实际上它要做更多的可见性判断。比如一个Layer完全被上面的不透明Layer盖住，它会被裁剪为不可见，直接跳过合成，省掉大量开销。这也是为什么App在设计窗口时，如果能保证顶层是不透明背景，就能减少一些合成压力。

5.2 合成方式：GPU合成与HWC合成之分

SurfaceFlinger合成一帧，通常有两种路径：

• GPU合成（Client合成）：SurfaceFlinger把各Layer作为纹理传给GPU，通过OpenGL/Vulkan命令把它们渲染到一块目标buffer里。这种方式灵活，能处理任意变换、透明度、圆角，但GPU开销大。
• 硬件合成（HWC合成）：SurfaceFlinger把Layer列表和合成指令交给HWC硬件，由显示控制器直接完成图层叠加。这种方式效率极高，很多场景下几乎不耗GPU。

实际工作中，这两种方式是动态切换的。系统根据Layer的复杂度、是否支持硬件叠加来决定走哪条路。如果你在trace里看到某一帧的"GPU合成"区间特别长，通常说明Layer列表里有什么东西破坏了硬件叠加的条件——比如某个全屏窗口开了模糊、或者Layer数量超过了硬件叠加层上限。

5.3 从优化角度看SurfaceFlinger：少给它添堵

应用开发平时接触不到SurfaceFlinger，但你的行为会直接影响它的工作量。我举三个真实场景：

• 透明状态栏/导航栏：如果你的Window背景是半透明的，系统在合成时就需要把下层Layer和你的Layer做二次混合，GPU压力增大。很多应用在不需要时保留了透明主题，这是我很常见的一个优化盲区。
• 多窗口分屏：分屏后每个App都有自己的Surface，窗口间还有分割线等额外Layer，SF要合成的Layer数变多，如果两个App都很活跃，掉帧概率会上升。
• 动画期间大量Layer：比如开屏广告弹窗、底部菜单展开，如果同时出现多个带阴影或模糊的View，Layer数量激增，SF的合成负载会明显上涨。

从这个角度说，应用侧的"过度绘制"不仅浪费GPU，还会把压力传导到合成端。优化完过度绘制，经常会发现整体帧时间也比之前平滑，就是这个原因。

6. HWC与Display：最后一公里由硬件说了算

App画了，SF也合成好了，但屏幕上的像素并不是马上出现的。最后一公里掌握在硬件手里：HWC（Hardware Composer）和DisplayController共同决定，这一帧什么时候、以什么方式显示到屏幕上。

6.1 HWC究竟做了什么

HWC通过HAL接口与内核显示驱动交互。它的核心能力是硬件图层叠加。相比于GPU合成，HWC可以借用显示控制器的硬件叠加器，把多个Layer在扫描输出的过程中直接融合，而不用把每个Layer先渲染成一张纹理再画一次。

这就带来一种常见的效果：当你的界面足够简单、Layer数量又少时，SurfaceFlinger可以把大部分合成工作完全丢给HWC，GPU几乎不参与。这也解释了为什么有的系统界面在弱GPU设备上依然很流畅——它压根没让GPU干重活。反过来，一旦某个界面图层复杂到硬件叠加器处理不了，合成压力就会回落到GPU上，帧率随之下降。

6.2 DisplayController与刷新节拍

显示控制器负责把内存里的帧数据，按像素时钟逐行扫描输出到屏幕面板。这个过程会严格跟随屏幕刷新率。比如60Hz屏，每16.6ms就要输出一整帧，中间不能中断。如果帧数据没有及时准备好，显示控制器可能会重复上一帧，或者出现撕裂现象。为了防止撕裂，系统会在Vsync机制里做"帧同步"，确保刷新过程只显示完整帧。

对一个做应用开发的人来说，这一段的可操作性不强，但你至少要有一个意识：高刷新率给硬件带来的负担不是App独有的。120Hz下，GPU、SF、带宽的负载都会增加，单帧预算从16.6ms缩到8.3ms，这意味着以前能扛住的低效绘制，现在会直接掉帧。

6.3 从帧生命周期理解整条链路的延迟

如果从"一帧的出生到显示"来看，整条链路的延迟包括：App绘制耗时、buffer排队耗时、SF合成耗时、显示扫描输出耗时。用户感知的触控到显示延迟，是所有这些加起来的结果。

我常跟团队里的人说，调优要分清楚是"哪一段延迟"。比如触控响应慢，可能卡在Input处理；点击后画面长时间无反馈，可能卡在绘制首帧；滚动时掉帧，则要看每帧的绘制和合成是否超过预算。维度不同，对策完全不同。不能手里有把锤子，看什么都是钉子。

7. 完整链路视角下的卡顿定位，我这套思路一直这么用

前面六节把这幅地图的每一段都铺开了。最后聊点实战——有了完整链路视角之后，遇到卡顿我究竟怎么一步步定位。这节讲的不是高深原理，而是可复现的排查套路。

7.1 第一步永远是"分边"

拿到任何一个"卡"的问题，我先不急着看代码，而是先判断它属于哪一边：

• 如果只在特定App内卡，切到桌面/系统界面就流畅，优先怀疑App侧。
• 如果系统界面也卡，大概率是系统服务或硬件负载问题。
• 如果在特定动画/转场时卡，要看SF和GPU合成路径。
• 如果低概率偶发卡，重点抓堆栈和trace，看是哪一线程在忙。

这个分流动作能帮你砍掉一半无用猜测，直接决定接下来用什么工具。不要一上来就优化代码，先知道敌人在哪个阵地。

7.2 常用工具串一条线

我常用的组合是这四个，按顺序来：

1. dumpsys gfxinfo：看App侧的帧耗时和掉帧分布，快速判断是不是App绘制问题。
2. dumpsys SurfaceFlinger：看Layer数量、合成方式、是否走了GPU合成，判断SF侧压力。
3. Perfetto/Systrace：拉整机trace，同时看到App线程、RenderThread、GPU、SF、Vsync频率，这是定位跨模块问题的最关键手段。
4. GPU监控（如GPU Profiler或厂商工具）：确认GPU是否过载，判断是否要降低绘制复杂度或减少特效。

这四个工具的定位逻辑很朴素：从最粗的粒度逐步收敛，最后在trace上定格到某一帧的某一段区间。

7.3 两个我踩过的真实坑

最后分享两个印象深刻的排查经历，都是完整链路视角带来的收获。

第一个坑是"主线程守卫"陷阱。有个页面滚动卡顿，gfxinfo显示主线程每帧耗时稳定在2ms，但掉帧依然严重。后来抓trace才发现，RenderThread每帧要等GPU完成一个巨大的模糊效果，而GPU繁忙期经常超过12ms。问题不在主线程，在绘制指令太重。按老思路去优化Adapter，根本不会见效。

第二个坑是"误伤SurfaceFlinger"。另一个问题里，SF的合成耗时居高不下，我一开始以为系统服务出了毛病，后来把所有Layer的边界画出来才发现，某个自绘弹窗View把阴影区域画得极大，导致一个超大透明Layer长期存在，合成器无法走硬件叠加路径，只能走GPU合成。把阴影范围收敛之后，SF耗时立刻恢复正常。

这两个案例共同说明一点：安卓的显示是一个接力流程，瓶颈常常不在你最初怀疑的那个环节。有了整条链路的完整视图，你才知道该往哪个方向追。

从第一张地图到最后的实战套路，这就是我看待Android显示完整链路的方式。它不是一张需要背诵的架构图，而是一把定位问题的尺子。下一次再遇到卡顿，先别急着改代码，拿这把尺子量一量——卡在哪一段，再动手也不迟。