0x00 前言

相信不少使用Unity的小伙伴都听说过,甚至也亲身经历过在Unity5.6最初的几个版本中使用Resources.Load方法加载资源变~~慢的问题。
这个问题的确是存在的,比如这个issue中提到的:
android-performance-regression-when-loading-a-prefab-with-a-lot-of-child-objects-using-resources-dot-load

所以为了验证问题并思考是否有解决方案,我也实现了类似这个issue中提到的测试场景,并且分别在Unity5.6.1f1版本和Unity5.6.4p1版本上进行了测试对比,至于为何选择这2个版本下文再说。

屏幕快照 2018-02-04 上午9.58.33.png

这个场景比较简单,主要是在Resources文件夹下创建了一个有很多(650+)子节点的prefab,并且在运行时通过点击按钮调用Resources.Load进行资源加载。

而我的测试设备则是几年前的MI Note Pro。

0x01 测试

测试场景和测试设备都准备就绪了,接下来我们就直接在Unity5.6.1f1上进行安卓包的构建吧,同时直接连上profiler进行数据抓取。
屏幕快照 2018-02-04 上午8.53.10.png
不过这一测不要紧,果然可以发现这个版本的Unity在调用Resources.Load加载资源的效率很低。大概要耗时1700ms!

等等,冷静一下,回想一下既然是加载Resources文件夹内的资源,那么Resources文件夹有什么特点吗?对,它会随工程一同打包。也就是说在打包的过程中它会经过aapt这个工具的处理啊。那么aapt是什么呢?看它的全称——Android Asset Packaging Tool,安卓资源打包工具啊。那么能否通过修改aapt的参数来改善加载Resources文件夹内的资源效率的问题呢?

想到这里,吓得我立马导出了一个gradle工程。
打开build.gradle文件查看一下,嗯这里没有设置aapt的相关参数。
屏幕快照 2018-02-04 上午10.18.42.png

所以我来手动加上对aapt的设置吧:

aaptOptions {
    noCompress '.unity3d', '.ress', '.resource', '.obb'
}

ok,这次我们通过Android Studio来导出一个安卓包。并且连上设备进行测试。
no_compress.png

结果让人稍感欣慰,耗时已经从之前的1700ms来到了300ms。

所以,修改aapt的压缩策略对Resources文件夹内的资源是有效果。

好了,我们接下来使用另一个Unity版本——5.6.4p1来进行测试。
这次不导出gradle工程,直接使用Unity来打包。

屏幕快照 2018-02-04 上午8.59.15.png

wow~测试的结果亮瞎双眼。竟然只需要50ms!(考虑到我的测试场景很凶残,设备很简陋,从1700+ms来到50ms还是很大的跃升吧)。

这是为什么呢?

答案很简单,因为我们fix了这个问题啊。而这也是我选择这个版本进行测试的原因啊。
屏幕快照 2018-02-04 上午10.26.16.png

所以,如果还在对江湖传闻中5.6版本的Resources.Load效率变态的低感到恐惧的话,就赶快升级Unity版本吧。当然,作为最佳实践之一,尽量减少使用Resources也是不错的选择。

版权声明:本文为murongxiaopifu原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/murongxiaopifu/p/8414041.html