低端机UI耗时超过30ms，问题为何指向按钮特效

作者：admin
/
时间：6小时前
/
浏览：31 次
/
分类：厚积薄发

1）UI耗时异常，如何定位粒子特效开销
2）AssetBundle已缓存，UI切换为何仍然卡顿

这是第498篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。

实战案例

Q：在不同档位设备的性能测试中，UWA GOT Online报告显示高端机UI平均耗时约2.66ms，而低端机达到8ms，部分区间甚至持续超过30ms。进一步查看函数堆栈，发现ParticleSystem.Simulate等节点存在较多调用，且调用次数与UI耗时变化较为一致。这是否意味着UI特效是主要开销来源，应该如何进一步排查？

A：从GOT Online报告目前的堆栈数据来看，UI Particle是需要优先检查的部分。ParticleSystem.Simulate的调用次数与UI耗时变化比较一致，但还需要看实际耗时占比，才能判断它对整体UI开销的影响。

结合测试画面，部分耗时峰值出现在升级按钮点击时，对应界面中的闪光粒子特效。而在后半段的主城场景中，UI耗时维持在相对较高的水平。项目中的活动入口、按钮辉光等位置也使用了UI Particle，可以从以下两方面排查：

1.检查常驻UI特效的更新开销
点击时短暂播放的特效主要影响触发帧，而主城中持续运行的按钮辉光等效果，则可能不断产生粒子模拟开销。建议对照ParticleSystem.Simulate的调用次数与耗时，检查哪些特效在没有操作时仍然更新。

如果UI Particle通过CanvasRenderer动态更新网格，还应关注Canvas.BuildBatch、Canvas.SendWillRenderCanvases等相关节点，确认是否存在额外的Canvas重建开销。对于更新频繁的特效，可考虑使用独立子Canvas，将动态特效与静态UI分离，并对比拆分前后的批次与CPU耗时。

2.调整低端机的特效表现方式
对于按钮闪光、辉光等简单效果，可以测试序列帧或基于UV滚动的UI Shader方案，减少粒子模拟开销；其他特效则可按设备档位控制数量，避免低端机同时运行过多UI Particle。替换时还需关注透明叠加、GPU耗时及内存变化，不能只看CPU开销。

最后，在相同界面和操作流程下，对比UI模块耗时、ParticleSystem.Simulate耗时及FPS，确认调整是否有效。

实战案例

Q：在低端机测试中，部分UI界面切换时出现明显卡顿，函数堆栈中可以看到较高的资源实例化和初始化开销。但项目已经对AssetBundle进行了缓存，为什么打开界面时仍然存在较高的CPU耗时？

A：AssetBundle缓存不等于Prefab实例缓存。如果关闭界面时销毁了Prefab实例，下次打开仍需重新创建对象，并执行相应的初始化操作。

从测试结果来看，相关主逻辑函数在高端机上的平均耗时约1ms，在低端机上则达到约6ms。堆栈中可以看到部分实例化、销毁相关开销，UI切换时也存在明显的局部卡顿。

项目虽然缓存了AssetBundle，但部分UI Prefab实例会在关闭界面后释放。再次打开时，GameObject创建、组件初始化以及可能触发的UI重建如果集中在同一帧执行，就容易出现卡顿。建议从以下两方面排查：

1.找出重复实例化的UI对象
在GOT Online报告中的资源管理模块通过资源实例化列表中的资源名称、调用次数和耗时，检查哪些界面在反复打开时仍会重新创建对象。

对于打开频繁、实例化成本较高的界面，可以考虑保留实例或使用对象池。但复用后仍需检查SetActive(true)触发的OnEnable逻辑，以及Layout Group重新计算等开销，避免对象创建减少了，界面激活时仍出现耗时峰值。

2.根据内存压力调整缓存范围
对象复用能够减少重复创建，但会增加内存驻留。对于内存压力较大的低端机，可以优先保留打开频繁、创建成本较高的界面，低频界面仍按需创建和释放。

如果界面切换时还伴随GC.Alloc明显增加，则应进一步检查临时托管对象分配，并结合GC执行耗时判断是否存在垃圾回收引起的额外卡顿。

调整后，重复执行界面打开和关闭操作，对比实例化耗时、卡顿帧及内存变化，确认缓存策略是否真正改善了低端机的表现。