UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技 - 性能优化
type: channel
link: https://blog.uwa4d.com/tag/性能优化/
items: ​Live2D 性能优化
items: 如何让你的游戏性能转危为安？
items: 提升市场竞争力，这些细节你都把握了吗？
items: 开展优化工作前，这些你需要熟知！
items: 基于团队的持续优化之道
items: UWA GOT v1.1 | 支持本地管理深度测评、全新的UWA API、兼容Unity 2017.3
items: UWA GOT v1.0.3 | 支持自定义代码段检测、支持数据导出
items: Lua的CPU开销性能优化
items: 【求知探新】《为谁而炼金》UI界面加载性能分析
items: Unity优化百科（UWA 博客目录）

​Live2D 性能优化
type: item
date: 2019-12-17T08:03:00+02:00
description: 随着Live2D在项目研发中被广泛使用，其性能优化的需求已经不容忽视。笔者通过模型资源、Mesh、RenderTexture、Material和CPU耗时这5个方面来阐述优化的过程，并且最终实现了低端机上6个模型30帧的效果，值得大家参考。 优化结果 测试机型：低端机——红米4X 测试样例：同样的6个模型（游戏中同屏最多6个模型） 版本：3.2.05 CPU优化主要在CubismModel.Update、CubismModel.OnRenderObject； 内存优化主要在Texture2D、Mesh、RenderTexture、Material以及Mono内存分配。 接下来介绍从模型资源、Mesh、RenderTexture、Material和CPU耗时5个方面来优化性能。 1、模型资源 项目前期没有制定Live2D美术规范，美术导出文件的时候，直接使用自动布局顶点的方式，而Live2D自动生成Mesh的时候对于每个部件的内外边界各生成一份顶点，发现如下问题： 1、模型Mesh数量太多 2、模型的总顶点数达到6K左右 后续跟美术沟通之后，对Live2D模型（后续的模型都指Live2D模型）的导出规定如下： 1、手动布局顶点 2、ArtMesh数量控制在100以内（之前的模型由于改动的工作量太大，暂时不做修改） 3、模型顶点数控制在2k面以内（游戏最多有6个模型） 4、Edit Texture Altas中贴图大小1024*1024，自动布局且Margin为5px 5、为了避免多贴图导致DrawCall升高，一个模型只使用一张贴图 2小时后，通过Live2D Cubism Editor->File->Model Statistics查看优化结果如下： 性能数据测试结果如下： 2、Mesh 测试发现游戏一个模型的Mesh数量在80-200之间，同屏最多有6个模型，通过UWA GOT测试发现Mesh峰值达到107MB（27380个），Material数量达到10.2MB（14968个），其中Unlit（Instance）数量14563个明显异常。 研究CubismRenderer.cs发现如下问题： 1、运行时创建了两份Mesh内存 2、Mesh资源未销毁，导致内存泄漏 3、顶点色每帧都会重新赋值 针对问题1，经测试发现，改成一份Mesh并没有明显的CPU变化，Mesh内存减少一半，由于每一帧都有顶点变化，_meshFilter.mesh = FrontMesh每帧700次的CPU消耗也可以省去。 针对问题2，可以在OnDestroy中调用Destroy接口销毁Mesh。 针对问题3，使用标记控制是否更新顶点色，减少顶点色赋值的0.5ms左右CPU消耗。 另外值得一提的是，Mesh中使用了顶点色处理透明和颜色变化，但是同一个Mesh的顶点色全部相同，可以想到在Shader中控制颜色，实际上为了动态合批不得不使用顶点色，合批之后控制在10个DrawCall左右，不合批每个模型DrawCall数量达到上百个。 3、RenderTexture CubismMaskTexture.cs中创建的RenderTexture大小默认为1024*1024，项目中遮罩效果大部分使用在眼睛，在实际测试之后有如下优化： 1、将GlobalMaskTexture.asset的Size改成128，实际数值可以根据项目需要修改。 2、CubismMaskTexture.cs中RemoveSource函数加上如下检查，在没有遮罩模型的时候可以释放RenderTexture。 if(Sources.Count == 0) { if(_renderTexture != null) { RenderTexture.ReleaseTemporary(_renderTexture); _renderTexture = null; } } 3、CubismMaskTexture.cs中OnDisable()和RefreshRenderTexture()函数中同样添加释放RT的接口。 4、CubismMaskController.cs做如下修改，避免RenderTexture无法释放，同时避免切换模型且未销毁时CubismMaskCommandBuffer.Lateupdate持续CPU消耗。 修改后： 4、Material 通过UWA GOT测试发现材质数量也达到1w多个，研究发现材质有明显的泄漏问题，解决方案如下： 1、CubismRenderer.cs中Material属性 public Material Material { get { return MeshRenderer.material; } set { MeshRenderer.material = val…

如何让你的游戏性能转危为安？
type: item
date: 2018-11-05T05:18:00+02:00
description: 不知不觉，UWA在游戏性能优化领域耕耘了三年。我们相继推出了三项性能优化产品和服务：UWA驻场深度优化、UWA线上深度性能测评和本地性能测试工具UWA GOT （及其Online服务）。截止到目前，我们已经深度优化了近90款游戏，线上性能测评服务了2000多款游戏、VR和AR项目。 随着优化的项目和拜访的团队越来越多，我们逐渐意识到性能瓶颈不仅是技术层面所致，也来源于开发流程。在游戏项目的精品化和重度化趋势中，任何一个中间环节产生了资源浪费，对最终结果的影响都可能难以预估和弥补。所以，我们推出了UWA性能保障体系，我们认为性能优化不该局限于以前的“头疼医头、脚疼医脚”的救火行为，而应该将其扩展为质量保障体系的一环来保证研发团队更快地发现问题、解决问题，从而加快项目的研发效率。 在介绍UWA性能保障体系之前，我们先来看看项目的性能瓶颈是如何形成的，为什么它会成为多数研发团队的困扰。 项目性能在开发阶段的表现 项目的性能问题并非一开始就产生，也不是某一天突然出现的，而是在研发过程中日积月累的产物。在绝大多数的项目开发流程中，其性能耗时的走势大致如下图所示。 蓝色区域为研发期，一般为游戏立项后的功能开发和堆量阶段。在这一阶段中，功能开发是研发团队的主要目的，很少有团队在这一阶段会关注性能问题，即便是有QA的团队，这一阶段多数也是在测试功能的合理性和正确性，于是性能问题会在这里大量堆积，从0到1，再从1到100。 红色区域为上线测试和优化阶段，现在的项目研发团队多数都集中在这个阶段来进行优化，这时候主要功能已基本开发完成，后续是功能的调整、完善和调优；同时伴随大量玩家的涌入，性能问题被极速放大。卡顿、发热和崩溃问题是这一阶段开发团队和运营团队最为头疼的问题，熬夜、通宵也往往是“家常便饭”。 绿色区域是经过几轮测试和优化后，项目整体性能趋于稳定的状态。一般只要研发团队熬过了红色区域的优化阶段就可以顺利上线公测了。当然，后续也会有新版本的更新、新功能和内容的加入，所以不少项目的性能问题依然会再次涌现，即再经历前面的蓝色和红色区域，依次往复。 以上就是目前绝大多数游戏研发团队正在经历的过程，之所以会出现这种情况，其实是源于目前研发团队多数采用“瀑布流”式的开发习惯，具体如下图所示。 从预案设计，到程序开发、美术开发和玩家测试，根据反馈优化性能和调整方案，直至游戏上线。在项目内容和功能开发的过程中，虽然QA团队会对项目不断测试，但基本上都是围绕功能和数值，针对性能相关的测试寥寥无几。而随着项目的精品化程度要求越来越高、同品类竞争项目的数量越来越多，这种开发方式在性能方面的弊端暴露无疑： 问题一：性能优化时间紧、难度大 在开发流程图中的红色区域，是性能问题暴露的重灾区。这一阶段中，项目团队的制作人、策划和运营团队都在不断催促程序对性能进行优化，以期快速达到流畅的表现效果。原因很直接也很现实：玩家用户不等人。但是，短时间内修复长时间积累的大量性能问题，这其实是非常困难的，甚至可以说是一个悖论：如果研发团队拥有在短时间内就可以力挽狂澜的技术实力，那么在之前的开发过程中，也不会留下大量的性能缺口。 问题二：研发时间更长 研发团队在蓝色区域开发时，会习惯性地将问题（特别是性能问题）的解决后置，希望在后续的测试和优化阶段中集中处理，这是因为除了保证功能的研发效率之外，不少研发团队潜意识中对问题的解决持有这样的态度：同样一个问题，现在还是以后修复其实工作量都一样。这里我们想借用Scrum之父Jeff Sutherland在《SCRUM：用一半的时间做两倍的事》这本书的原话，他非常强调“问题一旦发现就立刻解决”的重要性： “几年前我在加州曾和Palm公司的开发人员聊过天。他们开发出最早一批被大家认为“个人数字助理”的产品，即现在的通讯设备。当时他们自动把工作中做过的每件事都一一加以记录。他们记录的其中一件事是，解决程序Bug要花费的时间，也就是软件开发人员在开发自己的程序导致系统出问题时，得花多久的时间解决。每一次电脑都会自动追踪这件事。 现在假设某天测试人员在试图把Matt（一位研发人员）的程序整合到系统时，却侦测到了缺陷。Matt和大多数程序开发人员一样，都不想马上回头把程序改好，而是答应事后会修改，接着就继续写新的程序去了。 在大多数企业里，这样的测试动作甚至不会在写出程序的同一天进行，可能是等到程序写出来几周、几个月后才进行测试，问题都是到了那个时候才被发现。但是，Palm公司每天都针对所有程序都进行自动测试，因此一有问题就会立刻察觉。 测试人员检测全公司每一位“Matt”们，亦即数百名开发人员，并分析马上修改程序所花费的时间，和数周后才修复程序所花费的时间有何不同。不要忘了，软件是一种颇为复杂、牵连甚广的产物，你觉得上述两种改正的方式所花费的时间会…

提升市场竞争力，这些细节你都把握了吗？
type: item
date: 2018-10-24T10:20:00+03:00
description: 优化工作向来是个复杂系统的工程，且不说前期的框架预设、大量的版本迭代、美术和性能的需求平衡，单从每个版本的上万帧测试数据中定位真正的性能瓶颈，其工作量就已可想而知。 无论项目是否复杂或简单，当我们开展优化工作前，这些问题都需在胸中有丘壑。那么如何井然有序地定位和排查性能问题呢？我们定位到了性能的真正瓶颈了吗？今天小编以一个优化前期的MOBA手游的UWA性能测评报告为例，深入分析该项目在真机上的运行情况，并讲解如何通过报告中的功能模块更高效地定位性能瓶颈，希望能对大家的项目有所参考。 一、关于性能简报 在这次优化讲解的时候，我们将从报告的“性能简报”模块入手（每个项目性能报告的首页），该模块作为UWA性能评测报告中的一大模块，将引擎性能模块的数据更有序、更核心地汇总成一个完整的优化体系，建议大家在优化项目之初先仔细参阅该模块的数据。点击这里可以快速了解UWA性能简报。 在性能简报的第一个模块，可以直观查看到最近测试的项目报告中的重要参数、其优化效果和性能变化趋势。 从性能排名的模块中，我们提供了测评项目在国内数千款测评项目中，同设备和同类型的横向排名，从而帮助大家更客观地发现项目中的优势和不足。 引擎模块的性能排名 内存模块的性能排名 UWA解读：该项目在CPU模块和内存上均有大量的提升空间。CPU模块的压力主要来自于引擎的渲染和UI，物理、粒子和动画，逻辑代码较为严峻。内存模块中各个资源的占用内存普遍都较高，Mono堆内存分配也较大。 在性能简报的最下方，是UWA针对本次性能提测所提供的分析与建议，在这里将所有引起以上参数开销的性能问题逐一列出，并通过精准的页面链接跳转定位到问题源头，协助开发者进行有效地排查。其中，标红部分的问题较为明显，建议研发团队优先处理。 优化任务队列是我们提供给用户的性能优化切入点，下面我们将逐一分析上图中罗列的问题。 二、优化队列详剖析之内存篇 2.1 内存占用 本次报告的内存占用峰值为660.3MB，高于行业同类型同设备，当前行业均值为305MB，因此需要研发团队密切关注。特别的，如果要保证在一些1GB内存的设备比如iPhone 6或6 Plus上不闪退，我们建议尽量不要超过280MB。 内存的主要构成来自资源内存和Mono堆内存，在此我们做下详细分析。 2.1.1 资源内存之纹理 （内存超标） 排查方向： 1） 纹理的分辨率、格式 如性能简报中显示，RGBA32和ARGB32都不是Android原生支持的格式，不但内存占用较大，且加载效率也低下，建议尝试转成ETC1等硬件支持的格式。如果效果不满意也可以尝试通过Dither算法，对某些高精度的纹理进行处理，转成RGBA4444或RGB565格式，以降低内存占用。 补充说明：在图表中我们也看到不少N/A资源：一般是new出来没有命名的纹理资源，建议在这些纹理new出来之后，给.name赋值，以方便进行纹理资源管理。 2）在查看纹理的具体使用情况时，我们同时发现其冗余情况较为严重。下图为按峰值倒序排序的资源列表截图，可以看到数量峰值大于1的纹理有100多个，当两张纹理的名字、尺寸、格式等属性都相同，UWA就会将其视为具有高风险冗余的资源。 关于冗余的排查优化方法： a) 检查AssetBundle（即打包的时候就有冗余）中是否有冗余，该问题可通过AseetBundle资源检测服务来定位； b) 检查AssetBundle重复加载情况，是否有AseetBundle反复加载导致的缓存漏洞。 2.1.2 资源内存之网格 （内存超标） 排查方向： 1）表格中顶点数大于5000的属于超大网格，需要进一步排查是否有必要。 按Vertex数量进行排序，可以看到第一页的网格顶点数都在1w左右，这个会造成一定程度的内存压力。 2）上图中也可发现，大量网格含有Tangent属性，Tangent属性一般为导入引擎时生成，会增大网格的内存占用，如果实际上不需要Tangent属性，可在Inspector面板中修改设置，关闭Tangent导入选项。 列表中显示Tangent数量为-1的网格，表示Read/Write选项被关闭了，所以统计不到。在此，UWA建议研发团队提交一个临时的打开该选项的版本，来检查网格的属性是否合理。 3）存在冗余的问题，解决方法同纹理 另外，我们在排查资源清单的时候发现了大量的内置资源，在这里提醒大家关于内置资源的处理方法可参考这篇文档：零冗余解决方案（其他类型的资源可借鉴） 2.1.3 动画资源（内存超标） 根据性能简报的提示页面转到动画文件的使用信息列表，如下图所示： 对于大于200KB且时长较短的动画资源，UWA认为可以进一步排查。这里看到资源列表按照内存占用排序，前3页内存占用大小都超过了200KB，建议使用一些精度处理的方法来进行优化：通过降低…

