2018 Unite大会——《使用UPA工具优化项目》演讲实录

2018年5月11日至13日，腾讯WeTest与Unity联合打造的移动游戏性能分析工具（Unity Performance Analysis，以下称为UPA）正式亮相2018 Unite大会，为Unity手游开发者提供更加深度的游戏性能优化、测试服务，带来了更多产品测试与优化的“新姿势”。

会上，Unity大中华区企业支持经理&UPA开发工程师高川先生、腾讯游戏性能优化工程师 & UPA开发工程师徐森先生代表UPA团队，为开发者们带来了题为“使用UPA工具优化项目”的分享演讲。

Unite大会技术专场演讲现场

腾讯游戏性能优化工程师 & UPA开发工程师 徐森先生

这么一个大前提下我们说性能优化这个工作既重要也不是很重要，首先它很重要，这是大家玩游戏的过程中都有体会，如果游戏性能优化不好会出现很多问题，比如玩起来卡，闪退或者掉线，这个会导致用户流失掉。这是做性能优化很重要的方面。为什么说它不重要？因为一个游戏的项目组里面最多的同学可能做功能开发或者做美术，或者做发行做运营。其实一个项目组里面专门针对性能优化的人员非常少，一个游戏可能一到两个人左右。这么有限的时间把所有的性能优化好，显然不可能。我们这边进行游戏优化的过程中，最重要的需求就是高效，我们一定在最短的时间内利用最少的人力，帮助我们发现并且解决掉我们游戏可能产生的一些性能问题。

那么说到这里有这样一个想法，我们可以做这个工具帮助我们高效的解决性能问题，所以这是我们UPA这个工具产生的前提条件。所以这个标题是效率，我们工具其实主要是帮助我们提升性能优化的效率工具。那么有了目标以后我们考虑怎么根据目标进行产品的开发，首先第一点为什么强调是Unity和腾讯合作开发的产品，因为我们觉得做这个工具它的前置条件很多，首先对底层的工具了解，后面对游戏测试或者游戏开发中的流程或者规范非常的清楚，可以帮助我们使用人员更快的上手工具，同时这个工具更有针对性。

所以说Unity扮演一个专家角色，对于我们底层的代码负责了解。那么腾讯这边扮演一个偏向于使用者的角色，我怎么设计这个工具，才能最大程度的提高使用人员的效率。所以这是两个前提条件，导致我们两边进行合作产品。这个产品最主要的就是，这边写的可能比较绕口，基于四无产品概念的非侵入式测试。什么意思？解释一下四无，首先第一个我们被测的游戏不需要接入SDK，第二测试机不需要其他的权限，第三测试时候不需要上传被测的应用，第四测试的时候不需要Unity的开发环境。

其实有了四无的概念以后，这个工具在任何场合，只要大家有一款手机，有我需要测试的应用就可以拿到这个工具进行测试了。其实非侵入式我觉得可能是对我们之前的四无的补充，因为我们知道现在很多市面上流行的一些测试产品，在PC端还好一点，那么在手机端可能需要一些很苛刻的Root权限，很苛刻的限制，所以我们强调非侵入式，相当于它的优点。

讲完了主要的以后下面还有一个，其实是全自助式的测试模式，这是针对使用的用户来讲，这样一款工具我们是完全开放给用户自主使用。我可以在任何时间任何地点，当然在家也可以测，任何时间任何的测试的手机上，可以测试我任何想要的场景，其实这么一款游戏测试工具跟玩游戏的场景其实差不多。

那么说了这些大家可能关注到这个工具会有什么样的特点？其实很多工具功能我们都是为了弥补我们当前测试工具的不足来针对性的开发。大家可能平时会使用很多性能优化工具，相信大家使用过程中也会感觉有这样或者那样的不太好用的地方。

我们可以列举一下目前市面上比较流行的一些性能优化工具。最常接触的可能就是Unity Profiler，它是嵌在界面中大家用起来最方便，开发的时候就顺手拿过来，这个是Unity官方推出的，所以有很多好用的地方，比如采集的数据分类非常明确，到底是CPU或者GPU数据或者内存数据或者物理数据，我可以看到问题出哪儿。还有其他的优势，比如说里面的数据是用曲线展示的，可能可读性会好一点，并且数据是从引擎官方内部采集的，所以数据可靠性比较高，不会出现误报的情况，这个就是Profiler本身的优点。

