★ FEATURED ARTICLE 最近在调某个跨平台UI引擎的性能遇到了一个非常典型的案例代码里只改了一个滑块控件的取值结果整屏界面肉眼可见地闪了一下帧时间从4ms直接飙到18ms。用帧调试工具抓下来一看GPU把整张1920×1080的画面重新画了一遍。明明要改的只有左上角那几十个像素最后却烧掉了整屏的渲染带宽。这种“立即渲染的带宽危机”在图形界面项目里很容易踩到尤其在嵌入式UI、游戏HUD和桌面应用里表现神出鬼没。这篇文章就把“改一个像素为什么烧光整屏”拆开讲透从带宽账本到渲染管线行为再到可落地的定位与修复方案。1. 现象复盘一整屏究竟是怎么被“误伤”的1.1 一个滑块值引发的“全屏事故”先说那个具体案例。项目背景是一个自研的跨平台UI框架渲染层走CPU生成绘制命令、GPU负责合成上屏。我在里面做一个控制面板滑块拖动时会修改数值标签的内容理论上只需要重绘标签那一小片区域。但实际表现完全不是这样拖动滑块时整个窗口出现闪烁文字边缘还有轻微撕裂感。一开始我怀疑是布局重排导致整个面板的尺寸变化检查布局树后发现节点位置根本没动然后又怀疑字体缓存是否在重建看了缓存的命中率也正常。最后把帧调试工具打开才发现每一帧都有一个1920×1080的RenderPass被完整重建而且里面塞满了整个面板的绘制命令。问题出在事件传播上。框架的窗口缓存策略是“单一Surface 全局invalidated”任何控件的脏矩形一旦向窗口管理器上报就会被子节点到根节点的遍历过程展开成全窗口尺寸。设计者的本意可能是为了简化脏矩形处理逻辑避免不同控件重叠时出现漏刷但在“立即渲染”这种要求下副作用被无限放大。一个标签的变化变成了整张窗口位图重新生成。我当时的第一反应是骂框架太粗暴但后来想想这种“局部改动全屏重绘”并不是哪一家独有的问题。很多引擎为了保证渲染正确性都会在最坏情况下选择保守策略。麻烦的是它不会直接报错只是带宽悄悄烧掉帧率慢慢变差最终表现为“UI越来越卡”。1.2 三类最常见的“局部改动、全屏重绘”触发点梳理这类问题通常会落在下面三个环节上。第一是脏矩形合并失败。控件的invalidate区域在向上传播时如果父容器没有正确裁剪或者由于透明背景、复杂圆角、裁剪区域无法精确描述框架就会放弃精确计算直接把整层标记为脏。尤其在滚动容器、遮罩层和模糊效果混用的时候脏矩形几乎一定会被迫扩大到安全范围。第二是纹理图集全量上传。现代UI引擎为了减少draw call会把大量控件贴图、字体位图塞进一张大Atlas。任何控件内容的像素变化如果引擎只是简单地把整张图集重新上传到GPU那么一次小改动就会触发几十MB的数据搬运。第三是RenderPass与RenderTarget重建。局部更新在渲染API层面往往意味着结束当前Pass并开启新Pass而很多代码为了统一处理会顺手做一次整RT的clear。于是“改一个像素”的操作在GPU上等价于全屏clear一遍画一遍再解析一遍。这三个触发点单独出现都能接受但当一个UI框架把它们叠加起来每次改单个像素都会变成一次灾难。下面的表简单归纳了它们的特征。触发点为什么会出现直接影响脏矩形传播失败父容器无法精确裁剪采用保守策略绘制范围扩大为整层/整窗口图集全量上传纹理更新未走局部子资源接口一次改字整张纹理数据被搬运RenderPass重建新旧Pass切换时全RT Clear全屏写入全屏解析2. 带宽的数学先算清楚一个像素到底值多少钱2.1 分辨率、色彩深度、帧率的三重乘法“烧带宽”这个词听上去抽象其实说到底就是“单位时间内从显存里搬了多少字节”。计算它不复杂就三个变量相乘像素数、每像素字节数、每秒帧数。以1080p为例1920×1080等于2073600个像素。如果像素格式是RGBA8888每像素4字节那么一帧全屏图像的数据量是2073600×4约8.29MB。跑60帧每秒就是8.29MB×60大约497MB/s。这还只是“写入一个全屏RT”的最低值。一旦加上MSAA抗锯齿比如4x MSAA像素缓冲会按4倍计算直接逼近2GB/s。再来一两个后处理RT带宽需求轻松翻倍。到了4K就更加夸张。3840×2160约829万像素RGBA8888一帧就是33.1MB60帧每秒接近2GB/s。很多桌面应用界面看起来只是比1080p清晰了一点但带宽需求翻了四倍帧率掉得飞快。我曾经写过一个快速估算带宽的小脚本把宽高、位深、帧率和RT数量填进去立刻就能得到一个理论下限值。写在这里供参考。def estimate_bandwidth_gbps(width, height, bytes_per_pixel, fps, rt_count1, msaa1): frame_bytes width * height * bytes_per_pixel * rt_count * msaa return frame_bytes * fps / (1024 ** 3) # 1080p, RGBA8888, 60fps, 1个RT print(estimate_bandwidth_gbps(1920, 1080, 4, 60)) # 约0.46 GB/s # 4K, RGBA8888, 60fps, 2个RT print(estimate_bandwidth_gbps(3840, 2160, 4, 60, rt_count2)) # 约1.85 GB/s这里有一个经常被忽略的点上面算的只是渲染目标写入。如果shader里采样了很多纹理还要加上纹理读取带宽。另外深度缓冲和模板缓冲在特殊效果中也占带宽只不过UI场景里通常占比不大。2.2 别忽略读取带宽水管放水的同时也在抽水很多人算带宽只盯着写入忽略了读取。打个比方GPU访问内存就像一根水管你往杯子里倒水写入的同时又在用同一个水龙头抽水读取两根方向加起来才是总流量而水管的粗细是固定的。举个实际场景界面背景要做模糊效果。常见做法是把一张截图放进shader每个输出像素采样9次甚至16次。假设是全屏模糊写入带宽是8.29MB/帧读取带宽就是8.29MB×16约132MB/帧加在一起一帧就超过140MB。如果再做降采样、再放大带宽成本成倍往上走。很多UI的“毛玻璃”效果慢不是shader计算量大纯粹是采样次数把带宽吃满了。我自己做性能分析时有个习惯先算理论值再对比工具读到的实测值。如果实测值明显超过理论值就去查是不是有shader在疯狂采样或者是不是某个RT被反复读写。这个环节往往能快速定位问题。3. 渲染管线里到底发生了什么3.1 CPU端提交的惯性为什么不能只画一个像素很多人第一次遇到“改一个像素烧掉整屏”时会下意识地问我都知道要改哪个像素了为什么不直接告诉GPU只更新那一块遗憾地说渲染API的提交粒度根本不在“像素”这一层。GPU的工作单位是draw call也就是你告诉它“用这个shader、这个纹理、这个顶点数据画这批三角形”。每个draw call会把一批几何体画出来至于这批几何体最终覆盖多少个像素驱动和硬件不会去单独优化。你想更新一个像素最直接的做法就是把这个像素所属的整个控件重新画一遍。控件面积越大被重画的像素就越多。更有甚者如果你改了shader的uniform参数部分驱动会认为shader版本发生变化触发管线状态重排。后续所有draw call都要重新验证、重新绑定、甚至重新编译变体CPU和GPU之间来回同步这比单纯重画几个像素还要伤。从我踩坑的经验看CPU端的这种“惯性”是整屏重绘的放大器。它把一个小控件的重绘放大成一大片区域的重复提交。如果你在profiler里看到draw call数量没变多少但CPU时间涨了十有八九就是状态切换导致的流水线停滞。3.2 GPU端RenderPass与平铺架构局部更新反而更贵如果说CPU端的问题只是重复提交那GPU端的问题就更本质了。移动平台和很多低功耗设备上的GPU都是Tile-Based架构它们会把屏幕切成一个个小块在块内的片上内存完成计算最后再把结果写回主存。这个架构对RenderPass非常敏感。一个RenderPass开始后所有绘制工作都在Tile内进行片上内存很快Pass结束时所有Tile的结果需要“冲刷”回显存。如果你中途想做局部更新就必须结束当前Pass再开启一个新Pass。结束旧Pass意味着全量把当前帧缓冲写回开启新Pass又意味着读回或者清理目标。这一来一回局部修改反而比继续沿用旧Pass更昂贵。还有一个隐藏问题清屏。很多UI渲染代码习惯在每次Pass开始后对RT做全屏clear这只是为了代码逻辑简单并不考虑“这次到底需不需要清理全部区域”。在TBDR架构下每帧做一次整屏clear意味着全屏写一遍如果再把pass的结果解析resolve到显示缓冲区又是一遍全屏写。一个“改一个像素”的局部操作在GPU侧承担的却是整屏clear加整屏resolve的完整代价。所以优化RenderPass的一个关键点是检查LoadAction与StoreAction。如果下一个Pass要覆盖全屏那LoadAction用DontCare通常没问题如果需要保留上一帧内容就要用Load。但要注意Load不一定比Clear便宜因为Load往往要把原有数据从显存读回到Tile里。正确的做法是尽量少开Pass而不是纠结于某个局部区域是否值得单独开一个Pass。3.3 纹理上传局部更新经常变成全量重传第三个重灾区是纹理上传。UI引擎把文字、图标、控件状态图打包到一张Atlas纹理里字模更新时只需要修改某个小矩形区域。但很多实现为了省事只要标记“纹理dirty”就直接把整张Atlas重新Copy一遍。举一个具体例子一张2048×2048的RGBA8888图集体积是16MB。假设你只是更新了一个24×24的字符位图正常应该只传约2.3KB。但如果代码写的是整张上传这次更新就是16MB。如果这个字符串以60fps逐字弹出一秒就是960MB光纹理上传就能把带宽吃干净。正确的做法是用局部更新接口比如图形API里的子资源更新或者地图集存储设备映射。OpenGL系可以走glTexSubImage系列只更新指定矩形D3D系有UpdateSubresourceVulkan则可以将上传命令拆出来通过vkCmdCopyBufferToImage指定目标区域和偏移。核心思路都一样只把变化的矩形喂给GPU。有个很容易踩的坑如果纹理启用了硬件压缩格式如ASTC、BC7部分驱动并不支持局部上传。因为压缩块会覆盖2D区域内的小块想更新一个像素往往要连带更新整个压缩块。碰到这种情况一个比较实用的策略是把高频变化的元素从大图集里拆出来放到一张单独的、较小的非压缩纹理中。这样虽然增加了draw call但每次更新的数据量小了许多总体带宽是划算的。3.4 合成器缓存失效系统级别的“整屏重来”UI最终上屏还要经过一个合成阶段不管它是应用层自带的合成器还是系统级的显示合成器。合成器为了省带宽会缓存每个图层的位图只有当某个图层的内容发生变化时它才重新合成该图层与相邻图层。问题在于很多图层的边界定义得很宽。比如窗口的背景层带了实时阴影或高斯模糊哪怕你只改了左上角1像素合成器也得重新计算整层的模糊结果因为模糊的半径跨过了整个区域。这种感觉就像你只弄脏了桌布的一角但洗衣机会因为“这块桌布被标记为脏”而把整块桌布洗一遍。这个层面的修复通常不是修改shader能搞定的要从UI架构入手把经常变化的动态内容例如滑块、动画、进度条和几乎不变的静态内容背景、标题、装饰拆到不同图层。动态层更新时静态层缓存可以直接复用合成器只需要重新混合两个图层而不是彻底重建整屏内容。4. 定位问题怎么证明烧的是带宽而不是CPU4.1 用帧调试工具验证“整屏是否真的被重画”遇到界面卡顿不要急着改代码先抓两帧对比。一帧是正常状态一帧是你刚触发单像素修改之后的状态。在帧调试工具里重点确认几件事RenderPass列表中有没有出现全屏RT这些Pass的Clear/Load/Store动作分别是什么每个Pass的Viewport是不是覆盖了全屏。如果看到Pass从屏幕坐标(0,0)到(1920,1080)并且StoreAction是Store或者Resolve基本可以断定它在进行全屏写入。再看一眼这两帧之间DrawCall的几何体列表如果所有控件都重新提交了那就说明脏矩形优化已经失效。很多工具允许你为RenderTarget命名这个习惯要养成。给RT起名之后帧调试器里能一眼看出谁是全屏主缓冲、谁是后处理缓冲、谁是UI局部缓存。我之前排查那个滑块问题时就是先把RT列表拉出来发现一个名为“MainWindow”的RT每帧都被清空重画下一步就直接按图索骥了。4.2 带宽计数器的读法光看帧画面还不够要用GPU Profiler看计数器。这里不指名具体厂商的工具因为不同平台都有类似项关键是理解数值含义。计数器含义排查时的关注点GPU BusyGPU整体忙碌程度CPU空闲但此项高往往瓶颈在渲染Shader ALU着色器计算单元占用UI场景若此项高查复杂特效Texture Read纹理读取带宽异常高时优先查采样次数和全屏模糊Render Target Write渲染目标写入带宽全屏Clear/Resolve会很直观的体现在这项Total Memory Bandwidth综合内存带宽接近硬件峰值时应优先做减法一个典型的反直觉情况是DrawCall数量变化不大但Render Target Write暴涨。这是因为重绘的控制件虽然少但覆盖的是一整屏。这时候不要再去优化draw call合并要回头解决“为什么要重画一整屏”的问题。4.3 从帧时间倒推带宽饱和的特征如果你手上暂时没有带宽计数器可以用帧时间的变化方向来倒推。CPU时间没变、GPU时间却明显上涨优先怀疑填充率或带宽如果GPU时间也涨了但DrawCall数量没涨那大概率不是CPU提交问题而是像素层面的读取写入量失控了。以我那个滑块案例为例改动前DrawCall是145改动后是147基本没差。但GPU Busy时间从4ms跳到20msTotal Memory Bandwidth从0.9GB/s飙到3.8GB/s。这就说明问题根本不在几何提交而在于全屏RT的重建和纹理搬运。有了这个结论就可以放心地往脏矩形、图集上传、合成缓存方向去查。5. 修复把“重画全屏”按回“局部”5.1 建立Damage Tracking先做减法修复的第一步是让UI框架知道“本次只有这一块需要重画”而不是把所有变化都提交给全屏。常见的做法是维护一个脏矩形列表新来的脏矩形先和已有矩形做合并如果合并后的外接矩形面积膨胀超过阈值就保留独立区域分多次提交。struct DirtyRect { int32_t x, y, width, height; }; bool TryMerge(DirtyRect merged, const DirtyRect incoming) { DirtyRect bound { std::min(merged.x, incoming.x), std::min(merged.y, incoming.y), std::max(merged.x merged.width, incoming.x incoming.width) - std::min(merged.x, incoming.x), std::max(merged.y merged.height, incoming.y incoming.height) - std::min(merged.y, incoming.y), }; int64_t mergedArea (int64_t)bound.width * bound.height; int64_t oldArea (int64_t)merged.width * merged.height; int64_t newArea (int64_t)incoming.width * incoming.height; if (mergedArea (oldArea newArea) * 2) { merged bound; return true; } return false; }合并策略要小心。如果两个脏区域相距很远强行合并成一个外接矩形面积会急剧膨胀甚至可能从“局部重绘”退化成“全屏重绘”。所以在合并前要计算面积增长率超过阈值就保持分离。这个阈值取决于你的场景我一般控制在2倍以内超过就宁可多刷几个小矩形。另外框架层的绘制入口要区分“整层失效”和“局部失效”。如果某个控件自身有离屏缓存它的变化其实只需要把缓存重新渲染到目标上并不需要让父容器重新绘制所有子节点。5.2 用LoadAction与局部RenderPass做取舍渲染API层面的局部更新需要具体问题具体分析。如果只是某个小控件变化但你为了它新开一个全屏RenderPass清RT的成本可能比原本直接重绘还高。这时候宁愿继续沿用原有Pass只在对应区域做绘制。真正值得新开Pass的场景是目标区域非常小并且这个Pass能够在一小块区域里独立处理。比如某个小弹窗它自己有独立的RT尺寸只有300×200开一个局部Pass完全没有问题。反过来如果整个窗口是一个RT你想刷新其中一个小块那就别开Pass了直接把局部绘制命令追加到原Pass里。还有一个容易被优化误导的点LoadAction的选择。很多人听说“不要每帧Clear”就一律改成Load结果在移动GPU上反而变慢。因为Load需要把旧数据从显存搬回TileClear却可以直接重置。经验法则是如果这个区域下一帧会被完全覆盖用DontCare如果只更新一小部分用Load反而需要读回旧内容未必划算。权衡标准还是那笔带宽账。5.3 动纹理时只传局部纹理上传的修复最直接找到所有“纹理dirty就整张上传”的代码改成局部子资源更新。下面是一段OpenGL风格的示意关键参数是目标偏移和尺寸。glBindTexture(GL_TEXTURE_2D, atlasTexture); glTexSubImage2D( GL_TEXTURE_2D, 0, dirtyRect.x, dirtyRect.y, dirtyRect.width, dirtyRect.height, GL_RGBA, GL_UNSIGNED_BYTE, updatedPixels );Vulkan里则是把上传缓冲区拷贝命令的范围限定到Image的offset和extent原理一样。这里强调一件事不要为了局部更新牺牲图集的内存布局。如果图集里的元素是动态变化的尽量把它们放在纹理的固定区域并且单独维护一份“哪些行需要刷新”的位图标记避免每次都算错矩形。对于压缩纹理做局部更新很困难的情况我建议从架构上绕过高频变化的元素不再入大图集而是放进独立小纹理。比如一个动态图标只有64×64上传一次仅16KB即使每帧上传都只有微小的带宽而如果它在大图集里一次变化可能就要连带更新整个压缩块甚至被框架误伤整张上传。独立小纹理增加的draw call通常不多但省下的带宽非常可观。5.4 像素格式与纹理压缩抠字节就是抠带宽带宽和像素字节数成正比所以降低每像素位数是直接有效的手段。下面列几个常见格式供参考。格式每像素字节1080p60全屏写入带宽备注RGBA88884497MB/s通用质量最好RGBA44442248MB/s有透明度色阶表现一般RGB5652248MB/s无Alpha适合不透明UIASTC 4x4约1约124MB/s压缩纹理需注意质量把UI的主RT从RGBA8888改成RGB565全屏写入带宽直接少一半代价是颜色精度下降。对于纯色背景、扁平化UI来说问题不大但如果界面里有平滑渐变或者大量阴影过渡颜色断层会非常明显。所以我一般只在低端机或者副屏界面里用RGB565。压缩纹理对带宽的帮助也非常大但要注意它并不适合动态变化的内容。压缩编码本身有开销而且很多平台不支持压缩纹理的子资源部分更新。静态背景、静态图标、字体图集这种内容可以放心用压缩格式动态图片、视频纹理、高频变化区域要斟酌一下。还有一个容易被忽视的点深度和模板缓冲。如果你的UI渲染开了全屏深度测试每帧都要读写大量深度数据。很多2D UI根本不需要深度缓冲关掉之后带宽立刻降一截。5.5 图层拆分把“容易变的”和“不易变的”分开图层拆分是最省带宽的设计级优化。把一整个界面拆成静态背景层、动态内容层和浮层更新频率不同缓存策略也不同。静态背景层只在创建或窗口尺寸变化时渲染一次之后完全不做任何更新动态内容层包含列表、滑块、动画它有自己的RT变化时只重绘本层浮层用于弹窗、提示面积通常不大单独管理。合成器在混合这些层时只需要重新合成发生变化的层其他层的缓存直接复用。我在做那个滑块面板时最终就是把背景和装饰性元素抽离成静态缓存层滑块和数字标签放进动态层弹窗放进独立浮层。之后拖动滑块时背景层完全不参与重绘带宽从3.8GB/s降回了0.7GB/s帧率恢复到稳定状态。这个改动比任何shader优化都生效快因为它在架构上就阻止了“全屏重绘”的发生。图层拆分的代价是多了一些合成开销。如果动态层是透明的合成器依然要把动态层和背景层逐像素混合这部分成本省不掉。但总体来看重绘整个动态层只涉及界面的一部分比重绘全屏要小得多收益通常远大于开销。5.6 过滤无效变化按需刷新最后一个修复手段不涉及GPU却往往最划算不要为了没变化的数据触发刷新。事件回调里如果新旧值相同直接返回控件处于不可见状态时不要标记脏矩形界面完全静止时连合成器都不需要调度帧率可以降到0直到下一次输入事件。很多UI的带宽问题其实是从“每帧都强制刷新”开始的。有些团队为了让动画流畅就把整个界面固定锁在60fps即使当前界面是静态的。这个习惯在低功耗设备上是纯粹的浪费。正确做法是动画播放期间锁定动态层帧率动画结束后停止刷新静态层保持缓存不动。6. 常见问题与排查速查表6.1 排查顺序遇到“改一个像素整屏重绘”类问题我的排查顺序如下供你参考。现象可能原因快速验证修复方向帧时间突然变高DrawCall没涨全屏RT Clear/Resolve帧调试工具看Pass的Load/Store换LoadAction、缩小Pass区域某次文字/图标更新后卡顿图集整张上传Profiler看Texture Write局部子资源上传、拆分动态图集背景模糊/阴影出现后帧率下降全屏采样次数过多统计Shader采样器数量降采样、预先烘培静态背景界面静止但GPU占用很高每帧强制刷新检查是否动不动就invalidate增加无效变化过滤、按需刷新移动端比桌面端卡得多Tile架构下Pass切换成本高查看RT数量与Pass次数合并Pass、减少RT切换6.2 我踩过的几个坑先说说盲目的脏矩形合并。之前我为了提高CPU效率把多个小脏矩形合并成一个大的外接矩形结果CPU是省了GPU却因为大面积重绘反而更卡。后来改成面积阈值控制的合并策略CPU和GPU才平衡下来。这个教训说明优化不能只看单侧指标必须同时衡量CPU时间和带宽。再说图层缓存。我曾经把一张带实时时钟的背景图放进静态缓存层结果时钟每一秒都在变更静态缓存每帧都在重建等于没有缓存。把时钟从背景层剥离开之后静态层终于名副其实。这个坑的教训是缓存层里绝不能放任何“会变的东西”否则缓存机制会被完全架空。还有一个关于LoadAction的坑。我一度认为“不清屏”总是比“清屏”好于是把所有Pass改成Load结果在某个移动设备上反而变慢。后来想明白Load需要把上一帧内容读回GPU内部带宽开销并不低。对于会被完全覆盖的区域直接用DontCare更好只有局部更新且需要保留周围像素时Load才有优势。最后提醒一点UI逻辑分辨率和使用时的物理像素经常不是1:1。如果你在缩放比例下开发看到的是1080p逻辑分辨率实际物理像素可能是1440×3200带宽就是另一个数量级。做计算时一定要用物理分辨率。6.3 对于“看起来没毛病却烧带宽”的几个冷门场景有几个场景很容易在自查时漏掉。第一种是动态字体。很多字体缓存实现会把新出现的字形塞进图集如果图集满了还要做淘汰和碎片整理每次整理常常意味着整张图集上传。我建议把字体图集和普通控件图集分开避免文字变化时重传所有控件图片。第二种是窗口透明区域的跨越。很多桌面框架的窗口不是矩形的或者带圆角透明遮罩这让合成器难以精确裁剪只能重绘整层。如果你做的是工具类小窗口尽量避免让整窗都带实时阴影把阴影预烘培成一张位图会比实时计算省太多带宽。第三种是垂直同步与多倍缓冲。为了防撕裂有的框架会同时维护多张后缓冲内容变化时不作区分地重新合成所有缓冲。这种情况下即使只有一个小区域变化多个缓冲也会被依次刷新。建议把“内容是否变化”作为合成触发的唯一条件而不是无条件逐帧合成。写在最后的实操体会我在反复排查这类问题之后把整个思路收敛成一句话局部修改之所以烧光整屏通常是脏矩形、纹理上传、RenderPass、图层缓存这几个环节里至少有一环退回到了“全量安全模式”。大多数情况下不是哪个API用错了而是设计时为了正确性牺牲了精确性。你需要在正确性达标的前提下逐步把“安全的全屏”改回“精确的局部”。我在那个滑块案例里最终的成果是带宽从3.8GB/s降到0.7GB/s帧率从18ms回到4ms整个改动没有牺牲任何渲染效果只是让每一次更新都只碰它该碰的区域。如果你也正被类似问题困扰建议先从帧调试工具抓两帧对比开始先确认有没有整屏重建再沿着脏矩形、图集上传、Pass切换、图层拆分这条链路逐级往下查通常很快就能找到那个藏在代码深处的“保守默认值”。
阅读完成 · 觉得有帮助？