开展优化工作前，这些你需要熟知！
type: item
date: 2018-07-12T06:40:00+03:00
description: 当项目进入优化阶段时，我该如何根据项目的实际情况安排优化工作的进度？针对每个模块的优化做哪些工作才最高效呢？怎样的排查才算全面到位，是否还有一些我们平时忽视却很致命的优化细节呢？今天，UWA就推荐一个可以快速掌握上手的“分析框架”，帮助大家更有章法地开展优化工作。 我们结合了UWA性能测评报告中的“性能简报”功能，梳理了研发团队需要关注的各个引擎模块，以及针对各个引擎模块大家可以着手排查的维度，简化示意图如下所示： 细看在这个分析框架图，我们不难发现，在实际优化过程中不仅要从宏观上分析项目运行时的整体趋势，包括总体CPU性能、引擎各模块性能等，也需要从微观上深入剖析运行时的代码堆栈、资源管理等情况，以确保百密无一疏。 我们以渲染模块的优化为例做解释说明，上图中显示可以从以下两方面入手： 一、分析渲染模块的总体性能 如下图所示，我们需要在UWA测评报告的“渲染模块性能”页面中关注一些重要参数的使用情况，比如DrawCall和Triange的峰值、半透明渲染和不透明渲染的使用趋势等。 二、查看Camera.Render函数的代码堆栈 Camera.Render的代码堆栈中包含了大部分渲染相关的函数操作，通过总体堆栈信息、指定场景堆栈信息、指定帧堆栈信息，配合运行截图，研发团队能更全面、更精准地定位性能瓶颈。 看到这里你也许有了新的疑问，UWA提供的分析框架图中的信息量太大，并且还伴随着大量繁琐的细节问题的定位，我该怎么快速上手呢？小编建议大家快来解锁“UWA性能简报”! 如上图所示，性能简报就渲染模块中的各个问题分别进行罗列，并建议开发者分别通过以下三个维度去优化： 1）查看Camera.Render代码堆栈 2）减小同屏渲染面片数 3）优化Draw Call数量峰值 再例如，当通过LoadFromFile加载的次数过多时，性能简报不仅明确指出通过该API加载过高的AssetBundle总数，并指引研发团队跳转至对应的分析页面做进一步的排查。 下图为点击蓝色超链接后的跳转页面，详细罗列了通过LoadFromFile加载的AssetBundle的具体使用情况。 目前，UWA分析引擎中的性能规则已经超过1000种，它将引擎性能模块的数据有序地汇总成一个完整的优化体系，通过“分析与建议”中提供的精准优化方案，帮助研发团队达到对症下药的优化效果。 临危不惧，在于胸中自有章法； 高手优化，在于胸中自有UWA！ 解锁更多UWA性能测评功能，请戳：https://www.uwa4d.com/#feature UWA合作案例 关于UWA 由侑虎科技开发的游戏/VR应用性能优化平台，目前提供 1）性能诊断与优化 2）资源检测与分析 3）UWA GOT 三大工具，帮助开发者在短时间内大幅度提升性能表现；同时其搭建的知识分享的博客和答疑解惑的互动平台使广大开发者收益，UWA以实力和态度诠释对性能优化的定义：问题的答案永远“在现场”，解决你的性能问题，才叫“优化”。