有优点就有缺点，其实平常我们在和用户沟通过程中，经常听到用户的吐槽。比如说Profiler界面显示的数据有限，同一时间有500帧，现在不太清楚，可能会有一些提高。这可能是不太好用的一点，还有另外一点Profiler的数据虽然分类比较明确，但是读起来有些难读，比如说会有一些函数的名字还有模块的名字，单看名字可能不理解这个东西是什么东西，可能还要上论坛上面求助或者Unity的专家去求助，才能大概知道这是什么意思。

还有一个问题其实Unity统计数据是从软件层面来统计的，那么深入不到硬件层，最明显的例子就是不支持的GPU的型号读不到里面的硬件数据，CPU也是读不到，这些数据对优化问题还是很重要的。刚才说到Unity提供的Profiler工具，其实很多硬件上面我们的硬件厂商也有提供一些Profiler工具，比如IOS和安卓上面都有工具。这些硬件厂商提供的工具会有什么优点？他们这些数据的统计和他们的硬件强相关，可以深入到硬件层。那么这样子的话，统计的数据非常的全面，从软件到硬件层都有，并且他们的可靠性非常高。

但是硬件层的数据有一个明显的缺点，就是它的可读性不是很强，我经常可能看到一些内存地址的数据对不上我自己写的代码，这样导致工具使用门槛很高，非常有经验的人才可能从工具中发现一些问题。

说完了硬件，随着Unity在国内使用的幅度越来越大，其实很多第三方的Profiler工具也会提供出来。比如商店里面可能有一些性能优化的插件，第三方工具的好处在什么地方？首先第三方工具相当于是针对我们的游戏开发者进行开发的，所以使用方面还有数据可读性方面，比一般的工具强一些的。但是也不是没有问题，因为很多第三方的工具开发商，之前可能也是Unity引擎的使用者，他可能对引擎底层的技术不是很了解。那么功能的一些更新可能很滞后，并不一定兼容最新Unity的版本，还有数据解读有一些误解，可能误导我们对这个数据的理解。

这个是我们在平常现有一些Profiler工具会产生的一些缺点，当然严格来说我们UPA是一个第三方的工具，但是我们和Unity合作所以可以避免一些第三方工具出现的一些典型的问题。这个合作还有一个比较重要的一点，其实我们是除了工具的可用性以外，其实我们想做一些数据分析以及整理，也就是说我们把Unity和腾讯在性能优化过程中积累的经验还有数据标准共享给大家，帮助大家比较快速的发现我们这个游戏到底哪个方面存在性能问题，并且可以方便的优化它，这是这个产品，相当于一些特点或者它想针对的目标。

有了这个产品之后大家可能就会想到这个产品应该怎么用？在平时的开发或者测试过程中应该怎么用这个产品才能更大化的发挥它的效果。其实这个产品我们在平时的推广过程中也积累了一些使用场景，可以跟大家分享一下。首先第一个是数据采集者和数据分析者，其实对于这个产品来说我们数据采集的人员和数据分析的人员可以不是同一个人，我们知道之前的Profiler工具可能都是，我那些做性能优化的同学自己用，自己采集数据看这个数据然后优化这个问题。

那么有了这个UPA的工具以后，其实这个角色可以分两个部分。首先第一部分是我们的数据采集人员，这个可以交给我们的外包或者测试同学来做，剩下的开发人员做功能就好，等到他们跑完了我们指定的场景或者指定的机型数据以后，可以把我们采集的数据或者生成的报告拿到专门负责性能优化的同学那边，其实省了我们平常可能是一些问题或者是采集数据的时间。这是第一点。

第二点因为我们报告采集以后是存在云端的，所以这个报告可以进行任意应该的分享。比如我们可以分享给我认识的一个比较厉害的大牛，我可以请他给我看一下这个报告有没有问题？如果这个问题我解决不了的话。可以分享我们Unity的专家，请他们看一下这个报告减少我分析报告的成本。当然分享给专家以后如果我们有采购Unity的驻场支持，他们在驻场的时候可以看一下报告减少他们的驻场时间。

还有应用比较多的场景，我之前已经发现类似的问题并且已经进行优化，这个时候看一下优化效果怎样，这个问题有没有被真正的解决，这个时候可以跟我之前没有进行优化的报告进行对比。那么两边的数据对比以后我可以很明显的发现，这个数据是不是恢复正常？这个代表我之前做的优化效果是不是有效。

