UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技 - 资源
type: channel
link: https://blog.uwa4d.com/tag/资源
items: 本地资源检测新增UI界面｜更易用、更丝滑
items: 优化为什么一定要关注Render.Mesh？
items: 2017年度大赏 | 最受欢迎的十个UWA问答
items: 技术分享连载（九十六）
items: 为什么他们都用UWA GOT？
items: UWA发布 | 2017 Unity手游体检蓝皮书 — MOBA篇
items: 搞定这些问题，一个插件就够了！—UWA GOT 功能全剖析
items: 技术分享连载（六十九）
items: UWA资源检测与分析支持Unity 5.3！

本地资源检测新增UI界面｜更易用、更丝滑
type: item
date: 2020-06-28T05:18:00+03:00
description: UWA已经推出了本地资源检测服务，并受到大家积极回应。在与用户的沟通交流中，我们惊喜地发现已有开发者基于该功能的代码实现，制作了可视化的UI界面，相关同事可直接进行自定义规则的检测设置，进一步降低他们的使用门槛。 “本地资源检测工具是可以通过uwascan_ruleconfig.json来配置检测项的，对于程序员还好，但是如果是QA组或者非技术人员参与排查就不方便切换了。于是我自行制作了对应的设置界面来操作切换配置。” ——黄程 看到这波操作，UWA团队异口同声地感叹：对团队同事来说太友爱了！这样的队友请给我来一打！ 在此特别感谢黄程团队对UWA和“本地资源检测”的认可。 受黄程启发并沟通后，我们决定将这个组件开放，供大家下载使用。考虑到用户首次使用“本地资源检测”，一般都是需要进行规则配置的，那么相比于陌生且“死板”的配置文件，UI界面操作无疑是个更友好的解决方案。 说明：我们现在配置文件方案和UI界面方案是共存的，新老用户皆可兼容使用，并且在UI界面中不同模式的选项下方做了相应的文字说明。 使用流程 在UWA官网接入了新组件后，Unity引擎的Tools->UwaScan选项中多了个Settings的选项，点击Settings选项后，就可以呼出UI界面，如下图所示： 界面呼出后，左侧会显示5个检测选项。在【通用】选项中，可以进行“场景扫描模式”、“资源扫描模式”、“资源扫描路径列表”，“扫描忽略路径列表”等操作。 剩下4个选项对应4个插件的规则启用/禁止，UI界面上所展示的功能与uwascan_ruleconfig文件中的配置项完全一致，用户在UI界面中配置后，会对uwascan_ruleconfig文件进行写入操作，等同于用户进行了配置文件的操作。组件在执行的时候，仍然是读取配置文件中的规则进行执行，这个逻辑与原有逻辑相同，不发生改变。 该功能需要大家更新检测组件，可登录UWA官网，【本地资源检测】服务中创建项目，点击【相关下载】即可获取最新组件。 替换文件如下： 对于已经使用了UWA本地资源检测服务并做过配置自定义的小伙伴们，可直接更新UwaProjScan.dll即可，该更新会兼容用户已存的规则。 关于【UWA本地资源检测】 本地资源检测是UWA推出的、面向于静态资源的全量分析，可针对项目组制作的美术资源进行检测，结合大家自己设定的阈值，快速检测资源的不合理情况，帮助研发团队及时发现并修复。 该服务目前已经成为不少开发团队的打版必备流程：每天半夜自动检测出报告，便于研发或QA团队第二天能快速查看数据报告并做针对性的修缮，大幅度地提高了研发效率。快来联系UWA小助手微信（17502188376）申请免费试用吧！

