资源管理
Q1：我们的游戏中，相邻关卡资源很相似。现在涉及到切换场景，每次都要卸载资源又加载资源，很耗时；但是如果先加载再卸载，内存峰值又会涨。请问UWA有什么建议么？
UWA建议研发团队可以将共用资源剥离出来，与其他场景进行依赖关系打包。这样当相邻副本切换时，其共用资源常驻内存，可以避免频繁加载和卸载所带来开销。如果研发团队想更准确地定位到底是哪些资源在频繁加载和卸载，那么可以通过UWA性能报告中的“资源管理”界面进行查看。如下图所示，多种不同资源被不同场景所共用，存在频繁加载和卸载的情况。对此，建议研发团队在内存允许的情况下，将此类资源进行缓存。
资源管理
Q2：在AssetBundle打包的时候，我们是一个文件一个AssetBundle，基本不存在冗余的情况了。但这种做法是否可取？UWA有什么建议？
这种做法是不足取的，因为这会造成Assetbundle文件非常细碎，进而带来两点不足：
（1）加载IO次数过多，从而增大了硬件设备耗能和发热的压力；
（2）在我们测试过的Unity 5.3 ~ 5.5 版本中，Android平台上在不Unload的情况下，每个AssetBundle的加载，其每个文件的SerializedFile内存占用均为512KB（远高于其他平台），所以当内存中贮存了大量AssetBundle时，其SerializedFile的内存占用将会非常巨大。
下图为我们获取的游戏运行时AssetBundle在内存中的贮存数量，在某一副本中，AssetBundle可以达到160个，那么其在Android设备上的SerializedFile内存也将达到80MB。该问题为目前Unity项目开发团队特别需要注意的地方。
资源管理
Q3：BuildAssetBundleOptions.DisableWriteTypeTree这个选项的实际用处是什么？
在Unity 5.x版本中，AssetBundle在制作时会默认写入TypeTree信息，这样做的好处是可以保证AssetBundle文件的向下兼容性，即高版本可以支持以前低版本制作的AssetBundle文件。所以，如果开启DisableWriteTypeTree选项，则可能造成AssetBundle对Unity版本的兼容问题，虽然关闭TypeTree会使Bundle更小，但我们一般都不建议研发团队在制作AssetBundle文件时开启该选项。
内存管理
Q4：网格模型FBX文件在不开启Read/Write选项时， 如果通过StaticBatchingUtility的CombineMesh来合批的话，内存会增加么？
通过StaticBatchingUtility的CombineMesh来动态地拼合网格是会增加内存的，主要体现在内存中CombinedMesh的增加以及一定量堆内存的增加。但是，该API使用的前提必须是网格Fbx模型开启Read/Write，如果不开启，则无法读到网格数据，进而不能完成网格的拼合操作。
代码加载
Q5：我的项目在加载过程时经常崩溃，项目加载代码如下。想请问这种写法是否存在问题，是否会导致崩溃？
首先，崩溃还是要看具体崩溃log，看看到底是哪里崩溃，定位真正的崩溃原因（说不定看完后还不是加载的问题）。其次，来谈谈代码的问题，一共有三点需要研发团队考虑：
（1）代码中通过For循环开启一个Coroutine，通过WWW加载AB，然后保存www.bytes信息，这可能是准备后续通过LoadFromMemory来加载。这里如果www.bytes量持续增加，且没有很好地管理的话，那么很可能会造成大量内存占用，特别是堆内存；
（2）代码中www变量在使用后已经设为null了，但为什么下面还要在new一个对象来对其进行缓存呢？这个目前仅通过这段代码来看是很难理解的；
（3）代码中For循环每次仅开启一个Coroutine来加载AssetBundle，这个很可能会严重拖慢项目的加载速度，但这个问题只是效率问题，不会引起崩溃。
PS：在我们与研发团队的交流过程中，我们发现比起大一统的、有规律性的经验总结，更多开发问题都隐于代码背后，这不能仅靠语言描述或者经验推测可以解决，而需要我们深入现场，在代码中挖掘问题的原因。这也是我们UWA真正想帮助大家解决问题的方式。因而，我们强烈欢迎大家就自己的具体问题具体交流。请记得：比起闭门造车，我们更乐意与大家各抒己见，畅所欲言；比起形而上的泛泛而谈，我们更乐意与大家直击痛点，对症下药。
原文出处：侑虎科技
本文作者：admin
转载请与作者联系，同时请务必标明文章原始出处和原文链接及本声明。
