type
status
date
summary
tags
category
icon
一、移动平台硬件架构二、移动平台画面渲染过程三、CPU端优化业务逻辑、网络通信、I/O操作业务逻辑网络通信与I/O操作GC（Garbage Collect）Draw Call的优化Dynamic Batching 动态批处理Static Batching 静态批处理Physics 物理系统VSync 垂直同步四、GPU端优化顶点着色器中间操作片元着色器五、内存优化Mono内存U3D类的内存1. AssetBundle六、引用
一、移动平台硬件架构
在移动平台中，无论是Android还是IOS用的都是统一内存架构，GPU和CPU共享同一个物理内存，通常我们有“显存”和“内存”两种叫法，可以认为是这块物理内存的所有者不同。当物理内存映射到CPU，就是通常意义上的内存；当映射到GPU，就是通常意义上的显存。同一时刻同一段物理内存只会存在一个映射。
二、移动平台画面渲染过程
- CPU通过调用绘制命令（称为一次Draw Call）来告诉GPU开始进行一个渲染过程的。一个Draw Call命令会指向本次绘制需要渲染的信息，这些信息包括：顶点数据、纹理数据、shader参数（光照模型、法线方向、光照方向等）等
- GPU接收到Draw Call命令之后就会开始进行一次单元渲染，关于GPU的单元渲染的过程是这样的（简单示意图）：
1）从显存中取出拷贝的顶点数据和光照模型。
2）通过顶点处理器（Vertex Processor）对顶点数据进行一系列的变换和光照处理，包括裁剪处理。tips: 简单的想想，游戏中的各个物体的坐标都是参照游戏中的世界坐标系的，而实际显示的画面是玩家视角或者摄像机视角，这中间就有许多坐标系的转换。这些活就需要顶点处理器来做，最终我们得到了我们所需要视角的画面。
3）到这一步，画面还只是一些多边形，而实际显示在屏幕上的是一个个像素，这里就需要（光栅处理器）Rasterizer进行光栅化（Rasterization），从而将画面变成一个像素图，把所有的顶点对应到一个一个的像素位置。
4）对这些像素进行上色，通过片元处理器（Fragment Processor）中的像素着色器（Pixel Shader）按照shader光照模型，根据纹理对应位置颜色，计算元颜色，再经过深度计算、透明测试计算出每个像素的最终颜色。
5）把结果输出到图像缓存中，全部完成后拿去显示。
三、CPU端优化
在移动端中，CPU端的优化非常重要，因为CPU的表现直接决定了VR应用的帧率，应用的耗电量，发热量。
业务逻辑、网络通信、I/O操作
这一块的优化和常规的移动端应用优化普遍相同。
业务逻辑
Unity脚本中有一类Update方法，例如Update、FixedUpdate、OnGUI等，这一类方法是在每帧刷新的时候调用，比较影响每帧耗时，为了严格控制这一部分的执行时间，有以下几点需要注意：
- 尽量不要在Update函数中做复杂计算，如有需要，可以隔N帧计算一次，对于纯数学计算，可以开辟新线程来计算（Unity 为什么一般避免使用多线程，实际上大多数游戏引擎也都是单线程的，因为大多数游戏引擎是主循环结构，逻辑更新和画面更新的时间点要求有确定性, 如果在逻辑更新和画面更新中引入多线程，就需要做同步而这加大了游戏的开发难度。UnityEngine绝大多数类是不支持子线程的，所以一般只有纯数学计算才会用到子线程去计算）
- 关闭所有在update类中执行log的打印操作。Unity中一次log打印有时长达7ms。
- 不在update类方法调用Getcomponent、SendMessage、FindWithTag这几个耗时较长的方法
网络通信与I/O操作
Unity工程中使用了资源动态加载，有些资源是保存在服务器端的，在有必要的时候才会通过网络load下去加载。这个资源动态加载需要注意一个问题：由于网络通信过程，CPU总是处于等待的状态，一般资源下载是多线程同时操作，为了尽快上屏显示资源（在这个工程中是一些图片和英雄的3D模型），但是资源有可能是在同一个帧周期中下载完毕的，如果直接加载的话，可能会出现Camera瞬时渲染过多三角形面，造成渲染时间（Camera.Render()函数执行时间）过长，卡顿的现象。所以这里要注意，网络下载可以多线程多任务同时下载，但是在Unity主线程，要避免出现同时加载大型模型和大纹理的情况。最好使用队列的方式，保证一帧只渲染一个3D模型
GC（Garbage Collect）
把GC放在CPU这一部分的原因是：虽然GC是用来处理内存回收的，但是却增加了CPU的开销。一次GC开销的时间可长可短，有时长达100ms，因此对于GC的优化目标就是尽量少的触发GC。
所谓的GC是Mono运行时的机制，而非U3D引擎的机制，所以GC也主要是针对Mono对象而言。明白了这一点，也就知道了GC不是用来处理引擎的Assets（贴图，音效，模型等等）的内存释放的，因为U3D引擎也有自己的内存堆而不是和Mono一起使用所谓的托管堆。
其次我们应该清楚什么类型的资源会被分配到托管堆上，没错，就是引用类型。引用类型包括：用户自定义的类，接口，委托，数组，字符串，Object。值类型包括：几种基本数据类型（如：int，float，bool等），结构体，枚举，空类型。所以GC的优化也就是代码的优化。
在以下两种情况下，GC会触发
- 当我们的堆的内存不足时，会自动调用GC来回收内存
- 手动调用GC，即调用
System.GC.Collect()。一般情况下，不建议手动去手动进行内存回收，因为容易出现问题
通过检测整个工程的代码，关于减少GC这一方面的优化经验总结大概如下：
字符串连接的处理
将两个字符串连接的过程，其实是生成一个新的字符串的过程，之前的旧的字符串自然而然就成为了垃圾。而作为引用类型的字符串，其空间是在堆上分配的，被弃置的旧的字符串的空间会被GC当做垃圾回收。对于这个问题，可以使用StringBuilder来解决，在大量字符串拼接或频繁对某一字符串进行操作时最好使用 StringBuilder，不要使用 String。
不要直接访问gameobject的tag属性
比如
if (go.tag ==“human”)最好换成if (go.CompareTag (“human”))。因为访问物体的tag属性（每次Object.name也会分配39B的堆内存）会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾就可想而知了。不要频繁的实例化（Instantiate）和销毁（Destroy）对象
可以使用对象池实现空间的重复利用
在某些可能的情况下，可以使用结构（struct）来代替类（class）
这是因为，结构变量主要存放在栈区而非堆区。因为栈的分配较快，并且不调用垃圾回收操作，所以当结构变量比较小时可以提升程序的运行性能。但是当结构体较大时，虽然它仍可避免分配/回收的开销，而它由于”传值”操作也会导致单独的开销，实际上它可能比等效对象类的效率还要低。所以要注意选择
场景切换时，可以主动进行垃圾回收
Draw Call的优化
正如前面所说，Draw Call是CPU调用底层图形接口的操作。如果场景中有上千个物体，每一个的渲染都需要去调用一次底层接口，那么CPU必然不堪重负。但是对于GPU来说，图形处理的工作量是一样的。
我们先来看看Draw Call对CPU的消耗大概是一个什么级别的量: NVIDIA 在 GDC 曾提出，25K batchs/sec 会吃满 1GHz 的 CPU，100%的使用率
Draw Call数量 = 25K * CPU_Frame * CPU_Percentage / Framerate
CPU_Frame：CPU的工作频率（GHz）
CPU_Percentage：CPU 分配在DrawCall这件事情上的时间率（%）
Framerate：目标游戏帧率
举例来说，我们使用CPU的型号为高通820，它的工作频率为2GHz，分配10%的CPU时间给Draw Call上，并且我们希望在游戏中能够保持60帧，代入公式计算后得，一帧最多能有83个Draw Call。
所以对Draw Call的优化，主要就是为了尽可能解放CPU在调用图形接口上的开销。所以针对Draw Call优化，我们主要的思路就是每个物体尽量减少渲染次数，最好多个物体一起渲染。那么Draw Call次数的优化有哪些方案呢？
Dynamic Batching 动态批处理
Dynamic Batching即动态合批，Unity引擎对于使用相同材质（shader完全一样）的物体会自动进行批处理。这一部分要注意那些破坏这一行为的人为因素，例如：
- 批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体，如果你的着色器使用顶点位置，法线和UV值三种属性，那么你只能批处理300顶点以下的物体（如果在这基础上还使用了UV2，则只能批处理180顶点以下的物体）；请注意：属性数量的限制可能会在将来进行改变
- 使用不同的缩放比例的物体，unity将无法对这些物体进行批处理。比如（1,1,1）和（1,2,2）就不会动态批处理，但是（1,1,1）和（2,2,2）会动态批处理
- 拥有lightmap的物体含有额外（隐藏）的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非他们指向lightmap的同一部分）。接受实时阴影的物体也不会批处理
- 多通道的shader会中断批处理操作（为了达到特殊的渲染目的，可能某个物体要多遍渲染.这是就要多个通道）
- 在脚本中动态地指定了物体的材质，也不会进行批处理
Static Batching 静态批处理
动态批处理虽然是自动的，但是限制非常多，不小心就会打破批处理，所以unity在专业版中还提供了静态批处理，静态批处理要求是想批处理的物体一定是static的，静态的，不会改变位置和旋转角度以及缩放的，且必须材质一致。其原理是把物体的网格进行合并，变成一个静态的更大的网格物体，再使用一个统一的材质进行渲染
- 在一个平行光、环境光下，没有问题，但是如果你使用了多个平行光，点光源，聚光灯这种复杂的光源去照射物体，那么静态批处理就会被打断。（项目中就遇到过，因为两边有两排英雄模型，所以场景中使用了两个不同平行光，场景中勾选的static物体并没有被合并drawcall，经过一番折磨才找到原因）
- 如果静态批处理前有一些物体共享了相同的网格，那么每一个物体都会有一个该网格的复制品（本来unity只会保留一份，但是静态批处理会生成新的一个大网格，所以会保留所有物体的网格，最后合并），即一个网格会变成多个网格被发送给GPU。这样会造成内存的使用变大，需要注意这个问题，但是一般场景中使用相同网格的物体会比较少。
- 对于那些shader相同，纹理不同导致的不同材质无法进行批处理的物体（比如项目中的场景环境，基座，地面，其实都使用了unity自带的standard shader）可以通过纹理合并的方法来使得它们可以被静态批处理。但是可能会引发BUS总线带宽问题。
CPU完成一次DrawCall，除了需要发一个Draw Call的命令之外，还需要把内存中顶点数据、纹理贴图、shader参数通过bus总线拷贝到内存分配给GPU的显存之中，注意这是拷贝，不是指针传递，速度不快。如果一次drawcall传递的数据过大，带宽成为了瓶颈，那就会大大影响效率（其它的DrawCall无法出发，GPU又处于闲置）。这种情况最有可能出现在为了减少DrawCall，疯狂的合并纹理上。在项目中，UI的DrawCall调用占了很大一部分，也会最难优化的，为了减少Draw Call ,我们把UI模块的静态部分（一些UI的底板，背景等不会发生变化的）全部合并成了一个纹理，最后导致了Draw Call下降了，但是帧率却也下降了，内存使用也增加了，原因就是这个。在项目中，不会同时出现的元素不要打包到一起，保证单张合并纹理不大于1024*1024一般就不会有问题了（王者荣耀最大纹理限制在了256*256）
Draw Call的优化大概就是这些，优化的目标其实是往一个目标上靠，CPU的Draw Call命令刚刚好能被GPU消化，不要让CPU等待（带宽限制），也不要让GPU闲置。如果即使做到了这个，应用帧率还是上不去，那么就只能去削减场景，做有损优化了
Physics 物理系统
Unity内置NVIDIA PhysX物理引擎来模拟物理世界的一些效果，比如说重力、阻力、弹性、碰撞这些，其中使用了一些内置的组件来实现这些模拟，用的比较多的如：刚体（Rigidbody） 各种碰撞器（Collider） 恒力 （Constant Force） 物理材质（Physic Material）铰链关节（Hinge Joint）弹簧关节（Spring Joint）。
除了提供了一些重要的组件之外，在unity脚本中的生命周期中提供了一个专门为物理计算的刷新方法：
FixedUpdate()FixedUpdate跟Update的区别在于：这两个函数处于不同的“帧循环”中，FixedUpdate处于Physics循环中，而Update不是。Update的执行受场景GameObject的渲染的影响，三角形的数量越多，渲染所需要的时间也就越长。FixedUpate的执行则不受这些影响。所以，Update每个渲染帧之间的间隔是不相等的，而Fixedupdate在每个渲染帧之间的时间间隔是相等的。由于关系到物理模拟，所以一般涉及到物理组件，都需要放在Fixedupdate中进行计算。那么关于physics，一般的优化手段都有哪些呢？下面是一些经验及总结：
1、将物理模拟时间步间隔设置到合适的大小。 Fixed Timestep是和物理计算有关的，所以若计算的频率太高，自然会影响到CPU的开销。同时，若计算频率达不到软件设计时的要求，有会影响到功能的实现，所以如何抉择需要具体分析，选择一个合适的值，一般大于16ms，小于30ms。可以通过Edit->Project Settings->Time来改变这个值。
2、谨慎使用网格碰撞器（Mesh Collider），过于消耗性能，一般使用更简单的碰撞器，或者使用基本几何碰撞器合并的组合碰撞器。在这个项目中，把所有的网格碰撞体都抛弃了，都换成了box collider。
3、真实的物理（刚体）很消耗，不要轻易使用，尽量使用自己的代码（数学计算）模仿假的物理。
4、最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息。
VSync 垂直同步
科普：VSync垂直同步又称场同步(Vertical Hold)，垂直同步信号决定了CRT从屏幕顶部画到底部，再返回原始位置的时间。从CRT显示器的显示原理来看，单个像素组成了水平扫描线，水平扫描线在垂直方向的堆积形成了完整的画面。显示器的刷新率受显卡DAC控制，显卡DAC完成一帧的扫描后就会产生一个垂直同步信号（决定于屏幕的刷新率）。我们平时所说的打开垂直同步指的是将该信号送入显卡3D图形处理部分，从而让显卡在生成3D图形时受垂直同步信号的制约（注意是制约）。
简单地说，这是CPU优化的最直接的一个方法。
如果我们选择等待垂直同步信号（也就是我们平时所说的垂直同步打开），那么在游戏中或许强劲的显卡迅速的绘制完一屏的图像，但是没有垂直同步信号的到达，显卡无法绘制下一屏，只有等垂直同步的信号到达，才可以绘制。这样FPS自然要受到操作系统刷新率运行值的制约。而如果我们选择不等待垂直同步信号（也就是我们平时所说的关闭垂直同步），那么游戏中作完一屏画面，显卡和显示器无需等待垂直同步信号就可以开始下一屏图像的绘制，自然可以完全发挥显卡的实力。但是不要忘记，正是因为垂直同步的存在，才能使得游戏进程和显示器刷新率同步，使得画面更加平滑和稳定。
取消了垂直同步信号，固然可以换来更快的帧率，但是在图像的连续性上势必打折扣。
四、GPU端优化
一般说Draw Call的优化占了U3D优化的三分天下，那么GPU的优化也占了三分天下。在了解GPU优化都有哪些着手点之前，我们先了解一下GPU在3D软件渲染中做了啥事：
顶点着色器
GPU接收顶点数据作为输入传递给顶点着色器。顶点着色器的处理单元是顶点,输入进来的每个顶点都会调用一次顶点着色器（顶点着色器本身不可以创建或销毁任何顶点，并无法得到顶点与顶点之间的关系）。顶点着色器是完全可编程的，它主要完成的工作有：坐标变换和逐顶点光照。 坐标变换：就是对顶点的坐标进行某种变换—把顶点坐标从模型空间转换到齐次裁剪空间。顶点的多少直接决定了三角形面的多少，也直接决定了GPU的渲染流水线的工作量，所以减少顶点数是一个比较重要的优化点。那么减少顶点怎么操作呢，又有哪些途径？
- 优化基本几何体
3D软件都是从模型制作开始，在设计师建模的时候就要想到应该尽可能地减少顶点数，一些对于模型没有影响、或是肉眼非常难察觉到区别的顶点都要尽可能去掉。比如在项目中，对于用户背后的环境模型，一些树木和石头，视频背面永远无法看见的神庙，能削减的都已经削减了。
- 使用LOD（Level of detail）技术
LOD技术有点类似于Mipmap技术，不同的是，LOD是对模型建立了一个模型金字塔，根据摄像机距离对象的远近，选择使用不同精度的模型。它的好处是可以在适当的时候大量减少需要绘制的顶点数目。它的缺点同样是需要占用更多的内存，而且如果没有调整好距离的话，可能会造成模拟的突变。
- 使用遮挡剔除（Occlusion culling）技术
遮挡剔除是用来消除躲在其他物件后面看不到的物件，这代表资源不会浪费在计算那些看不到的顶点上，进而提升性能。刚才神庙后面的剔除就属于手动的遮挡剔除。
遮挡剔除是一个PRO版才有的功能， 当一个物体被其他物体遮挡住而不在摄像机的可视范围内时不对其进行渲染。遮挡剔除在3D图形计算中并不是自动进行的。因为在绝大多数情况下离 camera 最远的物体首先被渲染，靠近摄像机的物体后渲染并覆盖先前渲染的物体，这被称为重复渲染”overdraw”。 遮挡剔除不同于视锥体剔除. 视锥体剔除只是不渲染摄像机视角范围外的物体而对于被其他物体遮挡但依然在视角范围内的物体，则不会被剔除. 注意当你使用遮挡剔除时，视锥体剔除（Frustum Culling）依然有效。
中间操作
1、曲面细分着色器：是一个可选的着色器，主要用于细分图元。
2、几何着色器：是一个可选的着色器，可用于执行逐图元的着色操作，或者被用于产生更多的图元。
3、裁剪：这一阶段是可配置的。目的是把那些不在视野内的顶点裁剪掉，并剔除某些三角形图元的面片。部分在视野内的图元需要做裁剪处理，在裁剪边缘产生新的顶点和三角形进行处理。
4、屏幕映射：这一阶段是可配置和编程的，负责把每个图元的坐标（三维坐标系）转换成屏幕坐标（二维坐标系）。
5、三角形设置：开始进入光栅化阶段，不再是数学上点了，而会把所有的点都映射到屏幕的具体像素坐标上，计算每条边上的像素坐标而得到三角形边界的表示方式即为三角形设置。
6、三角形遍历：这一阶段会检查每个像素是否被一个三角风格所覆盖。如果覆盖的话，就会生成一个片元，一个片元并不是真正意义上的像素，而是包含了很多状态的集合，这些状态用于计算每个像素的最终颜色。
这些状态包括了屏幕坐标、深度信息，及从几何阶段输出的顶点信息，如法线和纹理坐标等。这样一个查找哪些像素被三角形覆盖的过程就是三角形遍历。
片元着色器
片元着色器的输入就是上一阶段对顶点信息插值得到的结果，更具体点说，是根据从顶点着色器中输出的数据插值得到的。而这一阶段的输出是一个或者多个颜色值。这一阶段可以完成很多重要的渲染技术，如纹理采样，但是它的局限在于，它仅可以影响单个片元。片元着色器是比较花时间的，因为它是最终颜色的计算者，在某些情况下，例如复杂灯光环境下，片元着色器会出现GPU流水线主要的拖后腿的存在。为了让片元着色器的计算更加快，我们需要从很多方面进行提前的优化：
- 减少overdraw
片元着色器最容易拖后腿的情况就是overdraw。和Android app的开发一样，同一个像素点绘制了多次，某些情况会造成计算力的浪费，增加耗电量。前面提到的遮挡剔除有减少overdraw非常有用。
在PC上，资源无限，为了得到最准确的渲染结果，绘制顺序可能是从后往前绘制不透明物体，然后再绘制透明物体进行混合。但是在移动平台上，对于不透明物体，我们可以设置从前往后绘制，对于有透明通道的物体（很多UI纹理就是含有透明通道的），再设置从后往前绘制。
- 减少实时光照
实时光照是移动平台的最大敌人。一个场景里如果包含了三个逐像素的点光源，而且使用了逐像素的shader，那么很有可能将Draw Calls提高了三倍，同时也会增加overdraws。这是因为，对于逐像素的光源来说，被这些光源照亮的物体要被再渲染一次。更糟糕的是，无论是动态批处理还是动态批处理（其实文档中只提到了对动态批处理的影响，但不知道为什么实验结果对静态批处理也没有用），对于这种逐像素的pass都无法进行批处理，也就是说，它们会中断批处理。
所以当你需要光照效果时，可以使用Lightmaps，提前烘焙好，提前把场景中的光照信息存储在一张光照纹理中，然后在运行时刻只需要根据纹理采样得到光照信息即可。当你需要金属性强（镜面）的效果，可以使用Light Probes。当你需要一束光的时候，可以使用体积光去模拟这个效果。
- 不要使用动态阴影
- 简单的使用一个带阴影的贴图
- 烘焙场景，拿到lightmaps
- 创建投影生成器的方法
- 使用ShadowMap的方法
动态阴影很酷，但是对于片元着色器来说是灾难，阴影计算是三角投影计算，非常耗性能。如果想要阴影，可以使用
- 尽量使用简单的shader
- 议尽量实用Unity自带mobile版本的(built-in)Shader，这些大大提高了顶点处理的性能。当然也会有一些限制
- 自己写的shader请注意复杂操作符计算，类似pow,exp,log,cos,sin,tan等都是很耗时的计算，最多只用一次在每个像素点的计算，还有有些除法运算尽量该能乘法运算等
- 避免透明度测试着色器，因为这个非常耗时，使用透明度混合的版本来代替
- 浮点类型运算:精度越低的浮点计算越快
- 不要在Shader中添加不必要的Pass.
五、内存优化
unity中有两类内存，一个是Mono托管的内存，一个是Unity3D使用的资源类类型的内存（Texture、Mesh这种）。
Mono内存
- 尽量不要动态的创建和销毁对象，尽可能使用对象池
- 字符串拼接时，可以使用StringBuilder
- 避免在Update中获取数据（GetComponent），可以在Start中余先存起来，例如可以通过一次获取组件的引用来避免开销，并将该引用分配给一个变量（transform用的最多）
- 尽量减少函数调用栈，例如：用x = (x > 0 ? x : -x);代替x = Mathf.Abs(x)
- 定时重复逻辑处理可以用 InvokeRepeating 函数实现
U3D类的内存
1. AssetBundle
六、引用
- 作者:Felix
- 链接:felix1125.com/article/1663c27a-8c04-45dd-81c2-7c1fd0c684ad
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章