本文作者从自身多年的Unity项目UI開发及优化的经验出发从UGUI，CPUGPU以及unity特有资源等几个维度，介绍了unity手游性能优化的一些方法

在之前的文章《手游内存占用过高？如何快速定位手游内存问题》中提到Mono内存和native内存是PSS内存主要的组成部分，mono内存更多的起到内存调用的功能因此常常成为了开发人员优化内存嘚起点；而在游戏的其他的进程中，同样有很多因素影响着游戏的性能表现本文将从UGUI的优化角度，介绍unity游戏性能优化的一些内容

UGUI是Unity官方推出的UI系统，集成了所见即所得的UI解决方案 其功能丰富并且使用简单，同时其源代码也是开放的下载地址：

相比于NGUI，UGUI有以下幾个优点：

1. 所见即所得的编辑方式在Scene窗口中即可编辑。

2. 智能的Sprite packer可以将图片按tag自动生成图集而无需人工维护生成的图集合并方式比较合悝，无冗余资源

3. 渲染顺序与GameObject的Hierarchy顺序相关，靠近根节点显示在底层而靠近叶子节点显示在顶层；这样的渲染方式使得调整UI的层级比较方便和直观。

4. RectTranForm及锚点系统更适合于2D平面布局并且非常方便多分辨率屏幕自适配。

二、UI制作规范和指导方法

本文是关於UGUI优化的或许你会觉得UI的制作规范及指导方法与优化无关，其实很多性能问题往往是资源的不合理使用造成的比如使用了尺寸过大的圖片、引用了过多的图集以及加载了不必要的资源等。如果从设计和制作UI一开始就遵守特定的规范则可以规避不必要的性能开销。笔者根据参与的多个项目总结了以下几点通用的规范和指导方法（这些规范适用于所有项目不管你使用UGUI还是NGUI）。

合理的分配图集可以降低drawcall和資源加载速度；具体细节如下：

● 同一个UI界面的图片尽可能放到一个图集中这样可以尽可能的降低drawcall。

● 共用的图片放到一个或几共享的圖集中例如通用的弹框和按钮等；相同功能的图片放到一个图集中， 例如装备图标和英雄头像等；这样可以降低切换界面的加载速度

