服务器上配置加载resources下的文件 resources.load

0x00 前言

相信不少使用Unity的小伙伴都听说过，甚至也亲身经历过在Unity5.6最初的几个版本中使用Resources.Load方法加载资源变～～慢的问题。

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

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

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

0x01 测试

测试场景和测试设备都准备就绪了，接下来我们就直接在Unity5.6.1f1上进行安卓包的构建吧，同时直接连上profiler进行数据抓取。

不过这一测不要紧，果然可以发现这个版本的Unity在调用Resources.Load加载资源的效率很低。大概要耗时1700ms！

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

想到这里，吓得我立马导出了一个gradle工程。

打开build.gradle文件查看一下，嗯这里没有设置aapt的相关参数。

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

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

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

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

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

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

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

这是为什么呢？

答案很简单，因为我们fix了这个问题啊。而这也是我选择这个版本进行测试的原因啊。

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

-EOF-