最后一个也是我们最近在推广过程中碰到的一些项目的使用，项目组使用这个工具做自动化测试的工作，为什么做这个？因为自动化测试应用面比较小，因为如果是做功能的自动化，那么这些自动化过程中出现的问题可能我并不一定能够自动化的发现。如果自动化跑一个游戏中间突然花屏，有一些角色的渲染不太正常，或者有些文本显示不对，这个时候很难通过自动化的方式来发现，我跑自动化的时候可能还需要人来盯着这个东西。看一下这个跑的过程中有没有问题。

那么这样的话自动化测试的效率其实很低，当然我们刚才说是功能自动化，如果做性能自动化的测试的话，之前大家可能采集一些帧率或者内存这种指标。那么虽然有了这些指标，自动化测试可以帮助我发现一些问题，但是自动化工作能够做的工作到此为止，接下去我们又回到之前的数据优化的这么一个老套路。有了这种性能采集的工具以后，如果结合自动化的测试我们可以在每次自动化的时候，采集一些性能数据。然后通过测试结果的对比我们可以发现一些潜在的性能问题。

比如说一个函数它的时间可能每个版本都会增加10%或者5%，虽然可能一两个版本看不出来问题，但是等真正上线的时候这个问题已经成为一个问题，到时候我们再花时间进行优化，那么效率就会比较低，所以我们自动化测试的时候，提前帮助我们发现一些问题。

这是我们使用UPA的场景，说到这里大家已经对这个工具有一点好奇了，这个工具到底什么样的？能达到什么效果？或者能够帮助我们解决什么问题？下面我们请Unity的支持工程师高川同学帮助我们详细的演示一下这个工具的使用方法还有典型的使用案例。

Unity大中华区企业支持经理&UPA开发工程师 高川先生

我们可以看到有几项，一般来讲就是第一项，我们选择UPA，进入之后进这样一个界面，这个界面里面我们可以看到有这样几个选项，第一我们要求用户选择一下你们测试哪个Application，然后下面有三个选择，第一个是性能分析，后面是资源分析和MONO内存分析，报告所属你可以对报告进行分组，Unity版本，我们会有5.6以上和5.6以下版本，截图这个让用户理解你测试过程中究竟发生了什么。为什么做成开关？因为我们知道有些公司对于项目的截图比较敏感，所以这个截图是关闭的，如果有需要一定打开，这个对于你自己或者你的朋友或者其他的专家来阅读和解析整个报告是非常重要的。

你选择所有的东西之后点开始测试，你的Application拉起来，你可以玩游戏一样开始你的测试，测试时长没有限制，我们一会儿可以看一下我们的案例测试。这是我们的Demo报告，这是用Unity的AngryBots做的测试，上面有一个报告是合格还是不合格还是警告，同时收集一些Application信息，你的CPU性能情况，使用什么手机测试，基于腾讯后台大数据我们对手机进行分类，属于高配中配低配。然后下面是一堆列表，大家比较关注帧率、MONO的内存、纹理、网格，包括Tris在这里有一目了然的展示，我们也会用颜色来区分。这些报告，由于大部分人对自己的游戏很了解，看这儿可能结束了，因为所有的问题列这儿，你可能不需要放其他的数据或者再分析，可能有时候这个地方发现一些非常直接的问题，然后开始着手解决。

再下面是我们建议的这样一个关注点，包括一些模块的耗时这样一个排列，这是概况页，然后下面我们对CPU内存图形渲染三个方面进行分析。大家比较关心CPU使用情况，如果看截图非常清晰的知道这一帧在干什么。所以会有比较清晰的对比。最上面是我们的性能的摘要报告，包括你的耗时的平均，以及物理的耗时平均。再下面我们看到这是一个主的TimeLine，这个上面是采集每一帧的数据的采样点，我们可以针对某一帧进行放大，这一帧里面可以看到整个耗时，Rendering耗时非常凸显，我们可以一帧一帧的展开，看一下每个函数的耗时是什么。

再下面是我们的建议，虽然这里比较凸显，但是整体没有太大，我们Unity的Demo优化很棒，这真的没有太大问题，我们一会儿可以看到相对优化不那么好的项目。再下面是对于对象激活统计，大家知道Unity里面这两个操作是非常耗时的操作，每次都有树的传递，你的脚本有操作，这个传递非常慢，尤其是UI。比如人物头顶的billboard，我们在有的项目里面就会看到这个耗时是非常凸显的状况。我们和项目的优化过程中我们经常看到，有一些非常集中的实例化会导致卡顿，一会儿我们的案例也有相关的内容。下面我们会看到有一个内存方面的报告。