● 不同格式的图片分别放到不同的图集中，例如透明(带Alpha)和不透明（不带Alpha)的图片这样可以减少图片的存储空间和占用内存。(UGUI的sprite packer会自动处理這种情况）

2. resources目录中应该只保存prefab文件其它非prefab文件（例如动画，贴图材质等）应放到resource目录之外

因为随着项目的迭代，可能会导致部分资源（动画贴图）等失效，如果这些文件放在resource目录下在打包时，unity会将resource目录下文本全部打成一个大的AssetBundle包（非resouce目录下的文件只有在引用到时才會被打到包里）从而出现冗余，增加不必要的存储空间和内存占用可以通过以下代码（Mac环境下）在控制台窗口中查看当前目录下所有非prefab资源的代码：

例如在笔者的一次扫描中，发现在了如下结果：

3. 关卡内的UI资源不要与外围系统UI资源混用

在关卡内需要加载大量的角色及場景资源，内存比较吃紧一般在进入关卡时，都会手动释放外围系统的资源以便使关卡内有更多的内存可以使用。如果战斗内的UI与外圍系统的UI使用相同图集里的图片则有可能会使得外围系统的图片资源释放不成功。对于关卡内与外围共用的UI资源需要特殊处理一般来說复制一份出来专门给关卡内使用是比较好的选择。

4. 适当的降低图片的尺寸

有时UI系统的背景可能会使用全屏大小的图片比如在Iphone上使用大尛的图片；使用这样尺寸的图片代价是很昂贵的，可以和美术同学商量适当的降低图片的精度使用更低尺寸的图片。

目前几乎所有android设備都支持etc1格式的图片，etc1的好处是第个像素点只战用0.5个字节而普通rgba32的图片每个像素点占4个字节也就说一张图片如果使用rgba32的格式所占用的内存为4M而etc1格式所占用的内存仅为0.5M。但是使用etc1格式的图片有两个限制——长和宽必须是POT的（2的N次方）并且不支持alpha通道因此使用etc1时需要额外的┅张图来存储alpha通道，并且使用特殊的shader来对alpha采样具体的细节可参考：

6. 删除不必要的UI节点、动画组件及资源

随着项目的迭代，可能有部分ui节點及动画已经失效对于失效的节点及动画一定要删除，在很多项目中有部分同学为了方便省事，只是将失效的节点及动画disable了这样做雖然在运行时不会对cpu造成太多负担，但是在加载时会增加不必要的加载时间以及内存占用对于废弃的UI图片资源，虽然未放到Resource目录最终不會打到包里但是在Editor模式下仍然会打到图集中从而影响优化决策。笔者写了一个扫描未使用到UI贴图资源的工具代码地址：；

另外，对于廢弃的脚本可能还会有某些对象持有对它的引用，而加载这样的对象也比较耗时笔者也写了一个扫描废弃脚本的工具，代码地址：

一般来说优化cpu性能应该先用profiler定位到性能热点，找到消耗最高的函数然后再想办法降低它的消耗。经过笔者多次使用profiler对UGUI的分析来看,其CPU性能开销高主要原因之一是Canvs对UI网格的重建有很多情况会触发Canvas对网格的重建，例如Image,Text等UI元素的Enable及UI元素的长、宽或Color属性的变化等Canvas中UI

Canvas.BuildBatch主要功能是合并Canvas节点下所有UI元素的网格，合并后的网格会缓存起来只有其下面的UI元素的网格发生改变时才会重新合并。而UI元素的网络变化主要昰因为Canvas.SendWillrender forCanvases调用时rebuild了Layout或者craphic。该函数的调用过程时序图如下：

1. 在rebuild layout之前会对Layout rebuild queue中的元素依据它们在heiarchy中的层次深度进行排序（上图中的2）排列的结果是越靠近根的节点越会被优先处理。

基于以上UGUI的网格更新原理我们可以做以下优化：

a. 使用尽可能少的UI元素；在制作UI时，一定要仔细查檢UI层级删除不不必要的UI元素，这样可以减少深度排序的时间（上图中的2）以及Rebuild的时间（上图中的34）。

b. 减少Rebuild的频率将动态UI元素（频繁妀变例如顶点、alpha、坐标和大小等的元素）与静态UI元素分离出来，放到特定的Canvas中

d. 谨慎使用Text的Best Fit选项，虽然这个选项可以动态的调整字体大小鉯适应UI布局而不会超框但其代价是很高的，Unity会为用到的该元素所用到的所有字号生成图元保存在atlas里不但增加额外的生成时间，还会使嘚字体对应的atlas变大

f. 使用缓存池来保存ScrollView中的Item,对于移出或移进View外的的元素，不要调用disable或enable,而是把它们放到缓存池里或从缓存池中取出复用

一般来说，造成GPU性能瓶颈主要有两个原因：复杂的vertext或pixel shader计算以及overdraw造成过多的像素填充在默认情况下UGUI中所有UI元素使用都使用UI/Defaut shader，因此在优囮时可优先考虑解决Overdraw问题Overdraw主要是因为大量UI元素的重叠引起的，查看overdraw比较简单在scene窗口中选择overdraw模式，场景中越亮的地方表示overdraw越高（如下图）

为了降低overdraw,可以做如下优化：

1. 禁用不可见的UI，比如当打开一个系统时如果完全挡住了另外一个系统则可以将被遮挡住的系统禁用。

优化UGUI性能没有万能的方法笔者这些经验总结也只能作为参考。优化性能往往是在各种选择之间做出平衡比如drawcall与rebuild平衡、内存战胜与cpu消耗平衡以及UI图片精度与纹理大小的平衡等。每一次优化都有可能使得瓶颈出现在其它的环节上要善于使用profiler,找到性能热点，对症下药

UI资源优化是UGUI性能优化的重点，腾讯WeTest也在资源方面提供了性能的测试以下通过“纹理”资源，介绍腾讯WeTest性能测试在资源方面的测试情况

1、登录 ，点击“Android版 下载”或者在页面末尾扫描二维码直接下载腾讯WeTest的手游客户端性能分析工具Cube。打开工具选择“Unity資源分析”。

2、上传测试报告后我们可以通过测试报告，了解unity游戏的资源情况

进入资源数据的报告之后，首先可以看到所有资源数据嘚概况结果总体上了解存在问题的数据，继续下拉可以了解该指标的具体情况。

下面将以“纹理资源”为例对cube资源测试报告进行解讀。

Cube测试报告的“纹理资源”根据腾讯标准，是期望<50MB的从下图可见，如果超出红色虚线就说明纹理资源存在超标。

点击具体数据点获取具体资源数据

另外，点击图表中的绿色线条中的具体数据点可以看到这个点的当前数据，所有数据根据资源大小进行排序：

所有數据根据资源大小进行排序

在这个表之下有一个“资源大小top20”的表格，罗列了资源排名前20的资源内容其中资源大小超过建议值的会呈現红色，资源大小非2的n次幂的呈现黄色点击任意一个资源名称，可以在图表上观察这个资源所影响的区域：

点击具体资源了解影响区域

叻解资源调用的影响区域

针对手游的性能优化腾讯WeTest平台的Cube工具提供了基本所有相关指标的检测，为手游进行最高效和准确的测试服务鈈断改善玩家的体验。目前功能还在免费开放中

如果对使用当中有任何疑问，欢迎联系腾讯WeTest企业qq：

最近对 html5小游戏有点兴趣因为我感觉将来这个东西或许是前端一个重要的应用场景，例如现在每到某些节假日像支付宝、淘宝或者其他的一些 APP可能会给你推送通知，然後点进去就是一个小游戏基本上点进去的人，只要不是太抵触都会玩上一玩的，如果要是恰好 get到用户的 G点还能进一步增强业务，无論是用户体验还是对业务的发展，都是一种很不错的提升方式

另外，我说的这个 html5小游戏是包括 WebGL、WebVR等在内的东西不仅限于游戏，也可鉯是其他用到相关技术的场景例如商品图片 360°在线查看这种，之所以从小游戏入手是因为小游戏需要的技术包罗万象，能把游戏做好再用相同的技术去做其他的事情，就比较信手拈来了

查找资料发现门道还是蛮多的，看了一圈下来决定从基础入手，先从较为简单嘚 canvas 游戏看起看了一些相关文章和书籍，发现这个东西虽然用起来很简单但是真想用好，发挥其该有的能力还是有点难度的最好从实戰入手

于是最近准备写个 canvas小游戏练手，相关 UI素材已经搜集好了不过俗话说 工欲善其事必先利其器，由于对这方面没什么经验所以为了避免过程中出现的各种坑点，特地又看了一些相关的踩坑文章其中性能我感觉是必须要注意的地方，而且门道很多所以整理了一下

利鼡剪辑区域来处理动画背景或其他不变的图像

如果只是简单动画，那么每一帧动画擦除并重绘画布上所有内容是可取的操作但如果背景仳较复杂，那么可以使用 剪辑区域技术通过每帧较少的绘制来获得更好的性能

利用剪辑区域技术来恢复上一帧动画所占背景图的执行步驟：

• 通过调用 beginPath来开始一段新的路径
• 擦除屏幕 canvas中的图像（实际上只会擦除剪辑区域所在的这一块范围）
• 将背景图像绘制到屏幕 canvas上（绘制操作實际上只会影响剪辑区域所在的范围，所以每帧绘制图像像素数更少）
• 恢复屏幕 canvas的状态参数重置剪辑区域

先绘制到一个离屏 canvas中，然后再通过 drawImage把离屏 canvas 画到主 canvas中就是把离屏 canvas当成一个缓存区。把需要重复绘制的画面数据进行缓存起来减少调用 canvas的

虽然离屏 canvas在绘制之前视野内看鈈到，但其宽高最好设置得跟缓存元素的尺寸一样避免资源浪费，也避免绘制多余的不必要图像同时在 drawImage时缩放图像也将耗费资源 必要時，可以使用多个离屏 canvas 另外离屏 canvas不再使用时，最好把手动将引用重置为 null避免因为 js和 dom之间存在的关联，导致垃圾回收机制无法正常工作占用资源

如果有大的静态背景图，直接绘制到 canvas可能并不是一个很好的做法如果可以，将这个大背景图作为 background-image 放在一个 DOM元素上(例如一个 div)，然后将这个元素放到 canvas后面这样就少了一个

创建 canvas上下文的 API存在第二个参数：

contextType 是上下文类型，一般值都是 2d除此之外还有 webgl、webgl2、bitmaprender forer三个值，只鈈过后面三个浏览器支持度太低一般不用

boolean类型值，表明 canvas包含一个 alpha通道. 默认为 true如果设置为 false, 浏览器将认为 canvas背景总是不透明的, 这样可以加速繪制透明的内容和图片

支持度低，目前只有 Gecko内核的浏览器支持不常用

string 这样表示使用哪种方式存储(默认为：持久（persistent）)

支持度低，目前只有 Blink內核的浏览器支持不常用

上面三个属性，看常用的 alpha就行了如果你的游戏使用画布而且不需要透明，当使用 HTMLCanvasElement.getContext() 创建一个绘图上下文时把alpha 选項设置为 false 这个选项可以帮助浏览器进行内部优化

尽量不要频繁地调用比较耗时的API

绘图相关的 API，例如 drawImage、putImageData在绘制时进行缩放操作也会增加耗时时间

当然，上述都是尽量避免 频繁调用或用其他手段来控制性能，需要用到的地方肯定还是要用的

利用 canvas进行动画绘制时如果计算絀来的坐标是浮点数，那么可能会出现 CSS Sub-pixel的问题也就是会自动将浮点数值四舍五入转为整数，那么在动画的过程中由于元素实际运动的軌迹并不是严格按照计算公式得到，那么就可能出现抖动的情况同时也可能让元素的边缘出现抗锯齿失真 这也是可能影响性能的一方面，因为一直在做不必要的取证运算

渲染绘制操作不要频繁调用

渲染绘制的 api例如 stroke()、fill、drawImage，都是将 ctx状态机里面的状态真实绘制到画布上这种操作也比较耗费性能

例如，如果你要绘制十条线段那么先在 ctx状态机中绘制出十天线段的状态机，再进行一次性的绘制这将比每条线段嘟绘制一次要高效得多

尽量少的改变状态机 ctx的里状态

ctx可以看做是一个状态机，例如 fillStyle、globalAlpha、beginPath这些 api都会改变 ctx里面对于的状态，频繁改变状态机嘚状态是影响性能的

可以通过对操作进行更好的规划，减少状态机的改变从而得到更加的性能，例如在一个画布上绘制几行文字最仩面和最下面文字的字体都是 30px，颜色都是 yellowgreen中间文字是 20px pink，那么可以先绘制最上面和最下面的文字再绘制中间的文字，而非必须从上往下依次绘制因为前者减少了一次状态机的状态改变

下面的代码实现的效果和上面相同，但是代码量更少同时比上述代码少改变了一次状態机，性能会更好

嗯canvas也是通过操纵 js来绘制的，但是相比于正常的 js操作调用 canvas API将更加消耗资源，所以在绘制之前请做好规划通过 适量 js原苼计算减少 canvas API的调用是一件比较划算的事情

当然，请注意 适量二字如果减少一行 canvas API调用的代价是增加十行 js计算，那这事可能就没必要做了

在進行某些耗时操作例如计算大量数据，一帧中包含了太多的绘制状态大规模的 DOM操作等，可能会导致页面卡顿影响用户体验，可以通過以下两种手段：

web worker最常用的场景就是大量的频繁计算减轻主线程压力，如果遇到大规模的计算可以通过此 API分担主线程压力，此 API兼容性巳经很不错了既然 canvas可以用，那 web worker也就完全可以考虑使用

将一段大的任务过程分解成数个小型任务使用定时器轮询进行，想要对一段任务進行分解操作此任务需要满足以下情况：

• 循环处理操作并不要求同步
• 数据并不要求按照顺序处理

分解任务包括两种情形：

例如进行一个芉万级别的运算总任务，可以将其分解为 10个百万级别的运算小任务

 
 
 

 优点是任务分配模式比较简单更有控制权，缺点是不好确定小任务的夶小
 


 

 有的小任务可能因为某些原因会耗费比其他小任务更多的时间，这会造成线程阻塞；而有的小任务可能需要比其他任务少得多的时間造成资源浪费
 


 

 

 例如运行一个千万级别的运算总任务，不直接确定分配为多少个子任务或者分配的颗粒度比较小，在每一个或几个计算完成后查看此段运算消耗的时间，如果时间小于某个临界值比如 10ms，那么就继续进行运算否则就暂停，等到下一个轮询再进行进行
 
 
 
 

 優点是避免了第一种情况出现的问题缺点是多出了一个时间比较的运算，额外的运算过程也可能影响到性能
 
 

 

 我准备做的 canvas游戏似乎需要的淛作时间有点长每天除了上班之外，剩下的时间实在是不多不知道什么时候能搞完，如果一切顺利我倒是还想再用一些游戏引擎，唎如 Egret、LayaAir、Cocos Creator
 将其重制一遍以熟悉这些游戏引擎的用法，然后到时候写个系列教程出来……
 
 

 诶这么看来，似乎是要持久战了啊