优化为什么一定要关注Render.Mesh？
type: item
date: 2018-03-12T12:06:00+02:00
description: 本期聚集话题：Render.Mesh耗时剖析、PSS走势详解、合理优化RenderTexture、排查没有依赖的插件资源等，都是非常实用的技巧哦~ 这是第102篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间15分钟，认真读完必有收获。文末，我们的互动话题是，AssetBundle Diff Patch 方案是否可行？期待你的高见！ UWA 问答社区：answer.uwa4d.com UWA QQ群：793972859（仅限技术交流） 渲染 Q1：可否解释下不透明渲染中，BatchRenderer.Flush中的Render.Mesh代表什么意思，我看在我的报告中一直都很高。这个数据算正常吗？ UWA：这个问题正好可以解释一下Flush下的这些显示项含义。BatchRenderer.Flush其实就是引擎要对当前这一帧进行渲染时的CPU端开销。一般来说，都是先Batch Draw Call，然后就可以调用Ogl相关代码分批次将数据传输到GPU端进行渲染了。 这里根据项目的不同主要会出现三个显示项：Batch.DrawStatic、Batch.DrawDynamic和Render.Mesh。其中DrawStatic表示当前帧同通过Static Batching的Mesh的Draw Call统计耗时。相应的，DrawDynamic则为Dynamic Batching相关耗时。而Render.Mesh则为无法进行Draw Call Batching的统计耗时。 题主提供的信息中，可以看出是Render.Mesh的Draw Call为42，而CPU耗时为8.27ms，坦白说，对于42个Draw Call来说，该值属于偏高了。但具体原因，但这份表格是无法获悉到的。对此，UWA的建议如下： （1）题主需点击“Render.Mesh”查看其在整体测试中的CPU耗时走势，如果只是单一几帧出现零星高值，则不用过于担心，因为任何统计都不免出现“奇异值”； （2）但如果是普遍、持续的高耗时，那么就必须严肃对待了。可以通过报告中的图表查看出现高CPU耗时时的具体位置，然后有针对性地进行更为深入的分析，比如使用Unity Frame Debugger，重点查看到底会有哪些无法Batch的Draw Call，是否合理等； （3）通过第（2）步，你应该可以了解了一些无法进行Batch的模型，然后可以进行一些二分法来逐步定位到底哪些模型对其耗时影响最大，直到排查到问题为止。 当然，还有一个高效的方法，就是把项目抠一个可复现问题的Sample出来，然后发给我们。我们每天都在帮助深度客户来解决问题，一些典型问题我们会以专栏的方式放出来，具体可以看求知探新。 该回答由UWA提供，欢迎大家转至社区进行进一步交流： https://answer.uwa4d.com/question/5aa15dbfd35eb22c10a0a372 资源管理 Q2：我们用的是Unity 2017.3，游戏工程删除Resources文件夹和所有Scene后出的空包非常大，检查发现使用的插件包含比较多的图片导致。但是那些资源没有地方引用，怎么会打进包里呢？如果全部删除的话在开发的时候不方便，所以请问有没有办法在出包是剔除没有用的资源？ 配图： 题主可以自己修改下插件，把资源放到”Editor Default Resources”或者”Editor/Resources”下，不要直接放Resources下，反正根据打包日志慢慢把这些插件的清理干净就好，体力活。 PS. 在Unity 5.4之前(大概是这个版本，具体要查Changelog) ，Editor下的Resources也会被打包进来的，后来就修掉了。 感谢UWA问答社区 @钱康来 提供了回答，欢迎大家转至社区进行进一步交流： https://answer.uwa4d.com/question/5a97b0330b827e2c0bfdd06b 资源管理 Q3：对于RenderTexture的优化一直比较迷茫，貌似和分辨率和AA关系比较大，上图是相关的设置图，我想请教下。 1）这个分辨率的设定一般怎么比较合理？1440×2560是不是有点高了？ 2）AA的设置一般是None吧？看大家说在移动设备上一般不需要开启这个效果，是吗？ 3）Color Format一般选什么格式呢？ARGB32的比较高清，那是否也会占据大量的内存？ 4）这个参数设置图中是否还会有其他因素也造成RT较高？ 下图是我们的资源详情图，希望能给些分析建议，谢谢！ 1）RT分辨率的设置取决于这张RT是做什么使用的。一般RT的大小为屏幕尺寸大小，也就是screen.width和screen.height，而screen的尺寸，一般由于…

