UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技 - cpu
type: channel
link: https://blog.uwa4d.com/tag/cpu/
items: 小游戏RenderTexture内存为何偏高
items: 隐藏视频变“常驻刺客”，VideoPlayer与“N/A”纹理该怎么查
items: 高频GC与特效精准降温的调优实战
items: 小游戏发热的系统排查与性能调优实战
items: 一个高效研发的制胜之道 | UWA GOT Online功能说明
items: 技术分享连载（一百）
items: FPS手游《战地先锋》性能案例精讲
items: UWA发布 | 2017 Unity手游体检蓝皮书 — MOBA篇
items: Unity优化百科（UWA 博客目录）

小游戏RenderTexture内存为何偏高
type: item
date: 2026-08-25T05:13:00+03:00
description: 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驱动，观察减少单帧多次物理模拟后能带来多少收益。不过…

隐藏视频变“常驻刺客”，VideoPlayer与“N/A”纹理该怎么查
type: item
date: 2026-08-04T05:24:00+03:00
description: 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属性赋值。虽然起个名字不省显存…

高频GC与特效精准降温的调优实战
type: item
date: 2026-07-14T05:50:00+03:00
description: 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基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高…

小游戏发热的系统排查与性能调优实战
type: item
date: 2026-06-30T06:33:00+03:00
description: 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成本和渲染稳定性会更优。从工程角度看，这里的关键不是“图集是否更…

一个高效研发的制胜之道 | UWA GOT Online功能说明
type: item
date: 2018-12-20T06:53:00+02:00
description: 不管项目本身是否重度，性能调优永远是上线前的必经之路。优化性能，不仅需要足够深度的分析来定位问题瓶颈，也需前瞻性的保障措施来缓解后续的优化压力和性能风险。因此，我们推出了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卸载优化分析，场景切换时间太长，如何有效优化？ 物理模块优化分析，一招教你把耗时清零！ 网格内存优化，降低网格内存一二三，走你！ 纹理资源内存优化（一），纹理太大还是冗余？这些小技巧必备！ 纹理资源内存优化（二），优化缓存策略，巧妙降…

技术分享连载（一百）
type: item
date: 2018-02-24T03:49:00+02:00
description: 本期聚集话题：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不在…

FPS手游《战地先锋》性能案例精讲
type: item
date: 2017-09-04T04:47:00+03:00
description: 今天我们为大家带来由上海非钰数码科技的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调用频率控制得非常出…

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…

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.…