基于团队的持续优化之道
type: item
date: 2018-05-18T12:55:00+03:00
description: 四月份的博客也欠下了，大部分业余的时间花在准备UWA DAY 2018的分享上面。当时也说了，做这次分享也算实现了我去年的一个“小愿望”，借这个机会认识了不少做技术的朋友。回到杭州之后，也有不少人跟我要PPT，讨论一些分享中的细节。在准备分享的时候，因为时间关系，也将一些计划扩展开的内容删除掉了。所以这次想再根据准备时候的逐字稿整理一篇博客，以作记录，也为没有参加UWA DAY 2018的朋友提供参考。 所以这篇博客的主题还是以这次分享的核心内容为主线，顺便把PPT的内容也提供出来（以引用块或者(补)的方式标注，以方便听过分享的朋友阅读）。 题目和提纲 这次分享的题目是《Connecting The Dots——基于团队的持续优化之道》。优化是一件琐碎而又繁复的事情，它通常是一个又一个的点，而我们如果要让一个比如说30人甚至50人的大型团队，花1到2年的时间去开发一款大型的手游项目，不但需要了解和掌握这些优化的细节，而且要借助团队的力量在整个游戏开发的生命周期过程中不断地进行持续优化，才能够让优化效果可以保持下去。 在聊具体的分享内容之前，我想先抛出这样一个问题——在优化这样的过程中，程序应该承担一个什么样的角色？ 这也是和我刚才所想要聊的持续优化关联性非常大的问题。在优化过程中，程序可能有两种角色，一种是像救火员这样的角色，哪里冒火了，就去扑灭它。我自己也有过作为救火员去做优化的经历。另外一种工作方式是像园丁一样，可能不需要特别紧急地在最后关头才处理那些性能问题，而是从项目的初期就开始规划整个项目的性能指标，然后让整个团队可以按照指标的要求合理地产出美术资源、编写代码，从而让整个产品一直处于一个比较健康的状态。 救火员的职责很有挑战性，同时也比较容易做出成就感，比如我也有过用1到2周时间让游戏的性能有非常大提升的经历。而园丁在做的事情可能看上去比较普通，都是些日常且琐碎的事情。在游戏开发中，这两种角色并不冲突，而是同时存在的。但是在我的理解里，对于性能更友好的状态，是让团队里的成员都在以一个园丁的角色在工作，从根本上来保持游戏的性能一直处于一个较好的状态。因为——每一个神级优化的背后，都隐藏着一个2B的bug！ 那这次分享我就想从这样三个方面来聊一下我所理解的以“园丁”的角色来让团队进行继续优化的方式。 首先是美术资源的优化，美术资源是一个会对客户端运行效率产生非常重要影响元素之一，我想和大家聊一下，怎么样让我们团队可以在美术资源产出方面一直保持一个比较好的状态。然后我想回归到程序的本职工作，从一个更加宏观的角度来讨论一下程序代码的部分要怎么样去做一些优化，对于代码质量和一些底层模块的设计，如何去做一些提前的思考和设计。第三部分，团队开发效率的优化，这块可能看上去跟性能优化的题主没有直接的关系，但是在我看来优化不仅仅是游戏运行效率优化，而且应该包括整个团队开发效率的优化，这也是在项目开发过程中非常重要的部分。 1.美术资源优化 首先来看一下美术资源优化的部分。 大家在日常开发中可以感受到，对于美术资源部分，美术和程序，尤其是要进行性能优化的程序，他们的关注点会有不同。美术更多的是关注美术效果是不是足够的好，而程序可能更多的关注美术资源在设备上的运行效率是否可以达到目标帧率，这其中就有一些目标导向上的冲突。我认为，解决这一冲突的一个非常重要的手段是尽早来建立合理的美术资源制作规范。 这其实是一个美术资源制作的过程，首先通过在立项时制作Demo来确定适合的美术资源规范，然后通过给美术灌输效率意识、提供辅助工具让美术在制作资源的过程中可以严格按照规范进行，最后是要借助QA的力量对产出的资源进行检查，确保达标。 1.1 规范制定 为什么制定美术规范这么重要呢？我想借自己之前的一个项目中的真实经历来聊一下。 《无尽战区·觉醒》这款手游是我作为主程带领团队开发的第一款手游项目。当这个项目进行到中期的时候，收包了一批场景的资源。在使用这些资源的时候发现它们的运行效率明显偏低，Profile发现面数和DrawCall都超标了。面数很简单，使用减面工具进行减面即可，DrawCall也使用类似Unity的Static Batching的方式进行优化，但是结果发现一些场景的DrawCall只能从400减少到300多，并不能达到预期。仔细检查发现很多模型无法合并的原因是使用了端游常用的一种贴图制作方法——四方连续的贴图。这种方式虽然可以使用很小的贴图尺寸通过tiling制作出精细的效果，但是对于DrawCall敏感的手游来说并不合适。最终项目又请了好几个外派美术进行资源的整合和制作，导致多花费了几个周时间和几十万的美术成本。虽然对于大公司来说几十万的美术成本不算什么，但是我依然觉得这是我作为一个主程的失职——因为没有提前和美术沟通好制作方法，导致了…