这是内存的报告，首先我们可以看到Mono，在这里有非常频繁的产生，一会儿案例中会看到非常明显的内存使用的问题。然后是动画、音频、材质、网络的细分展示，在图形里面我们关注关注Draw Calls，再下面是Verts和Triangles，它加载某一些模型的时候加载策略不合适，所以把无用的模型统统加载进来。再下面是VRAM的值，这个值是一个估算值，所以给大家做一个参考，再下面是VBO的统计，以及这一帧里面更加详细的数据使用。

还有一个模块是我们的合批模块，我经常被问一个问题，要不要开通静态合批和动态合批，我们知道它对CPU产生一定的压力，或者对内存产生一定的压力，所以我们给的答案是能或者不能，大部分的答案是试试吧，所以我们通过合批想帮助大家解决这个问题。其实这里最重要的是黄色曲线，你通过开启动态合批为你省掉多少，如果这个曲线非常高，说明你的动态合批做的非常好，你可以付出相对比较小的代价获得比较大的收益，但是反之你不应该开它或者进行材质和渲染顺序之间的调整。这个稍后我们也会在案例里面看到一个非常明显的例子。还有我们认为渲染方面非常耗时的，这是大家平时做项目的时候遇到耗时非常尖峰的地方，所以我们提出来让开发者重点关注一下。

下面看一个案例，这个案例是腾讯的真龙霸业，这是早期的版本，我们看上完了是红通通不通过，真龙霸业的同学比较担心，它是在米4测的，它的平均帧率只有10帧，纹理资源是80多兆，峰值已经达到500。我们看一下问题建议，首先FPS均值很低，逻辑脚本高于渲染，这是我们看项目的时候，90%的项目都有这个问题，GC频率9.42次，然后是Canvas，还有就是纹理消耗比较高。我们看一下模块耗时，这个函数比较有意思，一会儿可以重点看一下这个东西应该干什么，它不仅会产生比较高的耗时，同时会产生比较高的GC alloc。

我们看一下GPU，我们看很多项目大多数的曲线是锯齿，在下面不停的抖，这个曲线是游戏平均帧率比较低，而且出现偶尔的卡顿，就是不流畅。但是这种曲线玩家的体验会停顿，所有的红色的曲线玩家感觉非常明显的停顿而不是卡顿。因为用UPA测试的时候版本比较早，所以没有做截图功能，所以打了一个Tag，我们看一下典型意义，比如红通通的，有4帧，第94帧是耗时非常高的一帧，这一帧是在干什么？耗时最高是这个函数，这是你的UI在加载一个滚动列表，你加载一个过大的滚动列表，所以这一帧之内大家可以看到它已经是非常夸张的值。而且这一帧里面仅仅一个函数就400，所以这就是明显的停顿而不是卡顿。

我们再看这个，从名字可以猜出来是第一个场景已经加载，这里有很多加载过程和初始化过程，所以导致这一帧的加载大概400多，这个意味着什么？如果这是一个等待的场景还好，如果这是游戏中的动态加载，玩家会卡将近一秒钟的时间，因为这两个函数卡一秒钟，这是难以忍受的。

所以我们给项目组提的优化，第一个向滚动列表我们需要进行少量加载，可以把时间分开，同时第一次进场景的时候检查是不是某一帧做了过多的事情，导致CPU卡了非常非常多的时间。129帧也是类似的问题，我们可以看到有一个Loading，我们里面又看到了很多的等待这边，它的耗时非常高，这时间开发组开发的时候没有考虑同一帧里面CPU的负担，而简单粗暴同一帧里面把所有的加载任务放一帧里面。这是我们给项目组做优化的时候看到一个通病，因为大家会基于项目时间或者管理成本或者代码，在加载的时间管理和CPU的时间管理做的不是那么细致，所以经常有粗放的大列表加载，一开始这样做没有问题，但是随着项目增长，这个地方的瓶颈会慢慢的凸显出来。所以我们建议他们初期或者中期做规划的地方，对于提前加载的地方布局一些措施，比如进行监控进行表的自动化筛查，以及提早做分帧加载，这些都是经验上的东西。

