《Unity 挪动端游戏性能优化简谱》共分为四个局部，明天向大家介绍文章的最初一个局部：画面体现与 GPU 压力的衡量，共 8 大节，蕴含了带宽、Overdraw、渲染成果、后处理、渲染策略、Shader 复杂度等多项常见的游戏画面体现解说。（全文长约 4400 字，预计浏览工夫约 15 分钟）
前三局部可点击以下对应文章查看：
一、《Unity 挪动端游戏性能优化简谱之 前言》
二、《Unity 挪动端游戏性能优化简谱之 常见游戏内存管制》
三、《Unity 挪动端游戏性能优化简谱之 CPU 耗时调优》
1. 总览
当初，越来越多的挪动端游戏开发团队对游戏的画面体现成果谋求也越来越高。GPU 端曾经超过了 CPU 端，成了许多我的项目性能压力的最次要起源，但 GPU 端往往更多地波及到硬件层面的问题，市面上不同的厂商不同的芯片会反馈出不同的景象，为开发者进行机型分档和规范制订造成了困扰；从另一个角度来说，针对 GPU 性能的检测往往不是 Unity 引擎相干的工具所能提供的，而硬件厂商提供的各类工具则繁多而难用，看得人目迷五色而抓不住重点，本质上为 GPU 性能问题的排查和优化带来了微小的艰难。
2. 带宽
2.1 GPU 压力与发热 / 耗能
尽管 UWA 外部做过一些带宽与发热 / 耗能关系的定量实现，但芯片底层的状况远比咱们设想的简单。咱们从教训和跟芯片厂家的业余硬件工程师沟通后得出的论断是：挪动设施上 GPU 带宽的压力还是比拟影响能耗的，特地是在发热这一方面也有不小的影响。但这是定性的说法，目前咱们和芯片厂商都没有特地定量的公式来具体阐明其影响大小。因而，当一个我的项目的发热或者能耗较大，带宽是开发者特地须要关注的中央。
UWA 工具可能监控游戏测试过程中硬件温度的变动，一般而言长时间维持在 55℃以上就是须要警觉的温度了。在 UWA 进一步的 GPU 专项服务中，还会更具体的采集和展现 GPU 和 CPU 别离的温度。
2.2 GPU 压力与帧率
上文中已提到过，GPU 压力大会使得 CPU 期待 GPU 实现工作的耗时减少，与此同时，也会使得渲染模块 CPU 端的次要函数耗时回升，从而影响帧率、造成卡顿。
除此之外，因为挪动端硬件主观上存在体积较小、散热难的问题，使得 GPU 发热会物理上显著影响到 CPU 芯片温度同时回升，重大的即产生降频景象。
除了通过 UWA 工具监控 Gfx.WaitForPresent 和渲染模块主函数的耗时数据外，GOT Online Overview 模式下还反映了测试中 GPU 耗时数据，从而直观地监控 GPU 性能瓶颈；而目前 GOT Online 还集成了 Mali GPU 统计带宽的 API，应用 Mali 芯片的测试机提交 Overview 报告，就能够取得 GPU 着色和带宽数据。后续也将逐渐增加对于高通等硬件的相干性能反对。
在 UWA 进一步的 GPU 专项服务中，还会联合带宽数据和 Clocks 数据，针对低压场景逐 DrawCall 地剖析其占用带宽和 GPU 耗时过高的起因，4.3 开始的局部会探讨一些常见的起因。
2.3 优化带宽
带宽数据是掂量 GPU 压力的重要参考。以绝对高端的小米 10 机型而言，全分辨率状况下，如果须要跑满 30 帧并发热状况稳固，则须要将总带宽管制到 3000MB/ s 以下。为此，常见的优化伎俩有：
（1）压缩格局
在内存的章节中曾经或多或少地探讨过，应用正当的压缩格局，可能无效升高纹理带宽。
（2）纹理 Mipmap
对于 3D 场景而言，对其中的物体所用到的纹理开启 Mipmap 设置，可能用一小部分内存回升作为代价无效升高带宽。当物体离相机越远，引擎就会应用更低层级的 Mipmap 进行纹理采样。但 Mipmap 设置也与正当的纹理分辨率挂钩，一个常见的景象是在理论渲染过程中只用到或者绝大部分用了 Mipmap 的第 0 层进行采样，从而节约了内存，所以要思考升高这类纹理的分辨率。
UWA 工具应用不同色彩来示意应用不同 Mipmap 层级采样的像素以便定位问题；在进一步的服务中，还会依据 Mipmap 各层级使用率列举出每个场景中存在上述节约景象的纹理。
（3）正当的纹理采样形式
除了正当应用 Mipmap 非 0 层采样外，还应关注我的项目中各向异性采样和三线性插值采样。概括来说，纹理压缩采样时会去读缓存外面的货色，如果没读到就会往离 GPU 更远的中央去读 System Memory，因而所花的周期越多。采样点增多的时候，cache miss 的概率就会变大，造成带宽回升。各向异性采样次数在 Unity 中设置有 1 -16，应尽量设置为 1；三线性采样采 8 个顶点，绝对于双线性采样是翻倍的。
UWA 的本地资源检测服务可能统计并列出开启各向异性或三线性采样的纹理资源。
（4）批改渲染分辨率
间接批改渲染分辨率为 0.9 倍乃至更低，缩小参加纹理采样的像素，更加无效地升高带宽。
此外，还应留神读顶点的带宽。相比纹理，它的占比个别会比拟小。但不同于纹理的是，批改渲染分辨率能够无效升高读纹理的带宽，但读顶点的带宽不会受到影响。所以在上文中针对网格资源和同屏渲染面片数的管制行之有效后，读顶点的带宽值应该占总带宽的 10%-20% 较为正当。
3. Overdraw
Overdraw，即屡次绘制同一像素造成的 GPU 开销。在场景中渲染顺序控制正当的现实情况下，不通明物体的 Overdraw 应管制在 1 层。所以，造成 Overdraw 的次要首恶就是半透明物体，也即粒子系统和 UI。
3.1 粒子系统
灵便应用 UWA 的性能剖析工具，能够无效定位对 GPU 压力奉献大的粒子系统。
一种做法是，建设一个专门的空的测试场景，在其中依次播放咱们我的项目中要用到的粒子系统，而后应用 UWA SDK 进行打包测试提交 GOT Online Overview 报告，就能够在 GPU 耗时曲线处，联合测试截图找到播放时 GPU 耗时较高的粒子系统了。
还有一种做法是间接应用 UWA 本地资源检测报告，能够间接看到造成 Overdraw 较高的粒子列表作为参考。
在筛选出须要优化的粒子系统后，对于低端设施尽可能升高它们的复杂程度和屏幕覆盖面积，从而升高其渲染方面的开销，晋升低端设施的运行流畅性。具体做法如下：
（1）在中低端机型上对粒子系统的 Max Particles 最大粒子数量进行限度；
批改前：
限度 Max Particles 为 10 后：
（2）在中低端机型上只保留“重要的”的粒子系统，比方对于一个火焰焚烧的特效，只保留火焰自身，而敞开掉周边的烟尘成果；
（3）尽可能升高粒子特效在屏幕中的覆盖面积，覆盖面积越大，越容易产生重叠遮蔽，从而造成更高的 Overdraw。
对于粒子系统的优化，咱们曾在 UWA DAY 2018 中对移动游戏的 GPU 性能优化中做了些分析，通过从 Fillrate 和 Shader 等几方面登程，联合大量优化过程中的理论案例剖析游戏在 GPU 端的性能瓶颈：《移动游戏的 GPU 性能优化》。
3.2 UI
（1）当某个全屏 UI 关上时，能够将被背景遮挡住的其余 UI 进行敞开。
（2）对于 Alpha 为 0 的 UI，能够将其 Canvas Renderer 组件上的 CullTransparent Mesh 进行勾选，这样既能保障 UI 事件的响应，又不须要对其进行渲染。
（3）尽可能减少 Mask 组件的应用，不仅进步绘制的开销，同时会造成 DrawCall 回升。在 Overdraw 较高的状况下，能够思考应用 RectMask2D 代替。
（4）在 URP 下须要额定关怀是否有没必要的 Copy Color 或者 Copy Depth 存在。尤其是在 UI 和战斗场景中的相机应用同一个 RendererPipelineAsset 的状况下，容易呈现不必要的渲染耗时和带宽节约，这样会对 GPU 造成不必要的开销。通常倡议 UI 相机和场景相机应用不同的 RendererData。
4. 渲染成果
除了粒子特效外，咱们往往还喜爱用一些炫酷的渲染成果来丰盛游戏的体现，比方体积雾、体积光、水体、次外表反射等等，然而场景中用到的此类成果越多，Shader 越简单，给 GPU 带来的压力越是大到远远超出承受范畴的水平。
优化和衡量是决定最初留下哪些渲染成果的次要伎俩。
一方面，从多个计划中比照选取成果和性能较优的，对开源计划依据本身我的项目须要进行精简优化；另一方面，依据机型分档和以后 GPU 压力，取重点而舍主要。能够在 UWA 社区的博客、学堂和开源库中发现一些优化良好、通过实际测验的优良计划。
5. 后处理
Bloom 简直是最受开发者青睐、最为常见的后处理成果了。常见的一个问题是，Bloom 默认是从 1 / 2 渲染分辨率开始进行下采样的。对此，能够思考在中低端机型上从 1 / 4 分辨率开始进行下采样，或缩小下采样次数。
各种后处理成果的性能开销和理论应用场景并不相同，在理论我的项目中遇到的问题也往往各不相同。UWA 社区中也有大量后处理相干的文章和资源，比方《屏幕后处理成果系列之常见后处理成果篇》。
6. 渲染策略
6.1 绘制程序
当场景中存在先画离相机较远的不通明物体，再画离相机较近的物体，而且两者有所重合时，较远物体被较近物体所遮挡局部的像素就有可能被绘制两次，从而造成 Overdraw。
这种状况常产生在地形上。原本当不通明物体的 Render Queue 统一时，引擎会主动判断并优先绘制离相机更近的物体。但对于地形而言往往有的局部比其余物体离相机更近，有的却更远，从而被优先绘制。
所以，须要通过对 Render Queue 等设置，使得离相机越近的物体（如工作、物体等）越先绘制，而较远的如地形等最初绘制。则在挪动平台上，通过 Early- Z 机制，硬件会在片段着色器之前就进行深度测试，离得较远的物体被遮挡的像素深度检测不通过，从而节俭不必要的片元计算。
6.2 有效绘制
存在一些视觉效果不显著能够敞开，或者能够用耗费更低的绘制计划的状况。
比方一种较为常见的状况是，某些绘制背景的 DrawCall，自身屏占比拟大，开销不小，但在引擎中开关这个 DrawCall 没有显著的视觉变动，可能是在制作过程中被弃用或者被其余 DrawCall 齐全覆盖了的成果，则能够思考予以敞开。
还有一种状况是，一些背景是用模型绘制的并带有含糊、雾效等额定的渲染成果。但场景中视角固定、这些背景也简直不发生变化，则能够思考用动态图代替这些简单的绘制作为背景，在低端机上把更多性能留给次要的游戏逻辑和体现成果。
6.3 渲染面积
渲染面积过大造成的性能问题曾经在粒子特效中有所反映和探讨了。但事实上对于不通明物体也实用。对于一个 DrawCall 而言，当它的渲染面积较大、且渲染资源多而简单时，两者遍呈现出一种乘积的作用，它意味着有更多的像素参加纹理采样，参加 Shader 计算，给 GPU 带来更高的压力。
7. Shader 复杂度
除了纹理、网格、Render Texture，还有一种对 GPU 压力奉献极大的渲染资源，也就是 Shader。UWA 尤其关注 Fragment Shader 的屏占比、指令数和时钟周期数，渲染的像素越多、复杂度越高，阐明该 Shader 资源越须要予以优化。
其中，应用 Mali Offline Compiler 工具能够取得 Shader 的指令数和时钟周期数。UWA 的进一步服务中会具体测试项目中所有使用率较高的 Shader 在不同关键字组合下变体的复杂度，从而定位须要着重优化的 Shader 资源及其变体。
8. 总结
这篇文章之所以称为简谱，切实是因为这些笔墨远不能达到八面玲珑，很多内容还未波及到，或者限于篇幅和重点不能深刻探讨。它更多地是立足于如何以用好一套欠缺残缺的性能工具为根底，构建发现问题 - 解决问题 - 监控问题的优化思维和优化体系，使得性能优化的工作事半而功倍。更多的优良内容，欢送在 UWA 社区中进行搜寻。
至此《Unity 挪动端游戏性能优化简谱》曾经全副更新结束，文章从 Unity 挪动端游戏优化的一些根底探讨登程，例举和剖析了近几年基于 Unity 开发的挪动端游戏我的项目中最为常见的局部性能问题，并展现了如何应用 UWA 的性能检测工具确定和解决这些问题。内容包含了性能优化的根本逻辑、UWA 性能检测工具和常见性能问题，心愿能提供给 Unity 开发者更多高效的研发办法和实战经验。