UWA GOT v1.1 | 支持本地管理深度测评、全新的UWA API、兼容Unity 2017.3
type: item
date: 2018-01-25T03:56:00+02:00
description: UWA GOT是UWA研发的本地性能优化工具，自推出以来，收到了大量游戏开发团队的关注和反馈。今天推出的UWA GOT新版本兼容了Unity 2017.3、添加了全新的UWA API、还支持在Unity Editor下直接上传项目进行在线深度评测的功能，在不断完善功能的同时，我们也希望能给大家带来更友好的操作体验。 一、Editor下直接上传项目 相较于UWA GOT的本地测试，UWA性能诊断与优化是UWA提供的在线性能评测模式，它能提供更丰富的数据检测和更深度的性能分析。在最新的UWA GOT中，用户可以直接在Editor中将项目的测试包提交到UWA官网（www.uwa4d.com），并在本地浏览器内查看报告内容。 具体操作流程如下： 1）通过UWA GOT菜单中的OnlineSubmit即可打开登录界面： 2）登陆后即会显示账号的项目列表以及各个项目的当前状态，所有项目按照是否为管理员权限进行了分组。 3）在拥有管理员权限的项目列表中，点击某项目后即可进入以下的项目提交界面。 4）在该界面上选择机型、上传安装包、填写测试要求以及验证码后，即可进行项目提交。同时，登录UWA官网也可查询到项目目前的测试情况，并且在24小时内即可得到深度的性能分析报告。 5）点击“Done”，即可在本地浏览器查看报告。 二、全新的UWA API 在最新版本的UWA GOT中，我们添加了新的UWA API，研发团队可完全通过脚本控制测试流程。对于VR游戏或应用，可尝试自定义UI按钮来控制测试的开启和关闭。 UWAEngine.StaticInit public static void StaticInit(); 该函数可用于：通过脚本动态挂载UWA_Android，而不需要提前手动将UWA_Android的Prefab放入场景。 UWAEngine.Start public static void Start(Mode mode) 该函数可用于：通过脚本动态开启指定类型的测试，而不需要手动点击右上角的UI按钮。 UWAEngine.Stop public static void Stop() 该函数可用于：通过脚本动态关闭当前的测试，而不需要手动点击Stop按钮。 说明： 1）目前所有的UWA API（包括之前的UWAEngine.Push/PopSample）都添加了条件编译：[Conditional("ENABLE_PROFILER")]。因此，当发布为非Development版本时，UWA API不会参与编译，从而对运行效率无任何影响。 2）UWAEngine.Start/Stop在一次游戏运行中只有第一次调用会生效，无法反复使用。 三、其他更新 1）新版本针对Unity 2017.3做了兼容方面的优化。 2）由于目前UWA GOT暂不支持IL2CPP，该版本在SDK集成界面中增加了当前Script Backend的提示，并支持一键切换到Mono版本。（在此特别感谢用户Ellan为我们提出的宝贵建议） 以上即为最新版本的UWA GOT功能介绍，小编建议大家及时在官网下载最新版本，以体验更完整的功能。 关于UWA GOT UWA GOT 全称 Game Optimization Toolkit，是由侑虎科技研发的本地性能测评工具。它既能方便研发团队在本地直接进行真机测试，也支持在Unity Editor中搭建本地服务器来接收和分析性能数据。整个测试过程中，研发团队能自定义测试时间和流程，几分钟后即可查看性能数据，同时还提供深度的数据分析，如脚本中的主要函数耗时、堆内存的具体分配堆栈等高级分析功能，从此为大家的项目性能又增添一份安全堡垒！ UWA GOT 目前提供 Performance Overview、Mono Memory Analysis 和 Runtime Asset Tracker三大功能。 关于UWA GOT更多功能请查看：搞定这些问题，一个插件就够了！

