Android图形系统这条路我写到了第三篇。前两篇我们聊了Window、Activity和View那一层的东西今天把视角拉到系统级专门聊渲染和合成的底层链路。这个系列里这篇是我觉得最值得反复读的因为网上讲Activity生命周期、讲View绘制的文章很多但能把“App画完一帧之后发生了什么”这件事讲透的确实不多。简单说这篇解决三个问题一帧画面从App进程到屏幕上经过哪些进程、哪几道工序为什么有时候明明布局不复杂却掉帧以及遇到渲染性能问题时怎么从原理反推出排查方向。适合已经写过自定义View、看得懂onDraw但对“屏幕为什么卡一下”“SurfaceView为什么快”这类问题还想再往深挖一层的同学。1. 整体设计与核心思路为什么要把渲染和合成拆成两件事1.1 这是一条跨进程的生产线Android的图形链路本质上是一条跨进程的生产线。你可以把它想象成一家餐厅的后厨和传菜口应用进程是厨师负责把食材UI状态加工成菜品一帧画面SystemServer里有一个叫SurfaceFlinger的进程是传菜员负责把所有厨师做好的菜各App的画面按顺序摆到一个盘子里最后端到餐桌上屏幕。为什么必须拆成两个阶段因为屏幕只有一个但同时在“做菜”的App有好几个。状态栏、导航栏、桌面、你正在聊天的窗口每一层都是独立App或独立线程画的。如果每个App直接去写屏幕显存那画面一定乱套——你盖住了我我刷掉了你。所以Android把“画画”和“上桌”分开App只负责往自己的缓冲区块Buffer里画画完交给SurfaceFlinger统一决策谁在上面、谁在下面、谁需要被合成、谁直接透传然后输出到显示器。这背后是一套典型的生产者-消费者模型用类比的思路梳理一下就清楚了。角色对应组件职责生产者App进程内的View系统 HWUI渲染引擎把界面绘制成像素/指令写入BufferQueue的空闲Buffer缓冲队列BufferQueue管理Buffer的生产与消费解决生产和消费速度不一致的问题消费者SurfaceFlinger进程从BufferQueue取走已填好的Buffer合成后送显屏幕Display / Composer最终把像素亮出来1.2 渲染和合成是两套完全不同的“计时器”很多性能问题分析不准就是因为没搞懂渲染和合成各走各的时钟。渲染阶段的节拍器叫Vsync应用信号Choreographer合成阶段的节拍器叫Vsync合成信号SurfaceFlinger的调度器。虽然都源自同一个硬件VBlank屏幕扫描完一帧后返回起点发出的脉冲但中间经过了不同的分发路径所以App画一帧和系统合一层并不是严格的“你画完我马上合”。这也解释了为什么有时候你的App明明在60fps稳定输出但用户感知还是“有点不跟手”——因为合成阶段如果某一帧耗时太长SurfaceFlinger来不及在下一轮Vsync之前完成合成就会跳过一帧。所以做性能优化不能只盯着App侧的渲染时间合成侧的耗时同样是变量。1.3 先把原理补齐再谈调优我见过不少同学一上来就开“开发者选项-显示Surface更新”“调试GPU过度绘制”一顿操作猛如虎最后也没定位到根因。原因很简单工具只能告诉你“这里有掉帧”“这里过度绘制了”但不会告诉你“为什么”。要回答为什么必须知道这条链路上每一站的工作方式。这篇博文就是想把这条链路从源头捋到尾把每站的关键机制和对应工具串成一个整体后面你无论是做应用层优化还是做系统层定制都有底子可以依靠。2. 应用侧渲染链路从setContentView到屏幕像素2.1 setContentView只是“布置场地”不是“画画”先纠正一个常见的误解很多人以为调用setContentView之后布局就开始绘制了其实不是。setContentView做的事本质上只是把XML布局解析成View树挂到Window上这时候屏幕上什么都没有。真正的第一次绘制要等到Vsync回调把消息发到主线程触发Choreographer的doFrame才会走“measure量尺寸) - layout摆位置 - draw画出来”这套流程。关于Choreographer你可以把它理解成一个“节拍器服务员”它跟硬件Vsync对齐然后一杯一杯地把咖啡回调端给主线程。主线程接到回调就开始干活。如果主线程忙着处理别的事物比如超长列表的item测量、一个巨大的Bitmap解码没能在下一杯咖啡送来之前干完那一帧就丢掉了——这就是掉帧的本质。我第一次做性能排查时总以为是draw方法里的path计算太慢后来在Perfetto里才看到真正吃掉时间的其实是上一帧遗留的measure/layout任务draw本身反而是轻活。这个认知直接影响了我后来的写法能不动的布局就不动能动局部就不invalidate整棵View树。2.2 CPU画指令GPU画像素DisplayList的由来从Android 5.0开始View的draw方法执行时CPU不再直接往Bitmap上画像素而是把绘制操作封装成一个指令列表这个列表叫DisplayList。说人话就是你把“画一个红色圆”“贴一张位图”“在这段文字上加粗”这些操作按顺序记录下来但并不立刻执行。这套设计的聪明之处在于缓存和复用。如果某一帧只是View的一个属性变化比如平移DisplayList本身没变那下一帧直接重放指令就行不需要重新measure、layout、遍历整棵View树。这也是属性动画比invalidate整View高效的原因之一。当然DisplayList也不是永远有效的一旦View调用了invalidate或者它的绘制状态被标记为dirty对应节点的DisplayList就得重建。2.3 RenderThread与GPU执行主线程不画像素的真正原因DisplayList准备好之后主线程的工作就基本结束了。接下来一个叫RenderThread的渲染线程会接管DisplayList把它转成OpenGL ES现在也有Vulkan路径的绘制命令提交给GPU执行。这就是“硬件加速渲染”的默认模型CPU负责“编剧本”生成DisplayListGPU负责“拍电影”渲染像素。为什么Android要专门搞一个RenderThread因为如果所有绘制命令都由主线程提交给GPU那么当GPU繁忙时主线程就会卡在等待GPU返回结果这一步导致点击事件、输入事件全部没空处理用户感知就是“点不动”“卡死”。有了RenderThread之后主线程只管生成指令提交和等待GPU是后台线程的事两者可以流水线式并行。这在低端机上表现尤其明显你给主线程减负一点点用户能明显感觉到界面“活”了很多。关于渲染引擎这两年还有一个很值得关注的发展方向Flutter新默认引擎Impeller它把Skia的运行时shader编译很大一部分挪到了离线阶段目标是解决首帧白屏和shader编译卡顿问题。这个思路对Android原生也有借鉴意义——你的App如果大量使用自定义Shader编译阶段是绕不开的隐性成本可以像我后面讲的那样用预热方式规避。2.4 BufferQueue生产者和消费者之间的“物流中心”RenderThread渲染完成后GPU把像素写入一块Buffer然后通过BufferQueue把这块Buffer交出去。BufferQueue本质上是一个有状态的队列经典的三板斧操作是dequeueBuffer取一块空闲Buffer用于绘制、queueBuffer画完放回队列、acquireBuffer消费者取走处理。帧率能不能稳Buffer数量是关键。老Android版本只有双缓冲App在画帧A时屏幕正在显示帧B如果App画得太快想画帧C但手里没Buffer了只能干等屏幕把帧B扫完于是帧率被强制拉低。后来引入三缓冲相当于给生产者多一块后端Buffer缓冲让生产者在某些时刻可以提前画即使屏幕还没扫完也能继续干活。代价是额外的一层内存和显示延迟硬件条件允许时Android会自动在三缓冲和双缓冲之间切换不需要开发者手动干预。3. 合成阶段SurfaceFlinger是如何把画面拼出来的3.1 所有App的出口都汇聚到SurfaceFlinger一个入口应用侧画完之后所有窗口的Buffer都进了SurfaceFlinger。SurfaceFlinger是整个图形系统的“中央调度室”它维护了一张Layer列表每个Layer对应一个窗口更准确地说一个Surface。它要做的事是在每次Vsync合成信号到来时检查哪些Layer有新帧到来dirty状态然后根据每个Layer的显示参数位置、大小、透明度、裁剪区域、Z序决定如何把它们输出到屏幕这里的“Z序”就是窗口的盖压关系。状态栏在顶层、输入法在需要时浮起来、Dialog在最上面这些都是由WindowManager通过Transaction事务告知SurfaceFlinger的比如setLayer、setPosition、setAlpha。如果你看过相关代码会发现WindowManager几乎每帧都可能发起事务SurfaceFlinger要高效合并这些事务再应用也是不小的负载。3.2 GPU合成与硬件合成谁适合合成谁只做透传合成这一步得看抬谁来做。如果所有Layer都能交给硬件合成器那SurfaceFlinger就做个“甩手掌柜”直接把各Layer的Buffer地址、格式、裁剪信息打包发给显示控制器让硬件去完成叠加。这就是HWCHardware Composer模式省电且高效——注意这里“合成”其实是硬件在显示扫描过程中完成的不走GPU甚至不额外占内存带宽。但硬件合成器并非全能的。某些Layer如果是GPU绘制的结果需要做旋转/缩放/混合等复杂变换、需要特效处理HWC大概率不支持这时候SurfaceFlinger只能自己上通过OpenGL ES把所有Layer合到一块新Buffer里再把这块Buffer送去显示这就是GLES合成。还有一类更进阶的东西硬件2D合成器。有些SoC会提供独立的2D引擎来做图层叠加像T113这类方案里提到的G2D就属于此。这类引擎的核心价值在于用专门硬件处理2D合成比通用GPU更轻量、更省带宽特别适合做LVGL这类GUI的渲染加速。但要用好它得清晰区分哪些操作是“纯2D搬移/叠加”哪些操作必须走GPU这个边界不把握好反而可能比全走GPU还慢。3.3 两个被混淆的概念Layer与Surface很多人会把Layer和Surface当成同一个东西其实Surface是生产端的Buffer容器Layer是合成端的一个显示实体。一个Surface被queueBuffer之后SurfaceFlinger会为它建立/更新对应的Layer或者Layer更新Buffer内容。Layer还承担了Buffer的缓存管理如果SurfaceFlinger发现一个Layer的内容没有变化即没有新Buffer入队就可以在合成时直接复用上一次的Buffer不需要重新合成一遍。这也是为什么静态界面的省电效果远好于动画界面。在实际工作中统计Surface和Layer的数量是一项基本功。Layer太多意味着每一帧合成时要做更多决策、处理更多Buffer再强的合成器也会忙不过来。常见病根是多个浮窗、多个透明Activity、频繁创建的SurfaceView。能用单Surface承载的内容就尽量不要拆成多个窗口。3.4 为什么SurfaceView可以“局部更新”且开销更低讲到这里SurfaceView的优势就很好理解了。普通View的一切都要先经过ViewRootImpl走DisplayList渲染到App的Surface上再由SurfaceFlinger合成。SurfaceView则单独拥有一块独立的Surface独立的BufferQueue而且默认情况下它还有个重要特性它的Layer在Z序上位于宿主窗口的“挖洞”层之下也就是宿主窗口那块区域相当于被挖空了SurfaceView的内容直接从前台的独立Layer透传显示。这意味着两点第一SurfaceView的内容更新不需要经过App整体RenderThread重绘它能做到独立于View树的刷新第二因为它是独立Layer在合成时可以直接交给HWC透传不走GPU合成所以视频播放场景特别偏爱它。这也是为什么我经常建议如果你要高频刷新一块区域视频、相机预览、游戏画面优先考虑SurfaceView而不是在普通View里疯狂invalidate。4. 性能优化实战从原理反推排查方向4.1 掉帧了先分清是谁的锅经验丰富的性能优化工程师看到掉帧第一反应不是改代码而是先分类这帧是App侧渲染慢还是合成侧慢还是主线程调度慢三个方向对应不同的证据来源。用adb shell dumpsys gfxinfo可以看App的绘制统计数据比如Draw、Prepare、Process等各阶段耗时其中如果“Total GPU time”特别高说明GPU负担重如果想看合成侧的情况dumpsys SurfaceFlinger --latency可以输出各Layer的帧时间戳信息配合分析是否有掉帧或Buffer不及时。我自己的习惯是先开Perfetto或Systrace抓一段场景数据找到掉帧的那个时刻看主线程上是不是有一个很长的任务常见的是setContentView大布局、getView重复创建、SharedPreferences读取如果没有再去RenderThread上找GPU瓶颈去看SurfaceFlinger那一段的时间线。只要这条链路的分析顺序固定下来大多数性能问题都能定位到具体环节而不是靠猜。4.2 过度绘制与DisplayList缓存两个容易被忽视的重灾区过度绘制是GPU压力的主要来源。开发者选项里的“调试GPU过度绘制”用颜色区分绘制层级每多画一层就多一层颜色最严重时整个屏幕都是红色的。典型问题包括多层嵌套的背景叠底、带阴影的CardView大面积堆叠、DrawerLayout/Scrim在桌面层上又画了一层全屏遮罩。优化的本质是减少不必要的绘制指令能用一层背景解决的就不要叠三层能用clipRect裁剪掉不可见区域的就不让那部分像素白白参与渲染。另一个重灾区是DisplayList缓存失效。很多时候你只是改了一个View的属性但因为它处于一个复杂的ViewGroup中invalidate一触发整个父容器的DisplayList都得重建。这个问题在看列表RecyclerView时尤其明显如果你的item根布局写得极其复杂或者item复用机制没做好很容易一两帧就把GPU打满。我处理过一个实际案例明明GPU型号不差但列表滑动就是掉帧最后定位到的问题是item的阴影效果在每次滑动时都触发整棵子树DisplayList重建。把阴影改为预先画好的纯色阴影图后帧率立刻回归平稳。4.3 setLayerType与硬件层的取舍View.setLayerType是一个容易被人滥用、也容易被人忽视的API。LAYER_TYPE_HARDWARE表示这个View会离屏渲染到一个Texture上之后系统可以直接复用这块Texture而不用每次重新执行draw方法。它适合用在动画频繁的场景比如旋转、缩放一个复杂View但有两个坑一是离屏缓冲会额外占用GPU内存滥用的话内存吃紧反而触发更频繁的GC和掉帧二是如果View在动画过程中内容频繁变化比如每帧都在更新里面的文本或Bitmap那离屏缓冲还不如不建因为每次内容变化还是要重画整个Texture等于白绕一圈。所以我的经验是先用工具确认动画期间是不是真的Draw方法重绘开销很大确认了再用LayerType不要一上来就“优化”。另外如果你的App确实在动画期间遇到了Shader编译卡顿可以采用一种“预热”思路在启动阶段用一个小区域、低开销的方式提前触发目标Shader的一次编译把编译耗时的尖峰平移到用户还没明显感知的时刻。这个技巧在Impeller出现之前是很多引擎做首帧优化的妥协方案。4.4 开发者选项里的实用开关最后补充几个开发者模式里对图形调试极其实用的开关和它们的原理依据“显示Surface更新”让已提交的Surface在更新时闪烁能快速发现哪些Surface在刷帧、哪些在隐藏地偷跑资源。“显示布局边界”帮你看清楚每个控件的真实边界Locate布局问题很直观。“模拟辅助显示设备”如果你在做多屏异显或副屏适配用它模拟多个逻辑显示。“Force GPU渲染”让不支持硬件加速的绘制也强制走GPU路径可以用来定位某些Canvas操作在软件渲染下是否成为瓶颈。这些开关本身不复杂关键是结合前面讲的链路知道它们改的是哪一环才能用得有意义。5. 常见问题与排查技巧实录5.1 问题速查表下面是我在实际开发和调优中遇到的一些典型现象整理成一张速查表可以直接对照排查。现象可能原因排查手段解决方向打开页面黑屏一闪Activity主题是黑/白背景首帧未完成看看dumpsys gfxinfo首帧时间、Theme配置设置启动背景或减少首帧工作量列表滑动掉帧item布局复杂、DisplayList频繁重建Perfetto看RenderThread和主线程耗时简化布局、复用View、减少invalidate范围视频播放卡顿/黑块SurfaceView独立时序与窗口切换冲突看SurfaceFlinger的Layer状态检查SurfaceView的surfaceDestroyed时序处理好Surface生命周期必要时用TextureView兜底界面整体白屏/无内容合成Buffer异常或OpenGL崩溃看logcat里OpenGL errordumpsys SurfaceFlinger查Layer状态检查硬件加速开关确认是否有关闭硬件加速的异常动画过程中掉帧严重动画导致DisplayList频繁重建用过度绘制查看绘制层级考虑LAYER_TYPE_HARDWARE或将动画移到RenderThread可独立处理的对象上高刷屏上帧率锁在60系统合成或BufferQueue未匹配高刷模式dumpsys SurfaceFlinger --latency查看帧间隔调整刷新率切换策略确认HWC状态5.2 容易被忽略的三个坑第一个坑StrictMode和掉帧检测只是结果指标不是定位工具。我看到很多人卡顿发生时只会说“这一帧16.9ms”但根本不知道是哪里的16.9ms。其实应该要抓Perfetto而且抓的时候一定要包含SurfaceFlinger进程不然只能看到App内部隔离的一半真相。第二个坑View.setBackground的颜色叠加。这个问题很隐蔽给根布局设了背景色给RecyclerView的item也设了背景色再给item里某个控件设了背景色结果三层的背景全部参与了绘制把GPU带宽消耗在了看不见的地方。很多所谓的“复杂布局导致卡顿”其实根本原因是背景叠加把不必要的背景改成透明即可大幅改善。第三个坑Bitmap过大GPU纹理超限。OpenGL ES对纹理尺寸上限有要求部分低端机超过上限会直接绘制失败或黑屏。排查时要检查Bitmap原始尺寸避免用超大尺寸图片做撑满屏幕的背景正确做法是先用BitmapRegionDecoder等工具加载尺寸合适的采样图而不是让GPU去处理一张明显超限的纹理。写在最后这条链路走下来我觉得最有价值的一点是当你真正理解渲染和合成是两套独立机制后你在做界面优化时就不会再被“卡顿”这个词带偏而是会冷静地问是绘制阶段慢了还是合成阶段慢了是主线程掉帧还是GPU掉帧针对不同环节对症下药很多之前靠乱试碰运气的优化就变成了有依据的工程决策。我个人还有一个习惯想分享给你遇到难定位的渲染问题先别急着改代码先用dumpsys命令把当前进程的Surface、Layer、缓冲情况全部打出来看一眼很多时候问题会自己浮出水面。比如你怀疑某个弹窗一直在做动画一查Layer状态发现它确实每隔几帧就在queueBuffer那问题的源头就清楚了。最后再补一条实战经验动手优化前先在真机上把“GPU呈现模式分析”打开跑一遍目标场景观察条形图的高低和颜色分布。如果绿色条密集且高度一致说明渲染管线稳定如果出现很多红色长条再去深挖具体阶段。磨刀不误砍柴工原理和工具配合起来比一上来就写优化方案靠谱得多。