2017年度大赏 | 最受欢迎的十个UWA问答
type: item
date: 2018-02-27T03:59:00+02:00
description: 新年伊始，随着大家紧锣密鼓地开始了工作，UWA每周推送的知识型栏目《厚积薄发 | 技术分享》已经伴随大家走过了100个工作周。回顾两年多来，我们分享了近500个和游戏开发、优化相关的精彩问答。这些问答不仅有具象明确的提问，也有详细周全的解答；既能供研发团队自身项目中即学即用，还能通过参与者的回答分析，帮助我们在解决问题的过程中触类旁通、鉴往知来。我们优选了10个开放性的精彩回答，分享给大家。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 1、如何在项目初期确定美术规范？ 在项目初期，没有任何正式美术资源的情况下，如何给出一个美术资源制作的规范给到美术呢？我明白，就上面的策划需求不能得出一个精确的制作规范，只是想要一个大概的推算方式，给出一些大概的参数，好让美术有规范可以参考。不知是否能给些指引？ 美术也可以按他们想要的精度先制作部分角色和场景，但只有有限种类的资源的情况下，有方法测算出这个精度在性能允许范围吗？也就是说这个精度满足策划需求，可以作为美术制作规范。例如只有一个角色（5000面，512贴图三张，80根骨骼），策划同屏要求20个，就在场景中摆20个一样的角色进去（因为只有一个），如果目标手机不崩溃，以后角色的制作就按这样做。这样可以验证这个精度吗？ 精彩回答1： 作为经历了一个新项目在大家都没经验的情况下做出一个刚小范围内测游戏的苦逼开发者，结合群里讨论，个人觉得以下经验可以参考： 1）选好对标游戏，扒资源来参考。比如畅销榜上的游戏，把资源解出来看，参考模型面数和贴图等游戏。这样最坏的情况下，参考别人能跑上线收到钱的游戏，收钱不保证，但是游戏性能的坑会少很多； 2）所有口头或文档的规范，都是无效的，不可能得到严格遵守，也就是说，不能用程序检测的规范都是空规范，全部做成Editor菜单检查校验； 3）用同一个英雄放20份测同屏的方法是不靠谱的； 4）从gfxbench.com上根据跑分选好基准机型，比如假设要兼容的机型是跑700帧的，那么基准机型得选6000帧的，预留好性能空间，性能别用得太满，否则没回旋余地: 5）贴图少用RGBA32，让美术在做图的时候，做出来一律以压缩模式的纹理来走Unity导真机包来看效果，千万别只是把美术图导手机相册里看效果，这会和真实的游戏效果有所偏差。建议规范只留两张2048*2048的纹理空间给美术发挥，其余全压缩，否则等美术在高画质模式作出效果后不肯降效果，逼程序优化，性能损耗非常大，程序会万分苦逼。 感谢李先生提供了以上回答。 精彩回答2： 这确实是个见仁见智并且取决于项目类型的问题，不过题主是在项目初期，想要快速迭代出策划的设计原型，并且要快速制作并且不用与程序产生过多沟通，在此前提下我觉得设定美术规范的首要目的是：不失控。制作出性能优秀的原型不是前期的目的，但毕竟是项目进展的一部分，如果美术资源制作没有标准规范参考，如果随便一个场景都是几十万面，DrawCall超过300，Overdraw可视化都红得发白，那到后面整个团队都要为此付出时间和精力，甚至返工。所以基本的制作规范也是十分必要的。 其次，在项目前期如何看待优化这个问题呢？我觉得过早的优化也是没有太大意义的，谈优化必须首先定位瓶颈，否则盲目优化除了降低资源质量和运算精度，对项目很难起到正面作用。这时项目处于快速变化中，不适合过早断定，所以在这个阶段依然是保证项目即使没有很优秀的性能，但是也没有很严重的问题，这就已经及格了。到了项目后期优化与效果的博弈，这又是另一个话题了。 在以上前提下，假设题主制作的是一个RPG游戏，主城+若干小副本推图，中端手机 iPhone 5，没有程序的太多干预，那么我的建议是： 1）大致规定好项目在 Unity 中的资源组织格式； 2）设定好 3dmax 导出模型的比例标尺，最好与 Unity 大小 1:1； 3）场景总面数均值5-6w左右（大部分），最高10w（少部分），单个模型300-1500面，摄像机可见部分2w以下，导出去除废点，多余的法线（如果没用的话），尽量单面； 4）场景总面数还要看同屏战斗人数多少做调整，Drawcall最好不超过50，一边给角色和特效留下空间，总 Drawcall 不要超过250这个尽量保证； 5）场景物体每个模型一个材质球，贴图256为主，正方形，pot(长宽2的倍数)； 6）严格限制场景中透明片的大小和重叠的个数，尽量少用，减少面积； 7）角色面数部分，主角1500以下；特殊boss2000以下；精英怪物1000面以下；普通怪物800面以下； 8）每个角色一个材质，除了特殊部件（翅膀等）一律不使用透明材质；贴图长宽相等，符合pot，128-256为主，最大不超过512； 9）去除 IK 节点和所有不必要的网格，对齐模型…