UWA GOT v1.0.3 | 支持自定义代码段检测、支持数据导出
type: item
date: 2017-09-19T12:32:00+03:00
description: UWA GOT是UWA研发的本地性能优化工具，自推出以来，收到了不少游戏开发团队的关注和反馈，感谢大家的支持，目前我们也一直在对该工具的新功能进行紧锣密鼓地更新中。在最新的UWA GOT中，我们不仅提升本地服务器的数据导入速度，降低内存占用，还增加了两大实用的功能： 支持UWA API，用于检测自定义代码段CPU耗时 支持导出CSV文件 一、支持UWA API 为了更快速地定位CPU的瓶颈所在，新版本中提供了UWA API，能够帮助开发人员统计自定义代码段CPU耗时，该功能仅在Overview模式下起效。API的具体含义及用法如下： UWAEngine.PushSample/PopSample public static void PushSample(string sampleName); public static void PopSample(); 参数sampleName表示自定义的函数标签，UWA Engine会对PushSample和PopSample之间的代码段统计CPU开销，并在UWA GOT中的统计面板中进行显示，该API支持嵌套调用。其具体用法如下： UWAEngine.PushSample(“MyCode”); // some code … UWAEngine.PopSample(); 最终在Overview界面中，可以看到自定义的函数标签，及其具体耗时（下图中A~E都是自定义函数标签）。 注意事项：请确保PushSample和PopSample是成对使用的。如果两者之间使用了return语句提前退出代码段（或者在协程中使用yield return提前跳出代码段），则会造成PushSample和PopSample的配对不准确，从而导致数据错误。 另外，请注意在同一帧中PushSample和PopSample的调用次数不宜过多。初步统计，在中低端的设备上，10000次的调用会导致接近50ms的额外开销。 二、支持CSV文件导出 为了方便用户进行数据的二次统计和处理，新版本的UWA GOT中提供了数据的CSV导出功能，可以导出当前面板中的显示数据。 在任意模式下，界面的最下方可以看到一个“Save as CSV”的按钮，如下图所示： 以下是上图中Shader资源的一个导出示例。生成的CSV格式如下，其中的Depth表示在面板中的层级次序，在Mono和Overview模式下可用于还原函数的调用关系。 以上即为最新版本的UWA GOT功能介绍，小编建议大家及时在官网下载最新版本，以体验更完整的功能。 https://www.uwa4d.com/index.html#download 关于UWA GOT UWA GOT 全称 Game Optimization Toolkit，是由侑虎科技研发的本地性能测评工具。它既能方便研发团队在本地直接进行真机测试，也支持在Unity Editor中搭建本地服务器来接收和分析性能数据。整个测试过程中，研发团队能自定义测试时间和流程，几分钟后即可查看性能数据，同时还提供深度的数据分析，如脚本中的主要函数耗时、堆内存的具体分配堆栈等高级分析功能，从此为大家的项目性能又增添一份安全堡垒！ UWA GOT 目前提供 Performance Overview、Mono Memory Analysis 和 Runtime Asset Tracker三大功能。 关于UWA GOT更多功能请查看：搞定这些问题，一个插件就够了！

