UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技 - cpu
1）小游戏RT内存为何偏高 2）Physics耗时为何居高不下 这是第490篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。 实战案例 Q：同一套项目资源，APP侧RenderTexture占用只有30MB左右，但小游戏侧却达到130MB左右，为什么会出现这么大的差异？ A：排查后定位到两个明显的配置问题：小游戏侧3D渲染分辨率没有按预期缩小，同时Depth Buffer仍然使用32位格式。这两项都会增加RenderTexture相关的内存压力。 小游戏和APP端虽然运行的是同一套项目，但不同平台实际创建出来的RenderTexture配置可能并不一致。尤其是渲染分辨率、Depth格式以及MSAA配置，一旦平台侧实际生效情况不同，最终内存占用就会产生明显差异。排查时可以重点关注： 3D渲染分辨率没有正确缩小。 小游戏侧实际渲染分辨率较大，说明原有的降分辨率策略没有按预期生效。RenderTexture内存和宽高直接相关，如果3D场景仍然按照设备较高的原始分辨率渲染，Color和Depth相关RT都会随之增大。 APP端原本可以通过分辨率设置控制渲染尺寸，但到了小游戏环境，需要重新检查对应接口是否生效。对于URP项目，可以通过renderScale控制3D场景实际渲染分辨率，最终再放大到屏幕，而UI仍保持全分辨率显示。 Depth Buffer仍然使用32位格式。 小游戏侧当前使用的是32位Depth，而移动端原有配置使用24位。需要检查平台相关设置，将小游戏/WebGL纳入对应的Depth格式配置，减少这部分额外的内存占用。 确认MSAA配置。 当前RenderTexture配置中可以看到MSAA为2。MSAA会增加Color Buffer和Depth Buffer的存储开销，尤其是在RT分辨率较高时，需要保存更多采样数据，会进一步放大内存占用。排查RenderTexture内存差异时，需要确认小游戏侧最终生效的MSAA等级，避免平台配置差异导致额外的RT开销。 实战案例 Q：项目已经针对物理碰撞制作了简化模型，但低端机上Physics耗时仍然达到二三十毫秒。碰撞模型已经简化，为什么物理压力还是很高？ A：碰撞模型复杂度只是影响Physics耗时的一部分。如果Collider已经进行了简化，但Physics耗时仍然较高，还需要继续关注场景中同时参与模拟的动态对象数量，以及这些对象之间产生的碰撞关系。 从GOT Online报告中数据变化来看，随着场景中的物件减少，Physics耗时也同步下降，同时Overlaps数量明显降低。当前场景中的Overlaps已经达到几千级，说明物理系统需要维护大量潜在碰撞关系。排查时可以重点关注以下几个方向： 确认Physics耗时是否和碰撞关系规模相关。 可以减少部分动态物体参与碰撞，再观察Overlaps数量和Physics耗时是否同步下降。如果两者变化趋势一致，说明主要压力可能来自大量碰撞关系，而不是单个Collider复杂度。 检查动态Rigidbody和Mesh Collider组合。 场景中存在大量带Rigidbody的动态对象，其中部分使用Mesh Collider。对于动态非Kinematic Rigidbody，Mesh Collider需要使用Convex。形状允许的情况下，可以继续对比Box、Sphere、Capsule或者Compound Collider的实际效果。不过碰撞体替换最终仍需要结合项目实际测试结果，不能简单认为基础Collider一定更优。 减少无效碰撞检测。 如果部分对象之间没有实际碰撞需求，可以通过Layer Collision Matrix关闭对应Layer之间的Collision，减少不必要的碰撞组合。调整后可以继续观察Overlaps数量和Physics耗时变化。 检查物理模拟频率。 Unity默认按照Fixed Timestep执行物理模拟。当低端设备出现掉帧时，一个渲染帧内可能需要补做多次物理模拟，从而进一步增加Physics耗时。可以尝试调整Fixed Timestep，例如从0.02调整到0.03，对比Physics耗时以及实际物理表现。 Unity 2022以后，也可以测试不同Physics Simulation Mode带来的影响，例如切换到Update驱动，观察减少单帧多次物理模拟后能带来多少收益。不过这种方式会受到实际帧率波动影响，需要同时确认碰撞稳定性和运动表现是否满足需求。 无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。 封面图来源于网络 今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。 UWA官网：www.uwa4d.com UWA社区：community.uwa4d.com UWA学堂：edu.uwa4d.com 官方技术QQ群：793972859
1）隐藏视频为何持续占资源 2）“N/A”纹理如何定位 这是第487篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。 实战案例 Q：一段操作提示视频只有在玩家连续5秒未进行指定操作时才会出现，但UWA GOT Online报告显示，用于播放视频的RenderTexture一直常驻，VideoPlayer相关函数也存在明显耗时。视频大多数时间并没有显示，为什么仍然会影响性能？ A：视频没有显示，不代表相关资源和逻辑已经停止运行。GOT Online报告显示，这段提示视频使用了一张全屏分辨率的RenderTexture，同时带有32位颜色格式和32位深度，并且在整个测试过程中一直常驻。也就是说，视频虽然只在特定条件下出现，但为它准备的RenderTexture平时也一直存在。 这张RenderTexture只是用来显示一段短暂出现的提示视频，却使用了全屏分辨率和较高的颜色、深度规格。这里需要确认三个问题：当前分辨率是否有必要；颜色和深度格式是否过高；以及这张RenderTexture是否必须在整段玩法中一直保留。 除了内存占用，VideoPlayer本身也有CPU开销。报告中的平均耗时为1.47ms，但它并不是每一帧都会执行。只看实际产生耗时的区段，单帧开销接近3ms。 项目目标帧率为30FPS，每帧的时间预算约为33ms。接近3ms已经占用了比较明显的一部分，而这段视频大多数时间并没有显示。 排查时可以先确认两个问题：视频隐藏后，VideoPlayer是否还在更新；对应的RenderTexture是否仍然需要常驻。如果它只是一个低频提示，也可以重新评估是否必须使用视频，以及当前资源规格是否过高。 实战案例 Q：项目在内存分析中发现，大量纹理资源的名称显示为“N/A”。这些纹理基本都是RGBA32格式，分辨率不同，有些长期驻留，有些只在特定流程中出现。这些“N/A”纹理是否代表发生了资源泄漏？应该如何判断并定位来源？ A：先别急着凭“N/A”就断定是内存泄漏。观察报告里这批纹理的总内存趋势，它并没有随时间出现阶梯式的持续上涨，而是稳定维持在一个固定值。所以眼下的核心问题不是产生了内存泄漏，而是这批资源丢了名称信息，导致没法直接从报告里看出用途。 报告中可以看到，这些纹理均为未经压缩的RGBA32格式，分辨率大小不一，整体占用也较为可观。继续查看生命周期后，还可以发现其中一些资源一直常驻，另一些资源只在局部流程中出现。通过纹理的分辨率、格式、占用大小和出现时间进行综合分析，可以进一步缩小资源来源范围，判断这些纹理出现的场景和使用方式。 这种无名称纹理，在实际项目里通常出在两个地方：第一类是代码在运行时动态new出来的临时纹理或RenderTexture。比如项目为了做屏幕截图、UI高斯模糊、画中画或者某些材质特效，在C# 侧写了new Texture2D() 或new RenderTexture()，但创建时顺手漏掉了.name的赋值。这部分资源丢进内存快照后，就会统一被标记为“N/A”。 排查时需要把项目里所有动态创建纹理的代码翻一遍，核对它们的创建时机、规格参数和生命周期。如果相关业务已经关闭，需要确认有没有调用Destroy或对应的释放接口。如果每次进出界面这种纹理都会变多，那才是真正的创建与回收没对齐。 第二类是第三方SDK或插件内部自己生成的纹理。比如视频解码插件、WebView渲染、广告SDK，或者是某些动态字库/图集系统，它们在运行时产生的纹理，很多原厂就没有写赋值name的逻辑，报告里自然也就全显示为“N/A”。 插件里的资源没法直接根据名字追代码，必须拿它们出现的时间点去对业务流程。例如某批“N/A”纹理刚好是在放视频、调网页或者打开特定插件界面时弹出来的，就可以直接锁定到对应的SDK上，检查它的内部释放和缓存机制；如果功能关了资源还不卸载，就要看是不是SDK没调Dispose，或者内部保留了Cache。 当然，上面这两类情况只是排查无名纹理时最常遇到的切入点，在没有拿到确凿的代码调用栈和生命周期日志之前，切忌拍脑袋认定是某段逻辑或某个插件干的。对于只在局部流程里出现的纹理，最好拉出对应时间段的测试录像和操作日志，看看当时到底在跑什么功能；对于全程常驻的纹理，则要重新评估它们常驻的必要性。 建议在项目里规范起来：所有运行时动态创建的纹理，应当为name属性赋值。虽然起个名字不省显存，但能大幅降低日后的定位成本。不然下次再遇到性能问题，面对一堆只有分辨率和格式的“N/A”资源，谁也说不清到底是谁留下的。 说到底，遇到大量的“N/A”纹理，第一优先级不是盲目去写代码释放，而是先把“谁建的、什么时候出来的、为什么要一直留着”这三个问题摸透。在资源的归属和生命周期还没搞清楚之前，别轻易把它扣上“内存泄漏”的帽子。 无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。 封面图来源于网络 今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。 UWA官网：www.uwa4d.com UWA社区：community.uwa4d.com UWA学堂：edu.uwa4d.com 官方技术QQ群：793972859
1）明明没有主动调用，为什么GC依然频发 2）特效精准降温：别急着对游戏画质“动刀” 这是第484篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。 实战案例 Q：我们发现部分设备运行一段时间后，GC次数异常高。但项目里没有主动调用GC，也没有明显的大量内存申请。这种情况一般是什么原因导致的？应该如何定位和优化？ A：遇到GC次数异常增加的情况，首先不要只关注“有没有主动调用GC”。在Unity中，GC不一定需要业务代码显式调用GC.Collect才会发生，更多时候是因为运行过程中持续产生大量临时对象，导致系统被迫进行垃圾回收。 另外，也需要注意增量GC（Incremental GC）的影响。开启增量GC后，垃圾回收会被拆分到多个帧中执行，因此可能观察到GC次数增加，但单次GC耗时降低的情况，需要结合GC耗时和整体性能表现综合判断。 这类问题建议先结合UWA GOT Online报告查看GC发生趋势，确认GC集中的时间段，再结合对应业务场景分析，例如是否发生在战斗Tick、UI刷新等高频逻辑中。 如果GC峰值与某段逻辑高度重合，就需要进一步检查该路径上的内存分配情况。实际项目中，比较常见的问题是高频代码持续产生临时对象，例如Tick中频繁进行字符串拼接、格式化等操作。 例如：string msg = "hp:" + hp + " mp:" + mp；这类代码单次分配并不明显，但如果处于高频执行路径中，会不断产生新的字符串对象，长期运行后就会增加Managed分配压力，最终导致GC频繁触发。 因此，排查GC问题时，不建议只看GC次数本身，而应该结合：GC触发时间点、Managed内存变化趋势、对应业务逻辑执行情况定位真正产生分配的代码位置。优化方向主要是减少高频路径中的临时分配，例如避免在Update、Tick等逻辑中频繁创建对象，对固定文本进行缓存，减少不必要的字符串处理。 最终来看，GC频繁通常不是GC本身的问题，而是业务代码持续制造垃圾对象，GC只是被迫进行清理。排查这类问题时，比起关注“GC调用了多少次”，更重要的是找到：哪些代码在持续制造垃圾对象。 实战案例 Q：我们发现部分特效开启1/4 RT后，渲染性能提升比较明显，GPU压力和设备发热也有改善。目前考虑根据特效Overdraw评分，超过一定阈值后自动开启1/4 RT。另外，有些项目会通过降低战斗场景相机分辨率来降低GPU压力，这种方式是否有必要？ A：1/4 RT本质上是通过降低特效渲染分辨率，减少特效绘制带来的GPU填充压力，因此对于Overdraw较高、覆盖范围较大的特效，通常能够带来比较明显的性能收益。 在实际项目中，如果某些特效长期存在较高Overdraw，或者在战斗场景中频繁出现，可以考虑根据特效复杂度、Overdraw情况等制定自动开启策略。例如，当某类特效达到一定开销阈值时，自动使用1/4 RT方案，在保证视觉效果的同时降低GPU消耗。不过，需要注意的是，1/4 RT主要解决的是特效自身带来的GPU压力，而降低场景相机分辨率影响的是整个画面的渲染成本，两者优化范围不同。 因此，在决定是否降低场景分辨率前，建议先确认当前GPU瓶颈来源。可以结合UWA GOT Online报告重点关注： GPU Clocks是否长期处于较高水平，判断设备GPU负载情况； Overdraw是否随着特效数量增加明显升高，确认是否存在大量透明特效叠加导致的填充压力； 开启1/4 RT前后，GPU Clocks、帧率以及设备发热情况是否有实际改善； GPU负载变化是否与特效集中出现的战斗场景保持一致。 如果开启1/4 RT后，GPU压力和发热已经得到明显缓解，通常没有必要继续降低场景分辨率。因为降低分辨率属于更偏整体性的优化手段，会直接影响画面清晰度，需要谨慎使用。只有当特效优化完成后，GPU负载依然较高，例如场景渲染、后处理、UI以及其他绘制开销仍然占据较大比例时，再考虑通过降低分辨率、调整画质档位等方式进一步降低GPU压力。最终目标是在保证视觉表现的前提下，找到GPU消耗、画面质量和设备发热之间的平衡，而不是单纯降低某一项指标。 无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。 封面图来源于网络 今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。 UWA官网：www.uwa4d.com UWA社区：community.uwa4d.com UWA学堂：edu.uwa4d.com 官方技术QQ群：793972859
小游戏发热的系统排查与性能调优实战
1）小游戏发热问题的系统排查法 2）iOS高性能模式下的内存与合批博弈 这是第482篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。 实战案例 Q：我们项目最近发热问题比较严重，玩家反馈集中在“玩一段时间后手机发烫”。我们用UWA GOT Online跑了一份小游戏性能报告，针对里面CPU占比偏高的几个模块做了一轮优化，但实际跑下来降温效果并不明显，想问一下，除了CPU模块本身，是不是还有别的维度漏看了？这种发热问题该怎么系统排查？ A：移动端发热可以从CPU、GPU、屏幕、网络四个维度切入。屏幕和网络我们也做过测试，对发热确实有贡献，但很难单独拆出来，真正能动手优化的还是CPU和GPU。 图源：微信官方文档 受小游戏接口限制，UWA GOT Online小游戏报告暂时拿不到CPU/GPU温度数据，我们改用UWA Gears工具补测后发现，CPU温度持续高于GPU，所以这个项目的发热主导确认是CPU。接下来拆解GOT Online的CPU数据，可以看到问题主要集中在三类结构性负载。 第一类是战斗逻辑模块。高负载场景下出现明显的帧级Spike，单帧耗时甚至超过100ms，本质是战斗Tick在复杂场景中的集中执行，造成阶段性压力堆积。 第二类是渲染模块。整体平稳，但大厅与武器、复杂UI界面耗时升到20ms左右，主要来自半透明对象渲染造成的Overdraw，以及UI嵌套过深导致的Batch Break，DrawCall超过250的UWA推荐阈值。 第三类是UI模块。均值耗时8-9ms（高于UWA推荐值），CanvasRenderer.SyncTransform调用频次异常高（峰值达940次），根因是UI状态切换过于频繁（SetActive/Instantiate/销毁），重建链路反复触发，形成尖刺型耗时。 除上面三类主要负载，CPU里还有一个容易忽略的次级开销“物理空转”，报告里Physics 3D的Overlaps调用次数全程为0，说明项目没触发过3D物理碰撞（实际可能只用到Physics 2D的射线检测或重力），但物理模块依然按默认Fixed Update模式持续Step。如果业务上不依赖自动模拟，可以把Update Mode改成Script，如果还需要射线检测，再勾上Auto SyncTransform保证Transform实时同步。 回到这个项目，发热的本质不是单点CPU过高，而是CPU内部三个模块的负载叠加，逻辑代码的实例化Spike、渲染的Overdraw与Batch Break、UI的重建过频。物理空转是顺手处理的小尾巴，GPU整体只是次级贡献。 实战案例 Q：我们iOS端开了高性能加模式，图标比较多，如果都打到一张图集里，会导致内存占用偏高，你们之前有没有遇到过这种情况？有什么优化建议吗？ A：在这种配置下，图集带来的“内存增长”，需要先区分是工具统计层面的变化，还是实际会影响闪退风险的系统级压力变化，否则容易出现判断偏差。 在iOS高性能模式下，纹理相关内存的分布机制与Unity Heap并不完全一致，部分纹理资源会进入系统图形层（GPU/iOS图形内存池）进行管理，因此在小游戏侧看到的内存增长，并不一定完整等价于最终的进程级内存压力。 小游戏的闪退判定也不是只看Unity Heap总量，而是取决于整体内存压力来源，包括WebContent进程RSS、Native内存占用、GPU纹理压力以及系统Jetsam机制的综合结果。因此，图集带来的内存变化本身，并不必然直接转化为闪退风险。 反过来看散图，省的是内存，但代价在CPU和渲染链路上。散图是按需加载的（比如100张图只用20张，其余不会进入内存），从“单次内存占用”来看确实更轻。但碎片化资源会导致UI合批被打断，纹理切换增加，同时UI提交阶段CPU开销上升，这部分开销在小游戏环境下往往比单纯的纹理内存增长更容易影响帧率与发热。 图集方案则是另一种权衡：它会带来一次性的加载成本，包括贴图解码与GPU上传，同时内存占用更集中。但换来的收益是更稳定的合批效果、更少的纹理切换，以及更低的UI渲染提交CPU开销。 所以在图标较多的UI场景下，在iOS高性能加模式+无Read/Write纹理的前提下，我们一般仍然建议优先使用图集。首次加载虽然有额外开销，但在稳定运行阶段，整体CPU成本和渲染稳定性会更优。从工程角度看，这里的关键不是“图集是否更省内存”，而是它在CPU渲染链路上的收益通常会覆盖内存集中带来的成本。 无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。 封面图来源于网络 今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。 UWA官网：www.uwa4d.com UWA社区：community.uwa4d.com UWA学堂：edu.uwa4d.com 官方技术QQ群：793972859
不管项目本身是否重度，性能调优永远是上线前的必经之路。优化性能，不仅需要足够深度的分析来定位问题瓶颈，也需前瞻性的保障措施来缓解后续的优化压力和性能风险。因此，我们推出了UWA GOT Online，并且很荣幸地在推出后得到不少朋友的积极反馈。 关于UWA GOT Online UWA GOT是UWA推出的本地性能测评工具，它方便研发团队在本地真机测试，并能在编辑器中搭建本地服务器查看性能数据。UWA GOT Online是基于其本地测评模式上的线上同步功能，研发团队可以将本地测评的数据快速同步到UWA官网，生成在线测评报告。 除了“本地化”和“快”这两大天然优势，我们目前提供了四大性能检测模式：总体性能检测、Mono堆内存分析、运行时资源检测和Lua性能分析来满足大家的优化需求，下面小编就带大家一一浏览。文末附上UWA GOT Online的使用攻略哦！ 以下是四大模式的核心功能和特色，点击对应的条目可以查阅详细的功能说明。 CPU性能检测 全方位的引擎模块剖析（渲染、物理、粒子、UI、动画和加载，一个都不能少） UWA API 提供（锁定你关注的性能细节，让其无处遁形） Mono堆内存检测 Mono具体分配详情（对代码堆内存的分配一目了然，还有贴心的倒序功能哦） Mono堆内存泄露定位（代码泄漏风险？用这个模式捋一遍就明了） 运行时资源检测 具体资源使用情况检测（详细展现主流资源的具体运行情况） 资源内存泄露定位（不同采样点随心比较，科学排查泄漏风险） Lua性能检测 LuaCPU性能测评 （深度、全面的调用堆栈，直接锁定性能瓶颈） Lua内存检测（无论是内存分配过大还是内存泄露，用它就对了） 凭借“本地化”和“快”两大天然优势，UWA GOT Online能让项目人员快速执行项目的测试需求，以更友好、更易用的展示方式呈现给开发者。同时，依托于报告中具有针对性的分析建议，研发/测试人员也能定期地对自己的项目版本进行性能跟踪，一旦发现某个版本上的某个重要性能指标出现了问题，就能及时反馈给研发团队进行完善和修复。 UWA GOT Online截图 项目的研发需要持续改善，而解决问题的最佳时机就是在我们看到问题的当下，从而极大减少后期的优化时间，降低后期堆积的性能压力的风险，并加快游戏的整体研发进度。 以上就是UWA GOT Online功能的不完全说明，更多功能欢迎大家登陆www.uwa4d.com，在“本地测试 / UWA GOT Online”中查看各个模式下的Demo报告。 UWA GOT Online使用攻略 1、我可以直接用UWA GOT Online吗？具体操作方式如何？ 首先你需要拥有一个灵活的本地化测评工具UWA GOT； UWA GOT Online的具体操作方式为：本地真机测试完毕后，将测试数据传输到UWA官网进行查看。 2、UWA GOT和UWA GOT Online功能上有哪些区别？ 配置还是很不一样的哦，后者包括更广度的检测模式/功能，包括Lua性能、CPU性能模块分析、性能简报、优化建议和版本对比等功能，具体可参见此处。 3、想试试看怎么入手？ 登录UWA官网的个人账号，选择“立即体验”即可开始试用。 4、UWA GOT Online具体效果如何？ 截止目前，我们收到不少团队的积极反馈，并获知该功能帮助他们改善了测试机制。 UWA报告Tips 性能简报—小白都能秒懂的定位方法！ 优化时间不充裕？快快让性能简报帮你抓重点！ 突然卡顿不知为啥，卡顿分析里有大秘密！ 解决疑难杂症必备：堆栈分析，从此开启专家把脉模式！ 重要引擎性能参数，把握项目健康的几个核心指标！ 内存过高，资源占用的几个大头要盯牢！ 粒子数量过高，看看是否都物尽其用了？ 特效复杂，使用Overdraw排查问题就对了！ Mali Counter 分析，高效定位发热、耗电现象 Timeline视图分析，直观显示卡顿的时序 Lua-Mono对象引用，解决Mono内存泄漏的顽疾 Shader解析耗时高，原来是冗余问题在作怪 资源实例化&激活，想要运行表现平滑，这个技巧不能少 Mipmap分析，优化纹理分辨率，每个像素用到刀刃上 自定义参数，随时把关重要参数走势 GC调用分析，GC耗时、调用频率一览无余 渲染模块性能分析，快速定位，一目了然！ Shader.CreateGPUProgram 优化分析，特别重点关注游戏战斗中的耗时！ Shader.Parse优化分析，优化Shader策略，避免重复加载卸载！ Unity卸载优化分析，场景切换时间太长，如何有效优化？ 物理模块优化分析，一招教你把耗时清零！ 网格内存优化，降低网格内存一二三，走你！ 纹理资源内存优化（一），纹理太大还是冗余？这些小技巧必备！ 纹理资源内存优化（二），优化缓存策略，巧妙降低纹理内存！ GPU图元处理，节省GPU图元算力，减缓带宽能耗压力！ GPU Shader Cycles，锁定Shader复杂度瓶颈，针对性排查优化！ 温度细分为CPU、GPU、 电池，定位压力来源，确认发热原因！高效优化的小技巧~ AssetBundle驻留信息，AssetBundle的驻留情况怎么看，你学会了吗？ 场景分隔线，精细化数据分析，你有没有用起来呢？ Mono泄漏，如果判断定位堆内存性能点？内存泄露分析来帮你！ Mono倒序调用，快速定位堆内存深层子函数，定位堆内存问题瓶颈！ Lua倒序调用，定位堆内存分配、高耗时原因，精确到代码行！ Lua端Mono对象引用，查看Mono对象引用情况，避免Lua端造成的堆内存泄漏！ UWA性能简报页更新！新增性能评级，项目瓶颈一目了然！ 性能总结页改版啦！新增Jank帧和同步等待耗时统计！ 如何进行特效优化？试试GOT Online Overview模式吧！ GPU负载在Mali芯片下都有哪些参数？如何优化？ GPU负载在Adreno和PowerVR芯片下代表什么？要怎么来看？ 提高场景GPU缓存率，节省带宽和能耗！ 当GPU压力较大时，要如何选择纹理过滤？ 查看测试时的设备功率信息，定位发热耗电情况！ 线程耗时统计，支持子线程数据统计，快速定位线程压力情况！ 性能简报页，快速跳转至问题界面，定位问题不迷路~ 如何快速判断项目压力情况？试试GPU同步模块吧！ 函数堆栈自定义面板，除了函数的耗时情况，有时调用次数也是需要关注的重点！ Overview Timeline，UWA SDK 支持可视化配置啦！开关模式更便捷！ Overview API/堆栈细节，如何获取更详细的堆栈信息？快打开API和堆栈细节！ GOT Online Overview模式中获取Resource数据，告诉你一个定位资源问题的小技巧~ GOT Online Overview模式中获取Lua数据，打开Lua数据采集，精准定位Lua问题！ 三种开启GOT Online测试的方法，总有一款适合你~ “回归测试”、“CPU压力较大”、“内存压力较大”这三种不同场景下 使用GOT Online测试时UWA推荐的参数开关配置
本期聚集话题：Texture2DArray、远距离物体的物理模拟、粒子系统的CPU/GPU开销、如何读取StreamingAssets目录下的压缩包... 新年伊始，随着大家紧锣密鼓地开始了工作，UWA每周推送的知识型栏目《厚积薄发 | 技术分享》在节后的首个工作日迎来了第100篇！今天，我们继续为大家精选了5个和开发、优化相关的问题，建议阅读时间15分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 粒子系统 Q1：请问粒子系统的消耗如何区分呢？哪部分是在CPU哪部分在GPU呢？一个空粒子（禁用所有模块，包括Render）会有消耗吗？如果有消耗，会体现在哪部分呢？ 就目前的Unity引擎的原生功能而言，粒子系统中的状态更新（粒子的位置、朝向、触发事件等）均为CPU端开销，具体表现在ParticleSystem.Update和ParticleSystem.EndUpdateAll等函数中。具体可以查看UWA性能报告中的这两张图： 相关链接 相关链接 同时，粒子系统在渲染时也需要在CPU端进行准备，比如粒子系统的Culling和Draw Call操作等等，这些也都属于CPU端开销，如下图所示。 而GPU端的耗时则与其他Mesh渲染无差，主要和ALU、Bandwidth和Overdraw相关。但与其他一般场景渲染不同的是，粒子系统在GPU端的压力往往在Overdraw中进行体现，如下图所示： 上图来自《极无双》的性能详细报告，大家可以参考完整数据来加深这部分的理解： 一个空粒子其自身开销理论上很小，但UWA这边暂时没有做过测试，题主可自行做一些测试，绝知此事要躬行。 此问答来自于UWA 问答社区，如您对该问题仍有疑问，欢迎转至社区进行进一步交流。 资源管理 Q2：我用的是Unity 5.5 版本，由于项目采用LZ4格式的AssetBundle，如果直接放进StreamingAssets下，包就太大了。现在想把所有的AssetBundle打成一个压缩包，再放进StreamingAssets，让玩家在第一次安装时，拷贝到PersistentDataPath目录下再解压。但目前不知道怎么读取Android平台下的StreamingAssets目录下的压缩包，希望能得到指导，感谢！ 我们是直接使用的C实现的unzip库，启动游戏的时候就常驻打开Apk，后面都直接通过unzip库解需要的文件到缓存目录来读取，读完了，不用就定期做一些清理。 感谢Lujian提供了以上回答 在Unity的API里应该就只有WWW（新版本里对应UnityWebRequest）能访问非Bundle文件了，但这个接口是异步的，另外.bytes操作会产生较高的堆内存分配，容易撑高堆内存峰值。所以，有的做法是通过Android的Java API来读取，可以参考下雨松MOMO的这篇文章里用的Java接口：https://www.tuicool.com/articles/fAnYJ3I 此问答来自于UWA 问答社区，如您对该问题仍有疑问，欢迎转至社区进行进一步交流。 资源管理 Q3：我用的是Unity 2017.2f版本，我们Prefab里Image元素直接引用的是Sprite Atlas文件夹里的图片，现在把Prefab和Sprite Atlas分别打到两个不同的AssetBundle里，并且去掉了Sprite Atlas的include build的选项。拿工具查看Prefab和Sprite Atlas的Bundle发现，Prefab所在的Bundle会把Image元素引用的那张Sprite图也打进来，而Sprite Atlas所在的Bundle里不但包括了这个Atlas图，并且原图都在这个Bundle里。这是为什么呢？ UWA测试发现Unity 2017.2和2017.3都存在题主说的问题，不过也都能通过一些操作绕过这个问题。先说一下个人认为正常的现象： include in build不应该影响Bundle的打包行为，且Prefab的Bundle中始终不应该有SpriteAtlas存在。但是如果不开启include in build，正常加载完两个Bundle，且实例化Prefab后，Sprite不会显示，因为需要做一下late binding。 接下来说一下碰到的这个Bug： 如果在第一次（打之前清空Bundle目录）打Bundle时，include in build开启了，那么atlas会被打包进prefab的bundle中（即题主的问题）； 但如果在第一次打Bundle时，include in build没开启，那么就是正常现象（Atlas不在prefab的Bundle中）； 有意思的是，在第二次打Bundle时，不论include in build有没有开，结果都和上一次打包一样。所以，绕过去的方法是： 先清空Bundle目录，关闭include in build打一次Bundle；再开启include in build打第二次。得到的结果就是Atlas不在Prefab的Bundle里，同时Atlas的include in build是开启状态的。 题主可以按这个步骤做个尝试。 此问答来自于UWA 问答社区，如您对该问题仍有疑问，欢迎转至社区进行进一步交流。 渲染 Q4：我从文档上来看，GLES3 Metal 已经可以支持了。最容易想到的就是地形的splat层，如果是四层splat，那么就可以用一个Texture2DArray来代替，好处是减少了bind消耗。相关的知乎链接，其中根据龚大的意思来看，似乎还可以减少splat采样次数，但根据自己的测试和理解来看并不行，因为Texture2DArray 的slice之间并不会 blending，不知是不是我理解问题。 我使用一个Texture2DArray来代替4层的Splat地形，从XCode上看开销，并没有任何的减小，那目前来看这么做地形的意义就不是很大了。AssetStore上有一个插件叫MegaSplat就是使用Texture2DArray来达到很多层混合。目前想到的Texture2DArray还有一个可以利用的地方是场景贴图。比如场景用到了多张1024的贴图，或者多张lightmap，原来由于贴图不同导致StaticBatching无法合并，现在就可以使用Texture2DArray来做了。还有比如UI上的icon之类的，可以合并到一个Texture2DArray来达到DrawCall的合并。 目前Texture2DArray最不利的地方是：只能通过代码来创建，没有编辑器的支持。如果要离线制作Texture2DArray，就需要为不同的平台准备多份资源了。请问大家有没有Texture2DArray的经验可以分享呢? UWA研究了Texture2DArray，看起来它是将多个2D的Texture组合起来变成一个对象，所以在使用的时候只需要绑定一次，就可以采样多个2D Texture。的确如题主所说，采样的时候还是一次只能采样一个指定的slice，blend也需要另外的Shader代码来完成。 题主说了：其中根据龚大的意思来看，似乎还可以减少splat采样次数，但根据自己的测试和理解来看并不行 我感觉他的意思可能是：并不是每次采样必须把所有的slice都采了，而是可以只采其中一部分。估计原本想表达的是一次采样只采一个slice。 我使用一个Texture2DArray来代替4层的Splat地形，从xcode上看开销，并没有任何的减小，那目前来看这么做地形的意义就不是很大了。 如果单从性能上看，Texture2DArray比Texture2D的确只是减少纹理绑定的开销，然后在游戏引擎中可能会对合批产生影响。其他的做法跟普通Texture2D是一样的。Texture2DArray比Texture3D在LOD处理上不同，Texture3D会减少slice，这并不是渲染Terrain时想要的。然后Texture2DArray在filter的时候只会在U,V上做，而Texture3D还会在d上做，所以这部分Texture2DArray也比Texture3D性能更好。综合这些因素可能是推荐渲染Terrain使用Texture2DArray的原因吧。题主通过实验说明Texture2DArray渲染地形没有减少开销，也有可能是因为一般一个场景就一个地形，从绑4张纹理变成绑1张就少了几毫秒，而且也不是每帧都绑，所以从整体效果上看不大出来。 UWA做了个简单实验验证了一下，下图分别是用Texture2D和Texture2DArray渲染地形结果和GLES API调用。实验设备为三星S6。 Texture2D： Texture2DArray： 其中，GLES API调用图中红色框表示纹理绑定的API调用，绿色框表示渲染API调用。WT表示了该API调用的耗时，单位为纳秒。从Texture2D图中可知一共有5次纹理绑定，分别对应于材质中的5张纹理绑定，而Texture2DArray图中只有两次调用，分别是splat纹理和四层混合纹理的绑定。从图中可知一次glBindTexture的耗时大约为1000~10000ns，即最多0.01ms。因此，三次glBindTexture加上三次glActiveTexture也最多0.06ms。所以看不出来。 此问答来自于UWA 问答社区，如您对该问题仍有疑问，欢迎转至社区进行进一步交流。 物理 Q5：我们正在开发一款超大地形的MMO游戏，场景中的角色或者怪物较多，请问Unity引擎是否会对远处（500m或1km外）的GameObject进行物理模拟？是否有设置可以降低这部分GameObject的物理模拟开销？ Unity引擎确实会对远处的GameObject进行物理计算，只要该物体是Active、挂载Rigidbody（Character Controller）组件并且没有Sleeping的。Unity引擎并没有原生功能可以根据距离的远近来调整物理系统的计算，不过题主可以自行来进行控制，比如通过Culling Group或者自行计算GameObject的远近来控制Rigidbody组件的Active和Deactive，从而降低整体的物理系统耗时。 此问答来自于UWA 问答社区，如您对该问题仍有疑问，欢迎转至社区进行进一步交流。 今天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，我们早已在UWA问答网站上准备了更多的技术话题等你一起来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。 官网：www.uwa4d.com 官方技术博客：blog.uwa4d.com 官方问答社区：answer.uwa4d.com 官方技术QQ群：793972859（仅限技术交流）
今天我们为大家带来由上海非钰数码科技的FPS手游《战地先锋》的 UWA测评报告分析。该游戏在各种档次的移动终端设备上，无论是画面表现力，还是性能开销都非常优异。在此，我们将对该款游戏的性能数据进行深度剖析，希望通过这篇文章可以让大家对移动游戏各个模块的运行效率有更为深刻的认知，并对大家的项目研发有所帮助。 一、CPU性能 该游戏在CPU占用方面的性能非常不错，下图为该游戏在红米Note2 设备上按照剧情进行游戏时的性能数据。可以看出，在红米Note2 上运行的24979帧中，超过33ms的帧数占比为4.3%，超过50ms的帧数占比为1.2%。考虑到切换场景时资源加载的开销，一款游戏如果超过33ms的帧数占比低于10%，则说明该游戏在绝大多数时刻的运行中都是非常流畅的。 通过进一步统计，该游戏的CPU性能超过了84%的红米Note2设备上的测试游戏，其能耗更是低于91%的同设备测试游戏。 其整体CPU性能的优秀表现与其各个模块的合理使用是分不开的。下面，我们就详细讲解一下其CPU性能方面的亮点之处。 1、渲染模块 通过UWA性能测评报告，我们可以看到该游戏详尽的渲染模块性能开销。该游戏在红米Note2设备上运行时的渲染模块CPU开销如下图所示。通过统计，半透明物体渲染的CPU消耗均值为1.5 ms，主要集中在 0.7~2.7ms 范围内（5%~95%）。不透明物体渲染的CPU消耗均值为1.8 ms，主要集中在 0.2~4.6ms范围内（5%~95%）。 Draw Call峰值为340，虽然峰值较高，但仅在场景切换处出现，这是因为项目在动态加载后通过代码调用StaticBatching的方式来合并Draw Call，所以可以看到Draw Call数量在进入场景后迅速回落。同时，Draw Call数量主要集中在 48~179 范围内（5%~95%），属于合理范围之内。 下图为该游戏在红米Note2上的具体CPU性能堆栈。可以看到，该游戏在红米Note2上无论是不透明开销还是半透明开销均处于较低水平，这得益于研发团队对于场景模型、蒙皮网格和UI的控制十分得当。 美中不足的是Shader.SetPass稍高，这主要是渲染模块中RenderState的切换较为频繁所致，对此，建议大家对场景中的Material数量进行控制，具体可以参考：《使用MaterialPropertyBlock来替换Material属性操作》 2、UI模块 该游戏在红米Note2设备上运行时的UI模块CPU开销如下图所示。该游戏使用UGUI作为UI界面的解决方案。经过统计，UI模块总体的CPU占用均值为1.9ms，主要集中在0.1~3.6ms范围内（5%~95%），属于合理范围之内。 其均值高于70%的行业数据，这是因为该项目使用的是Unity 4.7版本进行开发，该Unity版本中，UGUI并没有像Unity 5.3版本以后将部分拼合操作放到子线程中进行。在这一点上，Unity 4.x的UGUI性能较之5.3+版本确实要多一些性能上的开销。堆内存平均每帧分配为5.5B，仅高于5%的行业项目，这说明该游戏UI界面的制作及UI重建的影响范围非常合理。目前，UWA推荐UGUI模块中，平均每帧堆内存分配尽可能控制在2KB以下。 从下图中可以看出，Canvas.SendWillRenderCanvases在不同的运行时刻均出现CPU高值，但通过运行截图可以看到，其共同特点是CPU耗时高值均发生在画面底层的UI选人界面出现时。因此，该UI界面的出现或相关操作极有可能是引发Canvas.SendWillRenderCanvases CPU过高的原因，建议研发团队对该界面进行进一步检测。 3、动画模块 在UWA测评报告中，该游戏运行时的动画模块CPU开销如下图所示。 可以看出，除进入场景时出现CPU高值外，其在战斗副本中的CPU开销均控制在较低水平。Animator.Update的CPU均值为1.8ms，主要集中在0.1~3.4ms区间内，其性能较为优秀，高于28%的行业项目。同时，MeshSkinning.Update的CPU均值为1.8ms，主要集中在0.1~3.4ms区间内，高于21%的行业数据。 同时，经过进一步检测发现，其进入副本时的CPU高值均为lhAnimatorEvent.OnEventCallback回调函数所致，具体的CPU耗时堆栈如下图所示。通过此堆栈可知，其耗时主要为UI界面的加载耗时，且进一步通过资源管理信息可知其主要开销为luaUI_PK(Clone)的Active操作和luaUI_Hall(Clone)的Deactive操作所致。因此，建议研发团队可进一步检测该UI的制作是否合理，并对其进行完善。 4、GC调用 该研发团队对于GC调用频率控制得非常出众，游戏在运行过程中，GC调用频率为1921帧/次，优于目前95%的行业内游戏。 一般来说，如果一款项目的GC调用频率可以控制在1000帧/次以上，就已经相当出众了。该游戏的GC调用频率如此优秀，主要得益于研发团队对于项目代码堆内存的控制。下图为游戏运行25000帧的代码堆内存具体分配情况。对于使用UGUI的游戏来说，我们建议游戏运行每1万帧中，Top10函数的堆内存分配总和小于30MB，而该游戏运行25000帧，其Top10函数的堆内存分配总和才26.91MB，足见该团队对于堆内存分配的理解非常深刻。 二、内存模块 《战地先锋》在内存上的表现如下图所示。总内存峰值达到249MB，Mono堆内存峰值为32.5MB。243MB的总内存分配相对来说略高，研发团队可尝试在低端机器上对资源进行进一步控制，从而降低低端机器上的内存占用。 1、Mono堆内存 从上图可知，该游戏的总体Mono堆内存控制得很好，在25000帧中，Mono的堆内存峰值仅为 32.5MB。该值属于合理范围之内（<40MB）。 但是，从走势上来看，其堆内存的占用在游戏运行过程中持续处于上升趋势，对此，建议研发团队对缓存池进行进一步检测，排查项目是否存在堆内存泄露的隐患。 2、资源内存 经过统计，该游戏的纹理资源数量峰值为618个，内存占用峰值119.5MB。纹理内存占用较高，目前高于82%的行业项目。经过统计，在内存占用峰值处，ETC1格式纹理占有221个，Alpha8格式纹理占有5个，RGBA32和ARGB32格式纹理共占有120个，RGB24格式纹理占有87个，其余为RGBA16格式纹理。 对于RGBA32、ARGB32的纹理，我们建议在视觉效果可以保证的情况下，尽可能使用ETC1格式纹理（Android平台）进行替换，不仅可以达到更小的内存占用，同时可以获得更快的加载效率。而对于无法进行硬件压缩的纹理，可以通过Dither方法尝试将其转换成RGBA16格式的纹理，具体做法可以参考此篇文章。 其他资源的内存占用情况如下： Mesh资源： 内存峰值高于41%的项目 AnimationClip资源： 内存峰值高于40%的项目 AudoClip资源： 内存峰值高于73%的项目 AudioClip的内存占用较高，高于73%的行业项目。对此，研发团队可尝试将内存占用较高的音频资源通过Stream的方式来进行加载，该方式可极大降低AudioClip资源的内存占用。 以上则为《战地先锋》游戏在CPU性能和内存管理方面的具体使用情况。优秀的CPU性能、非常少的堆内存分配以及引擎模块间的合理使用，足以看出该研发团队非常深厚的技术功底和对于引擎相当优秀的把控能力。 三、性能优化、进无止境 该游戏在Shader加载和GameObject Active/Deactive方面仍有一定的提升空间。在此，我们对其进行罗列，希望同样可以帮助到大家的研发项目。 1、Shader加载 目前，游戏副本切换时存在较高的Shader解析（Shader.Parse)开销，如下图所示。通过具体资源信息中的Shader资源分析，可以定位是如下几个Shader的加载耗时，对此，建议研发团队尝试对频繁使用的Shader进行预加载并常驻内存，从而减少不必要的Shader重复加载耗时。 2、GameObject Active/Deactive调用次数过高 该游戏在运行过程中，GameObject Active/Deactive的调用次数过高，在游戏运行的25000帧中，Active调用268952次，Deactive调用393490次。其调用的具体次数如下图所示（下图为游戏运行每10帧进行一次Sample，而每个Sample的数值为前10帧中Active/Deactive调用次数的总和。 其中，GameObject的Active/Deactive Top10资源信息具体如下所示，因此，研发团队可通过下表直接对频繁进行Active的GameObject进行完善。Deactive的完善亦然。 频繁的Active/Deactive操作不仅会造成CPU的浪费，同时，它还很可能间接造成更大的CPU耗时，比如Animator.Initialize耗时。该游戏的Animator.Initialize调用较为频繁，且耗时较高，如下图所示，而这就是频繁的Active/Deactive操作所造成的结果。因此，对于GameObject不必要的Active和Deactive操作进行控制，是非常有必要的。 最后，非常感谢《战地先锋》研发团队对 UWA 的认可和支持。感谢他们乐于将项目性能数据与大家一起分享，让更多的研发团队了解到一款性能优秀的3D移动游戏在各个模块上可以做到怎样的程度。同时，也欢迎更多的开发团队可以与我们一起来分享你们的性能数据，让更多的游戏开发者受益！ PS：安利这款FPS手游，在TapTap上已经获得了8.6的高分，并将于9月7日在14个安卓渠道同时开启付费删档测试，欢迎大家来预约！ 关于UWA 由侑虎科技开发的游戏/VR应用性能优化平台，目前提供 1）性能检测与优化 2）资源检测与分析 3）UWA GOT 三大工具。同时，我们也会为大家开发更省心的功能，希望通过它们可以减少开发者反复测试定位问题的时间，从而将更多的精力集中在项目开发和解决问题中，能为大家项目研发省下的任何一分一秒，都是UWA团队的骄傲。
过去的一年，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/Animation.Update的开销在中低端设备上的耗时呈现逐步升高趋势，对此，建议研发团队重点查看本篇文章的最后一节，我们提供了进一步完善和优化动画模块性能的相关方法。 5、粒子模块 严重程度：普通 1）粒子系统的CPU开销普遍很低，且近一年来下降趋势较为明显。 2）粒子系统的数量使用仍然较大，这会造成较高的内存占用，虽然2016 Q4和2017 Q1已经大幅下降，但2017 Q2随着新项目的增加，粒子系统的使用数量又开始大幅增加。MOBA项目中存在粒子系统数量较大的原因，主要是特效和技能的缓存所致。为了保证战斗时（特别是团队时）技能释放的流畅性，研发团队会选择在场景加载时即缓存英雄的所有技能，因此，MOBA游戏在战斗副本中会出现较大量的粒子系统缓存现象，特别需要研发团队关注。 三、MOBA手游内存模块开销分析 1、总体内存 严重程度：地狱 可以看到，MOBA游戏总体内存在2016年上升趋势明显，而在2017年内存占用则较为稳定。为了兼容市面上的中低端机，Unity引擎的实际内存占用需要尽可能被控制在300MB以下，这点是各大MOBA研发团队今年优化阶段的重中之重。 2、总体堆内存 严重程度：地狱 堆内存使用在2016年大幅下降，但今年随着新项目的涌入，其上升趋势明显，建议研发团队重点关注。对此，UWA建议重点关注以下几点： 1）严格关注配置文件的使用，避免一次性加载过大的配置文件而撑大堆内存； 2）不少项目的堆内存增大是由于热更新所致。因此，对于过大的数据Data的使用，建议通过分帧进行，并及时进行GC回收； 3）避免不必要的代码堆内存分配，虽然是老生常谈，但从趋势上可以看出，大多数研发团队仍需加强重视。 项目的内存占用很大一部分来自于资源的使用，下面我们将对项目中主流资源的使用情况进行分析。 3、纹理资源内存 严重程度：地狱 1）纹理内存峰值主要分布为 40~147.3 MB。 2）从走势中可以看到，随着MOBA项目的精品化趋势，其纹理内存占用也大幅提升，虽然2017Q2稍有下降，但依然拥有较高的内存占用。 4、网格资源内存 严重程度：噩梦 网格资源内存峰值主要分布为 14.1~ 65.9 MB，且上升趋势明显。对于场景、角色的网格资源控制，是研发团队在后续研发团队中需要关注的重点。 5、动画资源内存 严重程度：普通 动画资源内存峰值主要分布在9.2~38.5 MB以内，从走势中可以看出，2017Q1的内存占用达到47.1MB，而2017Q2的内存占用迅速回落到18.4MB。经过进一步分析，其主要原因如下： 1）2017Q1大量新游戏的涌入直接提升了该阶段的内存占用； 2）2017Q2动画资源新优化方式的推广，大量研发团队从中受益，从而内存占用大幅回落。关于动画资源的优化建议，建议研发团队查看UWA之前推送的技术文章《Unity动画文件优化探究》。 6、Shader资源内存 严重程度：噩梦 Shader资源内存峰值占用主要集中在0.1~7.9 MB区间之内。需要提醒的是，研发团队需要密切关注Standard Shader的使用情况，因为该类Shader在解析时不仅会造成较高的CPU开销，同时会造成较大量的内存占用。 7、RenderTexture资源内存 严重程度：普通 与MMORPG和ARPG手游不同，RenderTexture在MOBA游戏中的内存占用保持在较低的水平，在2016Q3出现41.2MB的高值后，迅速回落，并稳定在25MB左右的内存占用。 8、粒子系统资源内存 严重程度：噩梦 与粒子系统的开销一致，其内存占用也在2017年呈现持续大幅上升趋势。粒子系统的内存占用主要与其内存中缓存的数量相关，对此，建议研发团队在后续研发中对粒子系统的使用进行密切关注和严格控制。 四、MOBA手游资源管理分析 在资源加载方面，AssetBundle.Load是项目中的主要加载方式，且主要集中在场景切换处。就目前的MOBA游戏而言，绝大多数项目使用的加载方式仍然是同步加载。 1）New WWW是MOBA项目中AssetBundle的主要加载方式。 2）LoadFromFile(Async)的使用在2017 Q2上大幅增加，但整体仍然较少，仅占10.5%。这主要是因为市面上仍有不少MOBA项目使用的是Unity 4.x版本所致。但如果您的项目目前是使用Unity 5.x版本开发，建议尝试升级到Unity 5.3版本以后，并通过LoadFromFile(Async)的方式进行加载。 Instantiate/Destroy和Active/Deactive调用次数较高，需要研发团队根据自身项目情况时刻注意： 1）由于Active/Deactive每次调用的CPU开销不大，且不会造成崩溃、闪退等问题，所以研发团队极易忽视这两项操作所带来的性能问题，因而出现了游戏运行1万帧Active/Deactive上万次调用的情况。因此，此处存在着很大的性能浪费； 2）Instantiate/Destroy的调用次数同样较高，但与MMORPG和ARPG游戏不同的是，Instantiate调用主要发生在场景切换处，大量GameObject在Instantiate实例化后被缓存使用，而为了保证战斗时的足够流畅，战斗过程中研发团队大多通过Active/Deactive操作来代替Instantiate/Destroy操作； 3）Destroy操作大幅高于Instantiate操作。经过进一步分析，这主要是由于当前MOBA项目中NGUI使用占比较高所致。在对NGUI制作的UI界面（比如血条等HUD）进行Deactive操作是MOBA战斗过程中较为频繁的操作，而此Deactive操作会引发UI底层Destory相关的Material操作。所以会出现Destory次数次数大幅高于Instantiate次数的情况。 五、UWA 对于MOBA手游研发团队的建议 MOBA是移动游戏研发难度较高的品类，其对于性能的严苛要求可谓达到了“寸土寸金”的地步。目前国内仍然在开发MOBA类移动游戏的，也都是技术实力与情怀兼备的团队。正因如此，MOBA游戏在很多模块中的性能表现已经较为优秀。对此，我们对于MOBA项目研发团队的优化建议如下： 1、渲染方面，Draw Call的控制技术已被MOBA研发团队所熟练掌握。随着玩家的设备质量提升，建议研发团队考虑GPU Instancing技术，该功能已经在Unity 5.5版本以后被支持，由于MOBA项目的特殊性，研发团队可以考虑将其应用在场景中的草、树木等大量重复物体重，从而进一步降低渲染模块在CPU端的开销。但是，需要注意的是，GPU Instancing的技术虽然可以降低Draw Call，但仍需要节制使用，因为其在移动设备上的GPU和能耗方面的压力可能会让你大吃一惊。 2、UI方面，与其他游戏类型一样，UI网格重建开销在未来相当长的一段时间内仍然是研发团队头痛的问题，UI优化的原则非常简单：动静分离，但真实操作起来则是非常困难。90%项目中的UI性能问题是由于动静元素没有分离导致，但没有任何两个项目的具体原因是一致的。这是UI性能优化方面非常困难的主要原因。 3、逻辑代码方面在上述报告中并没有特别谈及，这主要因为MOBA类型的项目，其在战斗时的逻辑代码开销主要为自身开销，即项目自身的AI、同步等操作，其主要包括小兵和怪物的攻击搜索、寻路操作、位置和状态的持续更新等等。对此，建议研发团队关注其AI操作的调用频率和单位开销是否合理。 4、动画模块方面，随着MOBA游戏中怪物、小兵和英雄的角色复杂程度越来越高。建议研发团队考虑通过GPU Skinning + GPU Instancing的方式缓解大量蒙皮网格在动画模块和渲染模块中的性能开销，具体做法可参见《GPU Skinning加速骨骼动画》。 5、在内存优化方面，Mono、网格和粒子系统内存占用在2017年的上升趋势非常明显，对此，建议研发团队在接下来的项目研发中密切关注这两项的内存使用。 6、资源加载方面，New WWW仍然是MOBA研发团队的主流AssetBundle加载方式，但我们建议正在使用Unity 5.x的研发团队，使用LoadFromFile(Async)的方式来对AssetBundle进行加载。对于仍然没有使用该方式的研发团队，建议查看UWA博客上的相关文档（blog.uwa4d.com），并找到对应的性能比较和分析。 7、 以上数据是我们对于MOBA手游性能数据的整体研究和趋势分析，旨在从宏观上为大家展现项目中普遍存在的性能瓶颈和研发团队容易忽视的潜在性能问题。但同样需要说明的是，优化是一个“抽丝剥茧”的过程，需要研发团队花费大量的时间和耐心去完成。UWA建议：多做测试，以数据说话，空杯心态，将经验归零。 关于UWA 由侑虎科技开发的游戏/VR应用性能优化平台，目前提供 1）性能检测与优化 2）资源检测与分析 3）UWA GOT 三大工具。同时，我们也会为大家开发更省心的功能，希望通过它们可以减少开发者反复测试定位问题的时间，从而将更多的精力集中在项目开发和解决问题中，能为大家项目研发省下的任何一分一秒，都是UWA团队的骄傲。
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.2.1 毛发及眼球的渲染技术 2.2.2 游戏中的角色渲染技术之皮肤篇 2.2.3 卡通渲染及其相关技术总结 2.2.4 Unity移动端动态阴影总结 2.2.5 合并Shader系列 | 如何合并渲染状态 2.2.6 如何打造高逼格耀斑效果 2.2.7 Unity线性空间下移动设备上烘焙变暗问题处理 2.2.8 Unity 5烘培场景带来的“爱”与“愁” 2.2.9 GPU Skinning 加速骨骼动画 2.2.10 如何精简Unity中使用的字体文件 2.2.11 使用MaterialPropertyBlock来替换Material属性操作 2.2.12 Unity图片优化神器 - Dither算法进阶方案 2.2.13 布料系统原理浅析和在Unity手游中的应用 2.2.14 聊聊Unity里的嵌套Prefab 2.2.15 如何实现更真实的软阴影效果 2.2.16 开启HDR时，半透明渲染画面异常的解决方案 2.2.17 使用Fast Shadow Receiver优化渲染效率 2.2.18 Unity+ iPhone X适配方案 2.2.19 Unity手游开发札记——使用Shader进行UGUI的优化 2.2.20 iOS下拆分Unity图集的透明通道（不用TP） 2.2.21 Journey中的沙丘渲染及其Shader实现 2.2.22 扩展Unity模型编辑器 2.2.23 如何在Unity中实现Stochastic Screen Space Reflection效果 2.2.24 高效的iPhone X适配技术方案（UGUI和NGUI） 2.2.25 如何大幅优化NGUI的堆内存分配 2.2.26 如何在Unity中实现Stochastic Screen Space Reflection效果 2.2.27 基于Unity引擎的Bent Normal实现 2.2.28 Unity移动平台下的烘焙使用及优化 2.2.29 基于2D SDF的体积字实现 2.2.30 Unity如何实现投影阴影效果 2.2.31 Unity引擎后处理性能优化方案解析 2.2.32 利用多进程并行化加速Unity资源构建 2.2.33 Unity引擎iOS增量编译方法解析 3、插件&工具相关 2.3.1 插件 | 那些你不得不用的好插件！——工具篇 2.3.2 插件 | 你的项目和大作只差一个插件的距离！——美术效果篇 2.3.3 插件 | 好插件让你事半功倍！——资源篇 2.3.4 技巧 | Unity中Avatar换装实现 2.3.5 插件 | Unity一键图集生成工具，附源码 (基于NGUI和TexturePacker) 2.3.6 插件 | Unity游戏界面解决方案: PSD For UGUI 2.3.7 插件 | ShaderForge插件分享 2.3.8 技巧 | ScreenSpaceShadowMask Blur推荐 2.3.9 插件 | USequencer系列 |初识 2.3.10 插件 | USequencer 准确显示瞬时事件和持续事件 2.3.11 插件 | USequencer 缤纷事件、事件间吸附 2.3.12 屏幕特效插件分析 | FxPro & Beautify 2.3.13 屏幕后处理特效性能分析—运动模糊 2.3.14 Unity插件开发基础—浅谈序列化系统 2.3.15 如何高效定位Unity安卓开发中的闪退问题 2.3.16 ACT技能编辑器的制作经验分享 4、内存相关 2.4.1 Lua性能优化—Lua内存优化 2.4.2 用好Lua+Unity，让性能飞起来——Lua与C#交互篇 2.4.3 用好Lua+Unity，让性能飞起来—LuaJIT性能坑详解 2.4.4 Unity项目常见Lua解决方案性能比较 2.4.5 Lua配置表存储优化方案 2.4.6 Unity匿名函数的堆内存优化 2.4.7 给调皮的AssetBundle加上面向对象式加载调试管理 2.4.8 Unity 5.x AssetBundle零冗余解决方案 2.4.9 AssetBundle进阶内存优化（Unity 4.x） 2.4.10 巧用UWA资源检测，轻松剔除冗余资源！ 2.4.11 听说你的项目中仅这些资源就卡成了翔？看看他们怎么做！ 2.4.12 Lua的CPU开销性能优化 2.4.13 我所理解的委托和匿名函数 5、研发实录 2.5.1 我们用50次游戏性能的深度优化，总结出了五条“毒鸡汤” 2.5.2 Unity手游开发札记—大世界动态加载实战 2.5.3 Unity手游iOS内存分析和测试 2.5.4 Unity 协程运行时的监控和优化 2.5.5 Unity 游戏的String interning优化 2.5.6 Unity动画文件优化探究 2.5.7 动画重定向技术分析及其在Unity中的应用 2.5.8 VR交互动画短片《拾梦老人》的开发经历 2.5.9 独立游戏《Abi》场景耗时分析 2.5.10 Optimize GameObject选项对骨骼Transform的影响 2.5.11 《为谁而炼金》UI界面加载性能分析 2.5.12 Unity中ShaderLab内存优化 2.5.13 使用UWA GOT优化Unity性能和内存 2.5.14 客户端配置文件优化策略 2.5.15 Unity中字体名对依赖关系的影响 2.5.16 《小米超神》技术总监王啸予：重度MOBA的优化之路 2.5.17 基于团队的持续优化之道 2.5.18 《Exploring in UE4》多线程机制详解 6、行业参考 2.6.1 UWA发布 | 2017 Unity手游体检蓝皮书 — ARPG篇 2.6.2 UWA发布 | 2017 Unity手游体检蓝皮书 — MMORPG篇 2.6.3 UWA发布 | 2017 Unity手游体检蓝皮书 — MOBA篇 2.6.4 Unity版本使用情况统计报告 7、案例精讲 2.7.1 UWA助力独立游戏开发！《江湖X：汉家江湖》性能诊断精讲！ 2.7.2 一次MMO手游的性能诊断全纪录 2.7.3 RPG |《星辰奇缘》测评精讲 2.7.4 ARPG|《王者之剑2》性能数据精讲 2.7.5 RPG |《仙剑奇侠传3D回合》性能精讲 2.7.6 ACT |《艾尔战记》性能精讲 2.7.7 MMO |《六龙争霸》测评精讲 2.7.8 FPS |《全民枪战》测评精讲 2.7.10 FPS手游《战地先锋》性能案例精讲 2.7.11 MOBA手游《小米超神》案例精讲 2.7.12 UWA官方Demo新增《小米超神》，全面揭秘重度手游的性能表现！ 8、学术论文 2.8.1 基于功耗预算的实时绘制 2.8.2 微表面模型－PBR渲染管线的材质 2.8.3 基于物理的渲染—更精确的微表面分布函数GGX 2.8.4 基于物理的渲染—基于球面调和基的实时全局光照明 2.8.5 基于物理的渲染—基于Haar小波基的实时全局光照明 2.8.6 基于物理的渲染－用真实的环境光照亮物体 2.8.7 基于物理的渲染—HDR Tone Mapping 2.8.8 CG中的深度学习 |Siggraph 2017 相关论文总结 Part 3. UWA 问答社区 所有的已知，在未知面前不过是冰山一角。遇到问题怎么办，投石问路！正所谓不学不问，不问不知。一个高质量的提问是解决问题的一半。如果你真心想解决某个问题，不妨和大家一起来讨论下这些话题吧。 3.1 资源放到resource下面有什么优势和劣势 3.2 如何降低动画文件的浮点数精度 3.3 AssetBundle 粒度规划 3.4 数据模板表打包以及加载方式怎么做可以兼顾加载速度和热更新表结构 3.5 资源引用最后导致应用包体大小的疑惑 3.6 AssetBundle未加载完使用错误 3.7 项目初期如何确定美术规范 ... UWA问答社区地址：answer.uwa4d.com 关于我们的官方QQ群（465082844） 如果你也想做出高颜值的代码，如果你也期待能让项目走向性能巅峰，如果你本人也乐于分享从善如流，欢迎加入UWA群；与其闭门造车不如群策群力；比起形而上学，我们更乐于解决实际问题。 Part 4. UWA 自学素材 UWA不仅举办了多次技术优化日，也积极活跃在网络。我们尽己所能，将技术的触角传递到每个角落。以下就是我们留下的足迹： 4.1 8.10 直播回顾 | 一个小时内，我们用UWA GOT解决了这些问题... 4.2 UWA 六月直播季 | 6.29 Unity UI模块中的优化案例精讲 4.3 UWA 六月直播季 | 6.22 Unity中动画系统性能优化方案回顾 4.4 UWA 六月直播季 | 6.15 Unity引擎渲染效率全解析 4.5 UWA 六月直播季 | 6.8 移动游戏加载性能和内存管理全解析 4.6 5.4 UWA直播回顾：Unity游戏的代码堆内存优化 4.7 NGUI性能优化技巧（上） 4.8 NGUI性能优化技巧（下） 4.9 UGUI美术制作——如何实现次时代美术效果 4.10 UGUI性能优化技巧 4.11 请让我用一小时，将你的项目性能提升一个高度！ 4.12 UWA优化日厦门站回顾 | 资深TA教你如何将艺术概念转化为渲染代码 4.13 不喧哗，自有声—记UWA优化日深圳站（附完整技术PPT） 4.14 记一次冷雨寒风日的UWA优化日（内附技术PPT） 4.15 You should be here ！| 附UWA优化日技术PPT Part 5. 虚幻引擎学习之路 我们会将UWA内部学习过的Unreal相关技术文档进行总结和整理，并陆续发布，计划发布两大系列文章，第一个系列是功能篇，主要讲述我们学习过程中所了解到的Unreal引擎功能特色；第二个系列是性能篇，重点分析Unreal引擎在多个平台（特别是移动平台）上的性能效率。 5.1 虚幻引擎学习之路：渲染模块之光照系统 5.2 虚幻引擎学习之路：渲染模块之材质系统 5.3 虚幻引擎学习之路：相机图像后处理 5.4 虚幻引擎学习之路：渲染模块之全局光照明 5.5 虚幻引擎学习之路：动画模块之基础篇 5.6 虚幻引擎学习之路：动画模块进阶篇之动画融合 5.7 虚幻引擎学习之路：动画模块进阶篇（二） 5.8 虚幻引擎学习之路：粒子系统篇（一） 5.9 虚幻引擎学习之路：粒子系统篇（二） 5.10 虚幻引擎学习之路：新粒子系统Niagara 5.11 虚幻引擎学习之路：基于Unreal引擎的大地形加载研究 与其他世面文章不同的是，我们会在讲解中揉入和Unity引擎相似功能的对照说明，以方便大家更快地对其进行理解和掌握。这里，需要郑重说明的是，我们之所以这么做并不是为了比较Unreal引擎和Unity引擎谁更强大，二者都是当今世界上伟大的引擎。我们这么做是因为发现这可以极大地提高对于Unreal引擎的学习效率。 到这里便是UWA迄今为止所有在Blog以及微信上推送的技术博文汇总，我们将其梳理，是为了让一些经典好文能够重现，让知识能常流通，同时也是为了方便大家日后查找。本篇文章作为UWA Blog里的目录将随时更新，建议大家Mark起来，有空没空随手刷上个两篇，结合自身的研发项目多做测试加深理解，UWA相信一定事半功倍。 最后也要感谢所有向UWA供稿的开发者，感谢你们将这么棒的想法分享出来，从而帮助到更多的研发团队。当然如果你也有好的想法或者研发路上的心得体验，也可以分享给我们哦（support@uwa4d.com），知识的百科全书需要你我共筑。