技术分享连载（九十六）
type: item
date: 2018-01-23T10:08:00+02:00
description: 本期聚集了这些话题：AnimationClip的AB文件大小、不同Unity版本的AB文件大小不一致，AB前后打包的CRC值不一致...... UWA一下，你就知道~ 我们将从日常技术交流中精选若干个开发相关的问题，建议阅读时间15分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 资源管理 Q1：最近在做包体压缩，发现有些动画文件的AssetBundle文件比较大，观察发现是其中包含的Clips较多，但是这些Clips都是复用的，而只是动画轨上挂的事件不同，所以创建出来的。 我们使用了LZ4的压缩格式，这个文件的大小大约是800K+，偶然测试使用了非LZ4的形式来打包，这个文件的大小大约是60K左右，相差有10倍以上的差异，这个就比较奇怪。 不知道有没有别的项目遇到过这样的问题，我尝试从原理上理解： 对于这种重复的动画，数据是可以复用的，动画事件相当于存储一些额外的配置就够了，所以理论上增加这种复用式的Clips不会对AssetBundle文件有多大的影响。LZ4因为要支持Chunk式的加载，所以复制了动画信息到所有的Clips的Chunk上？因此数据比较大？ 想问下我的猜想是否正确，这种情况下，有没有什么好的方法压缩一下这块的体积？ 两种格式下的AssetBundle文件大小差异： 是可能存在这个问题的。使用了LZ4压缩的动画文件AssetBundle大小，与Animation面板中Clip的数目和每个Clip的大小成正相关。 因为无法看到源码，只能说下我的理解：在打包AssetBundle时如果选择LZ4压缩，其将动画文件中的每个Clip作为独立的资源来单独压缩，这样可以保证在解压时只解压需要的Clip，但这样也就隔断了不同Clip间重复数据的复用，从而造成AssetBundle体积随Clip数目增加而变大。一个简单的例子就是，当你增加多个哪怕是完全相同的Clip时，AssetBundle文件也会随着Clip数目增多不断增加（很容易超出动画Fbx的大小）。 而默认的LZMA压缩，压缩时将整个AssetBundle作为一个整体（当然解压时也需要对整个AssetBundle解压），因而能充分复用不同Clip间的重复数据，因此，压缩后的AssetBundle大小对分割的Clip并不敏感。同样的例子，对动画文件增加多个Clip后，使用LZMA压缩的AssetBundle依旧会保持很小，而且增加不同的Clip数目，其大小也基本不变。 如此一来，如果要通过压缩减少动画文件AssetBundle体积，可以对解压速度不太敏感的动画文件用LZMA压缩。 该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/5a5cbf773513a24bd4ee76e2 资源管理 Q2：我在Unity 5.3.8 和5.6.5 下进行同样的设置，为什么FBX打出来大小相差那么大？ Unity 5.3.8 ：35K， Unity 5.6.5 ：400K，相关的例子已经上传至UWA问答网站。 看了下题主的AssetBundle文件，可以提供以下线索： Unity 5.6的Bundle： Unity 5.3的Bundle： 可以看到两个Bundle的差异在Shader，然后在Unity 5.5的更新文档中看到： Shaders: Shaders are now exported to the Unity player completely in binary. There is no Shader text string and parsing in run time. 也就是说，Unity 5.6的Bundle中Shader已经被编译为二进制，而Unity 5.3的Bundle中仍然是Text的Shader，从而导致了Bundle的不同。 该问题来自UWA问答社区，感谢 Saber 提供了回答，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/5a5ecc8ce6353e6be1f4342e 资源管理 Q3：我场景打包的AssetsBundle每次都不一样，和这个问题类似（https://answer.uwa4d.com/question/58d24e477dc35e7f0efb470f ）。 我已经修改了Strippt Shader的设置，并且每次都在同一个空场景下打包，但是打包出来的CRC值不一样。 我每次都是先删除本地资源，然后从SVN上CheckOut下来再打包。场景用到的S…

为什么他们都用UWA GOT？
type: item
date: 2017-10-20T04:32:00+03:00
description: 手游开发和优化的时间一直是寸土寸金的，随着中国移动游戏的精品化趋势日趋明显，整体表现都在迅速向端游品质进行靠拢。随之而来的，则是各种性能压力的急剧上升，优化工期的不断延长。如何在紧张的工期内，实现时间的最大使用价值呢？ 为了最大程度优化测试和优化的时间，我们推出了本地性能优化工具，为游戏研发团队提供性能数据分析的同时，还大大提高了大家的优化工作效率。据统计，截止目前使用UWA GOT的团队已经超过300家！ UWA GOT 是什么？ UWA GOT 全称 Game Optimization Toolkit，是由侑虎科技研发的本地性能测评工具。它既能方便研发团队在本地直接进行真机测试，也支持在Unity Editor中搭建本地服务器来接收和分析性能数据。整个测试过程中，研发团队能自定义测试时间和流程，几分钟后即可查看性能数据。目前提供 Performance Overview、Mono Memory Analysis 和 Runtime Asset Tracker三大功能的数据分析，从此为大家的项目性能又增添一份安全堡垒！ UWA GOT 使用步骤 为什么大家都选择UWA GOT？ 300位技术买手实力证明！ UWA GOT 的优势在于快，那么它到底为大家省下了多少时间呢？不妨让我们看看各位开发者朋友的买家秀吧！（感谢诸位技术大佬倾情代言！） 仅用一个多小时，对大型项目找出了针对性的解决方案 快速定位性能热点 功能全面、使用方便 节省大量时间成本 采集数据详细又简单 利用帧对比定位了资源内存泄漏 加快版本复盘和迭代的效率，性能提升立竿见影 便于团队协作 资源问题一目了然，减轻大量优化工作 便于反复调试和定位全局问题 想开发者所想，不断推陈出新 为了满足开发者更多样化的测试和优化需求，UWA也在不断收集用户的反馈意见并加以完善。今天我们发布了UWA GOT 最新版本v 1.0.4，该新版本主要支持了对游戏启动时间内的堆内存分配统计，对于不少开发者来说，这又是一个非常友好的功能。 为什么这么说呢？因为在定位堆内存分配时，开发者在UWA的在线性能测评报告中常常会看到类似下图中的曲线。 从中我们可以发现，在开启测试时，Mono堆内存峰值已经到达100MB以上，这表明在游戏刚开启时很可能分配了大量的堆内存。 那么在游戏启动的那短暂的时间内，引擎到底做了哪些工作，分配了多少堆内存呢，具体又是怎么分配呢？为此UWA GOT增加了Direct模式来解决这问题，当点击Direct Mode并使左侧按钮变绿后再点击某个模式，App会自动退出，而在下一次开启时则立即开启测试。 这些贴心巧妙的功能还只是冰山一角啦，关于UWA GOT更多功能，请查看：搞定这些问题，一个插件就够了！ 小编建议大家及时在官网下载最新版本，以体验更完整的功能：https://www.uwa4d.com/index.html#download