Lua的CPU开销性能优化
type: item
date: 2017-09-14T04:43:00+03:00
description: 这是一篇着重介绍如何写好Lua代码，并做好优化工作的技术文章。文中笔者并没有介绍那些通俗的优化方法，而是首先总结了自己在优化过程中常见的性能问题，并通过实际优化案例的分析，来为大家提供更为实在的参考。 大家好，我是舒航，现任职于心动网络，主要负责《仙境传说RO：守护永恒的爱》（以下简称“RO”）的优化工作。今天主要想和大家分享一下，我这段时间在优化Lua的CPU性能方面的一些经验。 上一篇文章主要讲的是写一个LuaProfiler的思路，即如何快速定位到内存和CPU问题。而这一篇则着重于介绍如何写好Lua代码，以及优化的一些经验。在我优化RO和隔壁项目组手游的CPU性能时，发现CPU性能问题非常个性化，两个项目遇到的问题截然不同。而通用的Lua性能优化的Tips，往往并不能解决问题。所以这篇文章的前半部分是我总结的优化过程中常见的性能问题，后半部分是实际优化案例的一个分析，希望这样的形式更能帮到大家。 常见优化 首先需要说明的是，在我们项目中用的是Lua5.3，并且没有用到LuaJIT。 常见优化主要是参考了Lua作者Roberto Ierusalimschy所写的Lua性能优化建议： https://www.lua.org/gems/sample.pdf 一、使用局部变量 这个点是绝大部分Lua性能问题产生的原因，尤其是和一个频繁调用的函数组合，会产生大量的开销。总的来说，我们在一个频繁调用的函数内，应该避免重复地去查询Table，应该把Table内我们常用的值缓存起来。 这里的值通常有两种: 1）函数 2）对象 虽然Lua是first-class，但是我发现实际使用中，大家意识上还是认为函数有别于其他值。所以分开来列举，方便大家对号入座。 使用局部变量是优化Lua性能的一条重要准则。 不管是函数还是对象，不管是Lua自身的库，还是我们自己写的，在Lua中都是储存在_G中的某个节点下。当我们调用一个函数/对象的时候，Lua首先会去他们的表中查找到这个函数/对象，而我们使用局部变量的话，由于Lua的局部变量是储存在寄存器(这里的寄存器不对应CPU的寄存器)内的，所以这个访问就会快很多。更严重的是，如果使用的是父类的函数/对象，还会触发__index，这样不仅会有额外的耗时还有内存开销。 对于不熟悉Lua的开发者来说，容易忽视局部变量的使用，而有些时候这会造成比较严重的性能问题。比较常见的就是写UI的同学在一个定时器或者一个循环内，使用GetComponent来获取组件然后进行一些操作。由于没有用变量缓存起来，每次用完了就抛弃，再用再获取。这不仅会造成很大的耗时，还会造成很大的内存开销，而写UI的工作又容易被大家所忽视，所以目前为止，我发现大部分项目这一块都有优化的空间。 这里提供了一段缓存Lua函数的代码(摘自Roberto原文): function memoize(f) local mem = {} setmetatable(mem, { __mode = "kv" }) return function(x) local r = mem[x] if r == nil then r = f(x) mem[x] = r end return r end end 二、使用对象池 现在大部分团队，在使用Lua的时候，一般只用来写一些UI界面。而UI界面经常交给项目组的新人来做，以熟悉项目代码，所以这里的性能问题很容易被大家所忽视。这里经常遇到的性能问题一般出现在复杂滚动列表的重用、消息协议的重用、以及C#对象的重用中。 在我帮隔壁项目组优化性能的时候，就发现一个有趣的现象。他们项目Lua使用的不重度，但是平均每帧分配内存3.4KB，而RO高峰时期的内存分配也只有0.5KB，是RO的17倍。每帧Lua耗时在0.47ms，是RO的20%-30%。总体来说，对于普通使用Lua的团队来说这里面已经有很大的性能问题了，只是总量比较少，影响不是那么大。 而造成这么大性能问题的原因只有两个，一个是在一个定时器内频繁地给GameObject设位置，一个是每隔几帧收发一条移动消息。最后优化成，设位置时避免了重复创建LuaVector3，移动消息做了个简单的对象池。 优化了这两条以后，不管是每帧分配内存，还是CPU耗时都降低了50%。而在所有的项目中，除了使用局部变量，其他优化中最显著的就是使用对象池了。因为正确地使用对象池能有效地减少创建新对象的过程，在Lua中也就是newindex这个函数的耗时明显减少。newindex减少了以后，不仅避免了频繁开辟回收内存，还能避免额外的CPU开销。尤其是使用对象池缓存一个经常复用的对象时，这样的优化更明显，比如说LuaVector3、GameObject、滚动列表中的对象。 三、字符串拼接使用table.con…