我们看一下内存，内存非常有意思，可以看一下总内存大概占将近500兆，这个内存已经非常高，我们看一下Mono Reserved，我们可以看一下，前面几帧的内存比较有意思，前面都是红线，这意味着什么？从系统层面来看，系统看到绿色的，绿色过高系统就会回收，这是时简单粗暴的说法。那么红线是你使用的，对于Mono的内存池来讲，你使用内存不够，它分配新的内存拓展内存池，供游戏进一步的使用。我们可以看到前面这个是一个合理的，因为绿色上涨的同时红色也在上涨，这个地方比较有意思，大家可以看到这个地方红色是下降，但是绿色反而上涨，包括后面也是非常大的上涨，这一帧的时候红色有不太大的上涨，但是绿色有非常大的上涨。

我们经常看到非常典型的，第一个就是这样，我们知道Mono顶上去非常难以下来，所以尽量控制尖峰不要顶高，另外是没有突破绿色反而上涨的曲线。Mono是无压缩的内存池，它一直不停的分配，分配大的时候首先找里面有没有可以供你用的。我们可以看到项目里面GC非常多，意味着大量分配小碎片内存，最后导致内存碎片化严重，你分配相对大一些的内存，你的内存池已经没有地方可以分配出这样的内存，所以就申请新的内存。所以这个项目在后期浪费非常严重，大家可以关注一下大概有10兆左右，有10兆内存已经被分配，但是项目根本不会用到。所以大家优化的内存的时候，并不是只考虑我尽量减少分配，同时考虑分配内存的连续性。

所以有一些项目里面建议用户先分配大内存，再分配小内存，先分配大内存使用之后释放掉，然后用大内存的小内存进行碎片。还有一种方式我们Unity这边也在尝试升级Mono的虚拟机，下一代的虚拟机可能比较好的解决内存碎片化的问题。但是还是那句话，再优秀的机制也抵不住乱写的代码，所以开发上要有一定的节制，如果不节制什么机器也抗不住。这个项目比较有意思的就是它的纹理，80多兆的纹理内存，为什么？因为这个东西本身不大，但是它是一个2D游戏，开发组当时为了加载速度问题，把所有的纹理加进来不释放。

从目前它的数据来看这种策略对于他们项目来说有一点危险，因为整体内存非常高，但是并不是把纹理加载进来不释放这个事儿不能做，只是这个项目里面我们觉得不太合适，所以我们建议他们适当的地方去释放一些内存，对于纹理进行一些更细致的加载。同样这个问题也是非常常见的问题，还是由于开发周期以及人员迭代，导致资源和内存管理上非常粗放，到了后期我们发现内存是几何级的增长，我们之前遇到很多用户后期找到我们我有很多很多奇怪的现象，到底是为什么？我们到了现场之后发现七八十是由于内存爆掉了，但是他们不会意识到这个问题，因为他们是在线上，线上抓回来的不会告诉你是内存，所以内存会导致非常挠头的问题。

所以大家进行管理内存的时候，虽然做资源管理内存管理是非常细致的活，它必须贯穿整个项目，但是这样的收益一定是非常大的，千万不要在项目前一个月发现内存抗不住了，然后找美术找GD，据我们接触的项目这样的问题不在少数，这是给开发者一个建议，这是我们做UPA的初衷，帮助大家尽早发现风险，把风险消灭在萌芽状态。

还有一个是图形，大家看上面有两个0，他们不是没开，真开了，但是开了之后这边合不掉什么东西，因为他们的材质非常非常复杂，所以我们的建议要么关掉，要不优化一下你的材质的使用。所以通过这个工具我们可以很好的回答我们之前没法回答的问题，我们要不要开？我们直接告诉开发者你的情况是这样，你自己决定优化或者不开，省掉这部分的CPU消耗。

由于时间关系我们案例先分享这些，如果大家有兴趣的话一会儿交流之后可以到外面的展台来跟我们工程师进一步交流。关于WeTest我们后面做什么东西，我请徐森继续介绍一下。

还有一点就是我们可能也会考虑做一些现在这些市面上Profiler工具没有的功能，现在我们会提供一些快照对比的功能，大家可以尝试一下，最终希望通过UPA这个工具把大家平时在工作过程中积累的经验碰到的问题进行整合分析，帮助大家提高性能优化效率，这会是我们的发展方向。

今天就分享这些，谢谢大家！

若有任何疑问，欢迎在公众号留言给我们或联系WeTest企业QQ：800024531进行问询。

点击http://wetest.qq.com/cube/，WeTest UPA邀您体验。

进入UPA体验页面，认证用户即享UPA - 60分钟使用时间。