UWA发布 | 2017 Unity手游体检蓝皮书 — MOBA篇
type: item
date: 2017-08-31T05:14:00+03:00
description: 过去的一年，MOBA手游市场容量变得空前庞大，成了众多CP和发行追捧的对象，同时，其重社交、重玩法、重美术效果的高要求使得该品类游戏也面临着前所未有的性能挑战，那么当下市场上的MOBA手游性能呈什么样的状态呢？我们能从这一年的性能数据中找到什么规律呢？今天，我们将为大家分享MOBA手游性能的深度剖析。 今天分享的这份蓝皮书，收集了提交到www.uwa4d.com上的所有MOBA项目，我们从总体性能数据、引擎各模块开销、内存占用等方面进行了汇总分析，呈现Unity手游行业现状。 这是侑虎科技第291篇原创文章，欢迎转发分享，未经官方授权请勿转载。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。（QQ群：793972859） 报告目录： 一、MOBA手游总体性能开销分析 二、MOBA手游CPU模块性能开销分析 三、MOBA手游内存模块性能开销分析 四、MOBA手游资源管理分析 五、UWA对于MOBA手游研发团队的建议 说明：我们选择了测评次数最多的四款机型来进行统计，这四款机型分别是红米2、红米Note2、华为6Plus和三星S6。同时，由于中低端设备性能是研发团队更为关注的部分。因此，本报告中的性能趋势分析以MOBA项目在中低端设备的性能数据为主。 一、MOBA手游总体性能开销分析 Android设备的CPU均值主体范围为16~61.2 ms，且主要集中在17~50ms范围之内。 无论是高、中、低端的Android设备，渲染、UI、加载/代码都是需要研发团队重点关注的，它们的消耗总和占了总开销的80%。 下面我们就来具体分析这些主流模块的开销情况。 二、MOBA手游CPU模块性能开销分析 1、渲染模块 严重程度：地狱 为了能够更好地反映出各个性能参数的整体使用情况，我们统计了每种性能参数的主体使用范围，其范围区间是[5%~95%]，以下数据中P5代表5%，P95代表95%。 在Draw Call使用上，MOBA手游的使用程度大幅低于MMORPG和ARPG手游，且对Draw Call的控制同样较好，UWA建议Draw Call占用的P95 < 200，86%的项目可以将其控制在这个范围内。 MOBA手游的场景渲染三角形面片数量普遍较高。且设备性能越高，数量峰值越高。经过统计，在中低端设备中，46.6%的项目能将渲染三角形面片数控制在100K以下。 2、UI模块 严重程度：地狱 使用NGUI作为UI解决方案的项目占据了相当高的比例，NGUI目前仍然是MOBA研发团队对于UI系统使用的主要解决方案。MOBA是目前手游中工程技术难度最为复杂的游戏品类之一，对于UI模块的选择，大多数团队仍然倾向于从稳定性和把控性两方面出发，这也是NGUI占比持续较高的主要原因。 下面我们将分别说明NGUI和UGUI的CPU耗时和堆内存占用情况。 UI模块的性能开销依然很高，也是我们统计中的重要性能杀手。在中低端设备上，超过80%的研发项目在UI端都面临较为严重的性能问题，主要体现在以下几个方面： （1）同一时刻存在大量需要更新的Panel，比如，攻击时刻的血条、不断移动的伤害数字等HUD。这些在“人堆”中范围攻击时或者进攻高地时是很容易大面积出现的； （2）不断滑动的摇杆和点击的技能icon，这些是MOBA战斗场景中使用最为频繁的UI元素，研发团队需要时刻注意这些icon的变动是否会带来较大范围内的重建。 以上情况都是MOBA项目研发团队每天面对的主要UI问题，可能一个Widget的使用疏忽，就能让研发团队的UI模块性能开销飙升一个量级。 注意：从重要函数上来看，UGUI的CPU占用大幅低于NGUI。需要说明的是，Unity 5.2版本之后已经开始将UI的部分计算操作移到子线程中进行，而主线程中的表现则为WaitingForJob、PutGeometryJobFence等，在本次报告中，我们并没有将这两项开销统计在内。 经统计，NGUI中堆内存每10000帧分配的主体范围为 5.4~53.2 MB，UGUI中堆内存每10000帧分配的主体范围在5.2 MB以内。从堆内存分配来看，UGUI远低于NGUI。 3、逻辑代码 严重程度：噩梦 1）GC触发频率很高，是造成卡顿的主要原因之一，目前只有48.7%的项目可以将GC的触发频率控制在1000帧/次以上。 2）在2016年GC平均耗时下降趋势明显，但在2017Q2出现大幅上升趋势，对此，建议研发团队在后续研发过程中对GC操作和耗时进行密切关注。 Shader.Parse 操作是比较突出的性能杀手，目前平均每次调用的CPU耗时主要分布在 6.4~171.3ms。但随着越来越多团队了解该项的耗时特性后，该项的CPU耗时呈现出较为明显的下降趋势。 4、动画模块 严重程度：噩梦 Animator.Update…