【求知探新】《为谁而炼金》UI界面加载性能分析
type: item
date: 2017-08-24T05:36:00+03:00
description: 【求知探新】是UWA新推出的栏目。在UWA团队做性能优化的过程中，常常会遇到一些未知的问题，在这里我们将分享UWA研究这些问题的完整过程。当然需要说明的是，一个好的问题没有标准的答案，在此也欢迎大家来积极拍砖！ 今天分享的内容，来自UWA对DeNA《为谁而炼金》手游的UI界面加载性能分析。 一、问题描述 研发团队反馈部分UI界面的交互反应速度较慢，具体操作如下图：点击主页面（左图）的“英灵”按钮，UI界面会进入过渡界面（中图），最终进入“英灵”界面（右图），整个过程中打开速度较慢，大约4秒钟。 二、问题复现 我们在红米Note2（低端）和三星S6（中高端）设备上分别进行了尝试，点击该按钮后，UI界面出现确实较慢（4秒钟左右）。 三、问题分析 我们首先通过Profiler来进行测试，下图为红米Note2设备上的性能分析。我们发现，在点击“英灵”按钮后，UI开启过程中主要经过两个阶段：红框部分为资源加载期，蓝框部分为UI界面加载期。可以看到，虽然都是Loading.UpdatePreloading函数在加载，但其每帧的开销均很小，在蓝框期间，游戏的总耗时更是小于33ms。这说明研发团队对于此处的UI界面加载为异步加载。 上图为资源加载期的CPU耗时，下图为UI界面加载期的CPU耗时 对此，我们的建议如下： （1） 加载切换由于是异步加载，且每帧的CPU利用率过低，因此，建议研发团队对特定UI尝试同步加载来减少UI的切换时间； （2） 同步加载可能会造成切换界面运行得“不流畅”，对此，研发团队也可以考虑加大每帧异步加载的资源数量，从而减少红框和蓝框处的等待时间。 同时，我们在UWA性能报告中发现了每次点击UI后，均有规律性的单帧高开销（Profiler中存在耗时卡顿，但未发现该具体耗时项，我们推测是Profiler统计时出现了跳帧问题），如下图红框所示。经过定位，其52%的开销来自于Resources.UnloadUnusedAssets API，如下图性能堆栈中的GarbageCollectAssetsProfiler所示。对此，建议研发团队尽可能避免频繁的Resources.UnloadUnusedAssets，根据资源用量每5~10分钟调用一次即可。 四、结论 该UI界面加载耗时较大主要有两方面组成： （1）大量资源的异步加载，导致每帧CPU利用率较低； （2）Resources.UnloadUnusedAssets API的不合理调用。 对此，建议研发团队根据第三节中的详细说明进行进一步地检测和完善。 文末，感谢DeNA对于UWA团队的认可，并同意将以上研究过程中的性能数据在此分享。同时，我们也欢迎大家在UWA问答社区（answer.uwa4d.com）积极提交研发过程中遇到的问题。也许随着时间的流逝，科技的进步，答案将变得廉价，但问题会变得更有价值，因为提问和研究将比回答更有力量。 PS：《为谁而炼金》是一款富有壮大的故事情节以及高度的战略性的RPG战棋游戏，喜欢这款手游的童鞋们可以在官方网站上预约啦：http://fwg.mobage.cn/

