编辑：啊妹 2017-06-27
签约授权投稿，来源 腾讯GAD，转载请注明网站来源及作者
Unite大会是由Unity举办的全球开发者大会，至今已有10年的历史。Unite现已成为游戏行业，VR/AR行业中最具有权威性和影响力的活动。高川：先自我介绍一下，我叫高川，是来自Unity的技术工程师。在正式演讲之前，我先问一下在座的各位，有哪位同学有谁被性能问题坑过。
从昨天开始，一直在讲优化优化，性能性能。今天我的演讲也是跟性能有关的。我今天的演讲分为六个部分，首先先要了解一下什么是性能优化，性能优化的要点，性能与分析工具的比较，还有我们新的工具，eaglEEye的演示还有对它未来的规划。
性能优化的本质
首先什么是性能优化，性能优化的本质到底在聊什么。首先我认为性能优化是没有金科玉律的，我们在做现场支持的时候，很多人都在问这个问题，你觉得我按照什么样的标准我能够获得最好的性能。我把数字做到什么样的标准上我这个性能就无敌了。我说你想得太简单了，这个东西真的没有统一的标准，也不是说我告诉你一个数字，你做到这个数字就OK了。因为目标平台不同。我举一个简单的例子，在安卓上面我们都知道IO是受到很大的性质，但是在IOS上面，它非常快。之前做一个项目，我们发现在IOS上面每次用的时候，直接开IO就完全没有问题。在安卓上面就很卡。目标群不一样，男用户、女用户，年龄群的不同，对它的期待也不一样。游戏类型不同，重度游戏和轻度休闲游戏标准也不一样。然后到底是CPU还是GPU是内存还是渲染，这个也不一样。其实我觉得工程实施团队不同，因为每个团队都有每个团队的特点，每一个团队的组成也是各有不同的。我们提出一个方案的时候经常会问到，你们在这个方案上想用多长时间来做。你们的人实施的方案会用多大的成本。我们当然想做到一个性能非常极端的方案，但是现实不允许。往往越极端，背后付出的成本越高，老板是不高兴的。
怎么做性能优化？
其实性能优化要做的就是去峰填谷，时空转换。比如说这几天在聊Unity内部的机制。清除不必要的消耗，用智慧换性能。然后用空间换时间，用时间换空间，这是非常经典的。我们用的内存换掉了我们运行时的计算时间。拥有时换劣势，用长处弥补短处。这也已经非常常见了。一个典型的例子，有一个团队的包做得非常小，但是他们所有的asset都是经过高度压缩的，但是你要花更多的时间去压缩。归根到底，性能优化是一种平衡的艺术，只要消除木桶效应，你才能获得一个最优化的性能。同样要实现各个模块之间的最佳平衡状态。我们并不认为把所有的数字都做成最极限的，我们认为把所有的数字做到最佳的平衡才是性能优化最应该追求的目标。性能优化的目标我分成几点。
第一个就是逻辑帧率，一个是CPU的瓶颈，主要的耗时函数，频繁的GC，错误的逻辑和多线程。其实这个大家比较好理解。CPU瓶颈，有的机器CPU非常弱，但是GPU很强大。比如说苹果。我们知道在Unity里面有一些很敏感的函数，其实是建议大家用得越来越少。因为每一次调用都会不可避免地遇到时间消耗。
我们知道在任何一种情况下，无论是2D也好，3D也好，粒子永远是一个消耗非常高的话题。频繁的GC这个不用说，我们在做GC的时候，实际上是一个全局的遍历机制。它是相对来说非常慢的机制，无论它是不是GC，都会有这样的便利消耗。所以避免频繁的GC，一定要去除不必要的GC。错误的逻辑很好理解。多线程其实也是一个非常有意思的话题。现在Unity来讲并没有一个真正的多线程接口提供给大家。昨天有一个同事在分享的时候，我们有了Job System之后，才是真正的多线程。大家都会以为说我有了多线程就无敌了，但是其实不是的。它所有的计算，负载是没有变的，所以多线程只是导致主要线程不太卡，并不是减负了。另外当你的多线程代码很复杂的时候，他们会进行额外的消耗，这些反而会降低你的性能。
第二个是内存的使用，说完了CPU，当然就是内存了。首先就是内存泄露。但是严格来讲，Unity是不存在内存泄露的。大部分内存你是可以拿到的，你只是不用。所以这种情况应该叫僵尸内存。僵尸内存比实际泄露更可怕。你觉得你在用，但是你最后发现你这个东西根本不在用。
我给大家举一个例子，刚开始有一个五兆数据表，但是在最后发现，它读到的次数不到五次。这个就是僵尸内存。频繁的GC Alloc这个也是内存里面会遇到的问题，还有Unity使用的native内存。它并不会导致有一些非常严重的内存泄露的问题，但是确实是有消耗的。渲染性能我们其实主要关注的几个点，一个是三角形顶点的数量，DrawCall和Setpass。这种计算换出来的渲染效率是不是真的值得，这个其实也是要平衡的一个地方。还有就是shader的复杂度。
第三个是资源的使用，其实在资源导入的过程当中，是我们见到问题最多的地方。assetBundle到底用什么方式来管理，什么时候卸载一直是一个老生常谈的话题。还有一个就是包体大小，它会影响用户下载的积极性，所以它会影响到几个方面，一个是assetBundle打包方式，然后冗余资源，还有平台特性。像安卓、IOS都有一些很好的平台特性帮大家减包，但是我们之前也肯到有很多的团队对这个平台的特性并不是非常地了解，甚至是直接地忽略掉了。说了这么多，我们知道有这样那样的性能问题，有这样那样需要注意的点，但是人毕竟不是一个机器。我不可能都把Unity的视频翻出来，看看是不是做对了每一步了。所以我们需要工具，而且我们是程序员，我们需要工具来帮我们做一些不应该由我们做的事情。
Unity性能优化的工具
第一个是Unity的profiler，它有很多的优点，比如说它的数据分类非常明确，然后它的曲线展示，易读性高，同时原生数据统计，可靠性高。同时还有不足，Unity profiler展示的帧数是有限制的，一旦太长了，前面的就不见了。你们需要去了解或者通过一些手段去了解。所以采集数据的含义解读困难。再有一个就是，首先从根本上来说是一个软件层级的统计，所以统计的数据并不全面，有些数据是统计不到的。
第二个就是Xcode instrument，它数据全面，然后比较高的分析能力，还有可靠性高。有些选项可以帮你快速定位一些渲染方面的问题。同时它也有不足，首先就是IOS Only。我们到了很多团队之后，很多团队说我们没有IOS版本，我们都是安卓版本。因为我们老板买windows很便宜，再往IOS移植，这是一个现实的问题。从而带来的问题是，真正去了解Xcode instrument的，在一个团队里面是凤毛麟角的。还有与Unity的数据对应困难，这种对于没有专业培训过的人来讲，阅读起来是非常困难的。你反过来去对应的时候是很难以对应的。
第三个是GAPID，我不知道在座的同学有没有人知道。这个是谷歌最新在开发的一个在安卓平台上通用的一个Graphic，它也是按照硬件层级来设计的，同时它也是原生的数据，数据相对来讲比较可靠。它也有不足，比如说安卓，而且仅针对Graphic，它不会对CPU端做过多的分析。这个尚在开发阶段，所以之前用的时候并不是很稳定。同时使用的时候是有一定的学习成本的。
第四个就是第三方的数据分析服务，我们去跟这些厂商沟通的时候，也会自己收集数据，去分析出报告，来指导我自己的团队去优化。那么其实这样有一个好处，它的平台是很成熟的，同时有一定数量的积累。有一些大厂是有很多大型的产品在不停地开发，在这些产品在流动开发的过程当中，可以去帮助不同阶段的产品去分析。还有定制性好，更加符合中国开发者的需求和习惯。也有一个问题，对Unity引擎底层技术缺乏了解，另外一个，每一次Unity版本更新的时候，它的解读技术就会相对落后。所以每一次有新版本出现的时候，都需要做很多额外的工作去跟上。然后就会导致数据解读不准确，在上一个Unity版本里面，它是这样的，到下一个Unity版本里面，就会发生变化。可能你给团队的指导就是错的，导致你的优化方向就是错的。
第五个就是eaglEEye。 说了这么多，所以我们现在再做一个第一方的东西，就是eaglEEye。这个eaglEEye是我们一个性能分析平台，对于很多企业和用户的需求来打造这样一款工具。首先是一个自助式服务，各位无需等待，版本也无需传给第三方，自己测。你们开发到凌晨两点，你们自己来测，拿到结果就可以用了。而且自动生成数据图表。简单的SDK嵌入，现在开发的版本就是是Unitypackage来导入，需要一个配置的App key来识别你到底是哪一个。然后我们现在的工具会对分析出来的一些重要的profiler tag做一些简单的说明。我不知道大家能不能看清，这边有一个小的预览。首先我们现在做的有这么几个功能模块，第一个就是性能总览，我们对这一次的测试结果有一个总体认识，首先对大家比较关注的重点指标，为定位问题来提供第一步的数据认识。下面就是重点分析CPU的时间使用成本，帧率的使用情况，会从整体和部分两个方面来帮大家确定有几个针对点。
我们现在能做的这个版本会针对Mono的内存进行数据分析，针对不同模块使用内存情况进行展示和分析。然后对GC使用情况进行定位。渲染分成三步，第一个就是渲染的总体情况，包括DrawCall还有Setpass的分析。
OK，因为时间比较紧。我先给大家做一个简单的演示，可以看一下。大家现在看到的就是我们的平台，我们现在叫它Atlas，现在在Atlas这个平台上有一个服务叫eaglEEye。现在为了节约大家现场的时间，提前测了一份数据进来，有这么一个测试。可以看一下当前这个工程这次测试的一些情况。这个比较简单，我测了600多帧，平均的DrawCall是这样的，底下有一个CPU的曲线。下面还有memory的总体情况，还有每一个模块的使用情况。我们现在可以看到这个工程里面使用最多的是render。同时我们这边会有function cost的简介，我们会看到一个简单的标识。在CPU这里面，可以看到它是大于60。我们可以看一下现在的Frame rate，我们看其中的一部分。我们看到其中一部分的Frame rate，我想定位一下各个模块当中的情况。大致就是这样一个情况。我们可以看一下目前消耗在这个区域当中所消耗最高的这样一个函数，以及我们user函数的消耗情况。再来看一下memory，其实是类似的操作过程。这边是total used的memory。我们可以看到在这个里面，我们可以看一下在这个区间内，我的游戏在GFX里面占的比较多。我们看一下后面是不是相同的情况。是一个相同的情况，可能我重点优化的点就是在这个地方，再往下就是Mono Usage的情况。它一旦上去就不会下来。在什么样的情况下会上去，在什么样的情况下会上去。很多时候我们关心的是user rate。红色代表的是used memory，这条曲线代表了我在当前这一帧有多少被浪费掉了。这条曲线越平越好，在这一帧上面突然变高，我们看一下这一帧发生了什么。OK，我们可以看到在这一帧，红色刚刚高于了我的reserve memory，这可以很好地帮助大家理解Mono的内存池。其实这样的话，我有一个很明确的点，就是说我把这两个东西给优化掉，reserve不会被冲上去，在后面我整体的使用情况都会变小。在某一帧没有发现情况的时候，你也可以圈框。我在这一圈框里面可以发现，可能我需要优化的点重点在前面两个函数上。
我们再看一下Graphic。我们可以看到一些基本的信息，这款手机基本上是在一个G左右，平均消耗是30帧。然后这些都是基本信息，我们有一个基本的了解。我们再看一下DrawCall和Setpasscall，可以看到是这样一个曲线，还是相对比较平稳的。为什么会有两个DrawCall和Setpasscall。因为在Unity认为，其实我们现在DrawCall并不是我们最大的负担，最大的负担来自于Setpass。所以我们会额外统计一下Setpasscall。而且在Unity5.6的分析框里面，Setpasscall会被认为是一个更重要的参数。我们下面再看一下Triangles，我们可以看一下在某一帧里面，有多少个Triangles被batch。所以通过这样的一个分析的图表，我们可以了解到我们现在到底做了多少事情，是不是有益。如果每一次合并都非常少，我没必要去尝试了。如果我发现每一次的合并都没有地大，说明这个是有意义的。Verticals也有类似的分析，还有Dynamic也有类似的分析，我们可以看到两条柱子和一条曲线，通过batch，我们saved的数。其中有四分之三的时间被saved的时间比较多。再底下还会有一个Static Batch，这个一直都是零，因为一直没有用到。再有就是我们比较关心的比较重要的函数的消耗，比如说Camera Render，还有GPU。再底下还会有其他的两个模块，我们提供一些更高尖的数据。我的CPU里面有一个函数，或者有一段的耗时是比较高的。Special我们对它的定义是说现在Unity不断地加东西我们要分析的东西也不断地加多。
并不是对于每个项目组来说，它的special都是存在的。如果是5.4X或者在2017，更多新的feature会被放在Special，还会用特殊的使用情景。比如说，首先我们说一下未来的规划，第一下就是SDK，现在的使用情况是有一个SDK的方案，但是我觉得这个方案非常麻烦。你每次做的时候，你都要不断地把SDK切来切去。所以以后就是无SDK，未来大家拿到的版本就是没有SDK的，你不需要额外地为这个平台去做。从数据收集层面，现在的数据收集更多依仗于perfile的数据收集，我们还会做游戏的截图。现在也在和Unity的perfile团队讨论，说需要加入更多的数据。我们会从硬件层级和软件层级去分析。还有一个就是RESTFUL的批量测试，现在了解到很多的公司并不需要靠人肉去测试。很多公司现在在用，可能一次会有上百个手机的测试，不可能让一百个人每个人都去跑。一定是用自动化测试平台，大家通过自动化测试工具，也就是说你可以实现无人执手的纯数据分析。我们还如加入更加个性化的数据分析，安卓的还有IOS，个性化数据分析以及不同的硬件配置。还有数据比较，这是很多开发者都非常关心的，我一个月之前测了一次，一个月之后又测了一次，我到底好在哪儿。我们会提供这种历史性的数据比较还有不同设备之间的数据比较。IOS和某一款安卓手机之间是一种类型数据比较，我们希望通过这样来帮助大家找到数据平衡点。
其实Unity一直在想为开发者做更多的事情，其实Unity不可能做完所有的事情，所以会让大家来自定义，你要怎么样来呈现，以及谁和谁比较。优化建议，在你测试之后，你的目的是定位问题，定位问题之后就是要解决问题。首先会有特定项目的建议，比如说在某些测试项目，它如果出现了这样一个高值或者低值意味着什么，你应该怎么去优化。查询资料建议，我们会在刚才的API我们会知道我们的渲染是否过高。实际上在Unity官网有很多很多这样的资源，但是大家没有时间和精力去查找。我们会为大家提供一些这样的参考资料，来帮助大家找到对应解决方案。然后整体的优化建议给出一个相对完整的优化报告来帮助大家完完成整个项目的优化工程。以及Unity的Project review的联动。大概有一千款左右的数字被利用，Project review做了已经有几年了。实际上我们的review经验大概有几千款游戏经验。我们会提供上门的服务来进行现场的调试，通过这个平台能解决问题当然最好，如果解决不了问题可以来找Unity来帮助你解决问题。
更多的工具集合，Atlas这个平台上eaglEEye只是其中一部分。我们希望通过Atlas eaglEEye打造一个在测试阶段的平台。我们会更多的assetBundle的工具，还有包尺寸检测工具。很多人说这个包尺寸工具合理不合理，我们都在做优化。还有代码混淆工具集合等等其他的工具。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