搞定这些问题，一个插件就够了！—UWA GOT 功能全剖析
type: item
date: 2017-07-06T04:50:00+03:00
description: 继UWA GOT推出后，我们接到了大量的反馈，其中不乏一些令我们感动的评价和建议，在此首先感谢大家的关注和支持： 感谢如此走心的评价，鼓励亦是动力！ 读到这里，对于还不了解UWA GOT的朋友肯定多了一个问号，它究竟拥有什么力量，为何近期能在游戏圈小小地火了一波？接下来小编就为大家全面剖析UWA GOT的三大功能，并附上真实演示实例。 UWA GOT 全称 Game Optimization Toolkit，是由侑虎科技研发的本地性能测评工具。它既能方便研发团队在本地直接进行真机测试，也支持在Unity Editor中搭建本地服务器来接收和分析性能数据。整个测试过程中，研发团队能自定义测试时间和流程，几分钟后即可查看性能数据，同时还提供深度的数据分析，如脚本中的主要函数耗时、堆内存的具体分配堆栈等高级分析功能，从此为大家的项目性能又增添一份安全堡垒！ UWA GOT 目前提供 Performance Overview、Mono Memory Analysis 和 Runtime Asset Tracker三大功能。 功能一：Performance Overview 主要包括逻辑代码的CPU开销以及硬件设备等具体信息。 1、逻辑代码的CPU开销 在“Version”中选择需要查看的测试版本。 选择后，UWA将载入相应数据并进行分析和展示，主要包括CPU开销走势图、项目运行视图以及CPU耗时分析视图。 下图即为CPU耗时分析视图，从左上角可以看到，UWA将逻辑代码的CPU耗时进行总结，用户选取某一指定的函数，即可看到它在运行时的具体耗时，也能通过调整关注区域视图中的滑块，来查看重点关注区域的CPU开销。 同时还能动态调整数值的范围，方便用户进行进一步查看。 2、硬件设备信息 在“Mode”中选择“Hardware”，即可查看App运行时的硬件设备运行信息，主要包括：硬件设备的内存信息（PSS内存在项目运行时的走势）、电量、温度以及网络流量统计走势等具体信息。 上图为项目运行时，PSS内存的走势图。 功能二：Mono Memory Analysis 主要包括代码堆内存累积分配和代码堆内存泄露分析。 1、代码堆内存累积分配 在“Mode”中选择“Total”，即可查看App运行时每个函数的总体堆内存分配情况。在“Top List”中选择具体的函数名称，研发团队可以看到相应函数的具体堆内存分配情况，并且通过与图表进行交互来查看任何一帧的具体堆内存分配。 2、代码堆内存泄露分析 如下图所示，在“Top List”中选择具体的函数名称，即可看到相应函数的具体堆内存分配情况。我们在“Diff Mode”中选择“ON”，即可开启“代码堆内存泄漏分析”功能。选择任意两个柱状图，则可以快速比较两次堆内存占用的差异。通过比较差异，我们能快速定位堆内存变化的出处。 功能三：Runtime Asset Tracker 该功能主要包括资源使用情况、每帧中资源的具体使用情况、资源泄露分析以及资源冗余分析四大功能。 1、资源使用情况 在TopList中选择我们想查看的资源类型，点击资源使用走势图，即可查看每帧该类资源或某个特定资源的具体使用情况。 下图中，我们选择纹理资源类型的走势图，在面板下方马上就显示了项目运行时所有纹理资源的具体运行信息，包括：占用内存、高度、宽度、格式等，一览无遗，各种资源尽在掌控。 2、资源泄漏分析 大多数项目或多或少都存在资源泄漏的问题，但有了UWA GOT的帧比较功能，研发团队可以轻松分析是否存在资源泄露等问题。 以下图为例，我们在纹理资源中，选中第12000帧与第17700帧的资源使用情况进行比较。其中，“Max Memory”中为正值的资源表示为第17700帧中的新增资源（若存在负值即表示为第17700帧中的减少资源）。通过这种比较，即可协助研发团队快速定位具体的资源变化量和解决资源泄露等问题。 3、资源冗余分析 项目运行过程中，内存中的资源很有可能出现冗余情况。对此，建议研发团队详细查看资源数据展示界面中的“Max Count”数值， “Max Count”大于1的资源存在冗余问题的风险较高。Max Count是指项目运行过程中，某一资源在某一帧中的最大资源使用数量。 都说这么多了，是不是就差链接入手一个？ 小编特此附上入手指南，快收下~ UWA GOT 入手指南 Q1：官方是否会对UWA GOT进行维护和功能更新？官网的价格包括了之后的更新吗？ 是的，我们会不定时更新UWA GOT的新功能，并在官网和官方微信上进行说明，敬请关注。 Q2：UWA GOT目前支持什么平台？ 目前支持Android、iOS以及Windows平台，关于更多平台的支持及功能升级，我们将持续更新，敬请关注。 Q3：目前提供的入手渠道是什么？ 用户可以…