Unity优化百科（UWA 博客目录）
type: item
date: 2017-08-09T18:01:00+03:00
description: Hello, 各位Unity开发者，无论您是正用着UWA的工具、还是阅读着UWA的相关技术文章亦或是在UWA博客中寻找一个问题的解答，我们都倍感荣幸能和你在此相遇。本篇可以说是UWA产品服务的向导，认真读完它，您会了解UWA究竟是做什么的，并且如何利用UWA提供的资源和工具。在与UWA的日益接触中，您会发现它不仅能为你们项目的性能保驾护航，还能少走很多弯路，缩短优化的时间。 Part 1. 优化工具 Q：UWA提供哪些可以快速提升性能的工具？ 这个要从UWA的定义说起，UWA由侑虎科技开发的游戏/VR应用性能优化平台，目前提供 1）线上性能测评 2）UWA GOT 3）UWA GOT Online 三大工具。下面我们将分别介绍。 一、线上性能测评 1、性能检测与优化 通过真人真机对项目测试，提供针对性的性能报告和优化方案，既能从宏观上分析项目运行时的整体趋势，包括总体CPU性能、GC调用频率和引擎各模块性能等，也能从微观上深入剖析内存管理、资源使用以及逻辑代码在运行时的效率瓶颈。研发团队通过对报告提供的方案进行针对性的优化，能在短期内提升项目的运行效率。 入手方法：该服务主要通过在UWA官网上提交项目的测试包（apk、ipa等，无需工程源码）来完成。由UWA工作人员测试分析后，会提供针对该项目的性能报告和分析建议，可以在此参考报告demo。 该工具分为免费版和收费版，免费版一个月可以使用一次。强烈推荐大家来试试免费版哦！ 2、资源检测与分析 反馈资源的打包情况，包括具体包含的资源情况、详细的依赖关系和资源的冗余程度等。用户通过优化报告指出的冗余问题来实现减小包体、减小内存并提升加载速度的目的。 入手指南：用户在UWA官网上传AssetBundle包（无需游戏包），一旦上传，UWA将自动开启检测并返回结果，一般时长在30分钟以内（视AB包体量而定），可以在此参考报告demo。 该工具永久免费使用，无使用次数限制。 二、本地性能测试工具：UWA GOT UWA GOT 全称 Game Optimization Toolkit，是由侑虎科技研发的本地性能测评工具。它既能方便研发团队在本地直接进行真机测试，也支持在Unity Editor中搭建本地服务器来接收和分析性能数据。整个测试过程中，研发团队能自定义测试时间和流程，几分钟后即可查看性能数据，同时还提供深度的数据分析，如脚本中的主要函数耗时、堆内存的具体分配堆栈等高级分析功能，从此为大家的项目性能又增添一份安全堡垒！ 具体功能说明：戳此传送门 入手指南：戳此传送门 价格：RMB399，包括维护和更新 三、UWA GOT Online UWA GOT Online是基于其本地测评模式上的线上同步功能，研发团队可以将本地测评的数据快速同步到UWA官网，生成在线测评报告。除了“本地化”和“快”这两大天然优势，我们目前提供了四大性能检测模式：总体性能检测、Mono堆内存分析、运行时资源检测和Lua性能分析来满足大家的优化需求。 具体功能说明：戳此传送门 入手指南：戳此传送门 Part 2. 干货大全 一、引擎把握篇 性能卡顿、内存泄露、资源冗余...这些开发中遇到的疑难杂症大部分都能在这里找到解决方法，它们无不通过大量的项目深度优化和周而反复的测试验证。如果你想避开一些不必要的坑，请务必啃下这些硬货！ 1.1 Unity性能优化进无止境——CPU篇 从渲染、UI、加载等几个重要维度分析了目前大部分项目中存在的CPU性能问题和解决方案 1.2 Unity性能优化进无止境之内存篇（基础篇） 谈优化必谈内存，该文深入浅出地分析了Unity项目的内存占用 1.3 Unity性能优化进无止境之内存篇（进阶篇） 内存泄露、Mono无效堆内存、资源冗余...你关注的内存问题都在这里！ 1.4 AssetBundle打包机制详解（5.x） （4.x 版本的API接口有所差别，请看这里） 1.5 AssetBundle内存管理机制 AssetBundle真是个绝妙的设计，但是想说爱你不容易！ 1.6 Profiler中常见的高CPU耗时函数 1.7 代码热更新（dll反射） 亘古不变的话题了 1.8 加载模块详解（纹理篇） 加载龟速？是时候来点加速度了！ 1.9 加载模块详解（网格篇） 1.10 加载模块详解（Shader篇） 1.11 加载模块详解（动画资源） 二、提升：工欲善其事，必先利其器 在这里不仅有效果拔群、性能出众的插件帮助大家省心省力，也有卧虎藏龙的民间高手抛钻引玉给大家分享自己的优化技巧。 1、UI相关 2.1.1 UGUI 降低填充率技巧两则 2.1.2 如何优化UGUI的ScrollRect 2.1.3 UGUI表情系统解决方案 2.1.4 UGUI 文本多语言方案 2、制作相关 2.…