技术分享连载（六十九）
type: item
date: 2017-06-27T04:36:00+03:00
description: 本期我们聚集了这些话题：被自动打进AssetBundle的资源无法主动加载出来吗、Spritepacker自动划分Group、资源Ref count为空、Graphics ApI选择... 我们将从日常技术交流中精选若干个开发相关的问题，建议阅读时间15分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 资源管理 Q1: 在打包的时候，有一部分资源是没有设置AssetBundleName的，打包的时候会和依赖它们的资源打到同一个AssetBundle包里（Unity自动完成）。在资源加载的时候，无法主动获取到这些没有设置AssetBundleName的资源。GetAllAssetNames、LoadAllAssets这些接口的返回值中都没有这部分资源。 请问，在你们看来，这种情况是Unity的设计还是Bug？如果是如此设计的话，有什么特别的意义吗？ 提供一个简单的情景，如下： １）有A、B两个Prefab，其中A上挂个脚本引用了B ２）打包的时候，设置A的AssetBundleName＝"prefab.unity3d"，B的AssetBundleName=None ３）打包，只产生prefab.unity3d这一个AB包，其中包含了A、B两个资源 ４）加载代码使用AssetBundle.LoadAllAssets()，返回的数组里只有一个资源（A） 我们刚刚在Unity 5.5.2版本上进行了一个测试，得到与题主一样的结论。 我们更加倾向于它是一种设计，而非Bug。因为Prefab B是作为一种参数被引用在A的脚本中，所以在AssetBundle中，它将以GameObject B的形式存在，但是不会存在于AssetBundle的映射表中。而对于题主的这种打包方式而言，AssetBundle的映射表中只会有一个，就是Prefab A。而AssetBundle.LoadAllAssets虽然会把GameObject A、B及其关联的资源全部加载，但其返回的Object[]内容应该就只有一个，也就是Prefab A。 所以，UWA推测，AssetBundle中在打包时是自己维护了一个map的，只有明确被设置ABName的资源才会被放入map中，也只有map中的资源才可以通过特定名称进行Load，而其关联的资源则会被打包到AssetBundle中的其他container中，是无法通过LoadAsset或LoadAllAssets API来获取到的。 此问答来自于UWA 问答社区： https://answer.uwa4d.com/question/594dc62dba16a4c31f8ca1ac 如您对该问题仍有疑问，可以转至社区进行进一步交流。 性能 Q2：UGUI自动打包图集时，有时候同一个Tag会自己打出多个Group图集，导致DrawCall增加，有什么解决方法吗？这个分Group的原理是什么？ 不少的项目都会遇到这个问题，即很多纹理打上了相同的Tag，但是却出现在了不同的Group中，类似下图，一个图集里包含了四个Group： 而产生Group的原因主要有两种： 1. 纹理的格式不同 。举例来说，有这样四张纹理格式分别为：RGB24，ETC1，RGBA32和ETC2，那么设置一样的Tag后，对应的图集就会有四个Group： 2. 纹理量太大。一个Group放不进，这个原因是容易理解的，就不解释了。 其中特别容易忽略的一点是，某些小纹理可能没有Alpha通道，导致了图集被分成两个Group，引起DrawCall的增高，这种情况下可以直接修改纹理，也可以强制设定为Aalpha通道的格式。 此问答来自于UWA 问答社区： https://answer.uwa4d.com/question/594cef012a0bce361ae401ba 如您对该问题仍有疑问，可以转至社区进行进一步交流。 性能 Q3：Gfx.ProcessCommands包含哪些行为操作？据我了解，该行为是在RenderThread中，导致该行为耗时的主要原因是DrawCall。 那么除了DrawCall还有那些行为被记录到该过程中呢？ 另外这过程耗时统计是否还包括顶点、材质贴图以及Shader等从内存到GPU的IO时间呢？ 该问题限制在OpenGL ES 2.0/3.0驱动下思考，无需考虑Vulcan/Metal等目前面向多线程的驱动。 题主所列的这些行为应该是都在里面的。因为，即使是多线程渲染，图形API的调用也需要在同一个线程中。其一，是Android系统的EGLContext一般不是线程独共享的，也就是只有一个线程能向同一个EGLConte…

UWA资源检测与分析支持Unity 5.3！
type: item
date: 2016-04-26T12:07:00+03:00
description: 前不久UWA推出了资源检测功能之后，开发者的反应是这样的： 是这样的： 更有开发者把报告优化的成果晒给了我们：效果拔群！ 除了自动检测，反馈神速等低门槛的使用方法，开发者表示最认同的是该工具分析深度、冗余资源看得见！ 今天，沉浸在喜悦之余的我们，再为Unity 5.3版本上开发的朋友带去福音——与时俱进，我们全面支持Unity 5.x的正式版了！ 在UWA团队多年的技术支持中，常会被开发者问到：“如何减小包体大小、如何应对资源冗余，内存泄露”等在小编看来已偏形而上的问题。即便我们给出一些类似优化美术资源、注意依赖性打包机制等长篇大论，开发者在亲自优化的时候，仍需要根据具体问题具体分析。那么如何得到量身定制的解决方案，并做针对性的优化呢？ AssetBundle依赖性关系 AssetBundle之间的依赖关系是依赖关系打包的精髓所在，也是最容易出现问题的地方。依赖关系建立不当，往往会给项目运行带来极大的影响，比如资源丢失、资源冗余和内存泄露等等。正因如此，我们对AssetBundle文件的依赖关系进行了详细分析，并将其之前的详细依赖关系通过表格进行展示，以方便开发者对AssetBundle的依赖关系进行更好地管理。 如下图，表格中列出了每个检测到的AssetBundle文件，及其具体依赖的AssetBundle文件。开发者可以随时对任意AssetBundle文件、资源信息进行详细查询。 AssetBundle资源冗余 “资源冗余” 是AssetBundle文件在打包时最容易出现的问题。该问题在UWA性能诊断与优化中也常常出现。下图即是某动画片段资源在项目运行过程中出现的 “冗余” 问题。其根本原因，可直接查看相关文章《性能优化，进无止境---内存篇（下）》 在该页面中，开发者可以详细查看出现冗余资源的AssetBundle文件。点击 “含冗余资源的AB数”，则可以看到存在问题的AssetBundle文件，及其相应冗余资源的具体的信息。 由于篇幅有限，我们在此仅列举部分，更多功能（如缺失AssetBundle资源检测、脚本使用情况检测）等待开发者亲自探索。 同时，在我们的工具实现了一次次的光荣使命后，也有热心的开发者提出了以下建议： 能否将每次上传的资源包做对比？ 的确，该功能使得用户体验会更好，我们会尝试在以后的版本中提供该功能。 如果能加上资源大小的排序，就更好了。 该功能已经在Roadmap中了。 .... 感谢这些帮助UWA不断进步的使用者！看，学习总是相互的。每次和开发者的沟通中，我们从来都不仅仅是知识的给予方，我们也总能收获一些有趣的、值得深入探索的奇思妙想。 最后，UWA团队真诚希望，看到这篇文章的你，能把你们优化的同事邀请至项目中。优化大业，你从来都不是一个人在战斗；同时，也记得分享给你的任何一个开发者朋友，为了国产游戏品质的不断突破，何不再UWA（优化）一下？