我们游戏是使用Unity3d做的2D游戏，角色特效等都使用SmoothMoves来制作(在国内估计也算奇葩一朵吧，据说燃烧的蔬菜也是SmoothMoves作的)，游戏中的所有的资源--角色、特效、技能ICON、角色ICON、音效等几乎都使用assetbundles来实现。
问题：加载一场战斗的时间大概要30s左右！！！
解决方案关键字：依赖打包、数据块共享、冗余数据剔除
优化后：5s左右 :)
1. 依赖打包
1.1 使用AssetDatabase.GetDependencies()接口可以查看资源的依赖引用情况，利用这些依赖信息，就可以设计如何规划依赖打包了
PS: 曾猜测unity是在meta文件存储了资源间的依赖关系，结果在meta中没有找到什么痕迹... 有了解的兄弟请分享~
PS: GetDependencies 对prefab不起作用？我的打开方式不对？
1.2 依赖打包指的是使用BuildPipeline.BuildAssetbundle()打包资源时，使用BuildPipeline.PushAssetDependencies() 和 PopAssetDependencies()两接口，将资源间共享的引用资源抽离，避免重复资源。比如A、B两资源都引用了C资源，如果不使用依赖打包，A、B对应生成的assetbundle中都会有C资源的拷贝，在内存中也就有两份C资源，这样既增大了资源包，也浪费了宝贵的内存空间。于是，Push/Pop组合就可以派上用场了。
// 打包示例1 1 Push 2 BuildAssetbundle C 3 4 Push 5 BuildAssetbundle A 6 Pop 7 8 Push 9 BuildAssetbundle B 10 Pop 11 Pop
这样会得到3个assetbundle文件：A、B、C，在加载时由于依赖关系，一定要先加载C，才可以加载A或者B。而A与B间则没有任何其他的依赖关系，先加载哪个无所谓。
对示例打包方式略加修改：
// 打包示例21 Push 2 BuildAssetbundle C 3 4 Push 5 BuildAssetbundle A 6 BuildAssetbundle B 7 Pop 8 Pop
或者再干脆点
// 打包示例31 Push 2 BuildAssetbundle C 3 BuildAssetbundle A 4 BuildAssetbundle B 5 Pop
这两种打包方式，A和B仍然依赖于C，最后一种B同时还潜在的依赖于A。如果A B间除了共同引用了C资源之外，还有其他共同的依赖项D(善用AssetDatabase.GetDependencies)，则在加载B之前还必须要先加载A。所以推荐使用第1种打包方式，以避免类似情况的发生。
还是上面ABC的例子，如果A、B两文件本身没有更新，而C有修改，此时，可以只重新打包C，无须重新打包A或B，但一定要使用BuildAssetBundleOptions.DeterministicAssetBundle选项。
另外，依赖关系本身我们使用ScriptableObject来存储，当然也可以考虑使用XML等其它方式。
1.3 SmoothMoves动画打包
前面说到我们使用了SmoothMoves来制作2D动画:
a. 由于动画文件间会交叉引用atlas文件，为避免atlas的重复，将所有的atlas都由动画文件中抽离，单独打包，然后再打包动画文件。
b. 所有atlas都引用同样的Shader，使用Profiler可以看到每个atlas的shader都要解析一次，为避免shader的重复解析，shader也抽离后单独打包
c. 每个动画文件都挂载有BoneAnimation脚本，其atlas信息则由TextureAtlas来存储，这两个脚本都在SmoothMoves_Runtime.dll中。实测中发现，DLL文件的依赖打包一定要小心处理。我们的方法是建立一个无用的TextureAtlas(仅仅为引用SmoothMoves_Runtime.dll)，而所有的动画文件和相应的atlas文件都依赖于此进行打包。
大致打包流程如下：
1 // SmoothMoves动画打包示例
2 BuildSMAnimation()
3 {
4 Push
5 BuildAssetbundle shared_shader
6
7 Push
8 BuildAssetbundle SmoothMoves_Runtime.dll
9
10 Push
11 foreach atlas do
12 BuildAssetbundle atlas
13 end
14
15 foreach sm_animation do
16 Push
17 BuildAssetbundle sm_animation
18 Pop
19 end
20
21 Pop
22
23 Pop
24
25 Pop
26 }
如上所示，可以在打包的同时生成依赖关系配置，并在游戏初始化时，首先读取该依赖关系，然后是shared_shader、SmoothMoves_Runtime.dll，并且将两者常驻内存，即不对其assetbundle执行unload操作，因为任何的动画文件加载时对BoneAnimation脚本的处理都依赖于SmoothMoves_Runtime.dll，任何atlas加载时其shader都依赖于share_shader。
2. SmoothMoves.BoneAnimation 中的大数据块共享
使用依赖打包后，加载速度有提升，但依旧需要近20s！！！ 继续使用Profiler查看分析，最终确定是动画文件挂载的脚本BoneAnimation中的有大量数据，引起了大量GC Alloc。而且在动画实例化时，BoneAnimation也会进行深度复制，进一步测试后确定是BoneAnimation中的triggerFrames和mAnimationClips两成员变量占用绝大多数内存（在较大的动画文件中，这两项竟占到1MB）。阅读SmoothMoves_Runtime的源代码后，确定游戏中这两个成员变量是只读的(事实上triggerFrames会有写操作，只是我们的游戏不会用到)，所以决定将这两项数据抽离BoneAnimation，并保存在SMAnimationData(自定义的ScriptableObject) 中单独加载，并在需要的时候为BoneAnimation添加引用。这样保证了同一动画文件的各实例化对象共享同一份数据，减少了GC Alloc的次数，同时也减少了内存占用。如下：
1 // 抽离BoneAnimation.triggerFrames 和 mAnimationCips 2 sm_animation_data = ScriptableObject createInstance of SMAnimationData 3 4 sm_animation_data.triggerFrames = bone_animation.triggerFrames 5 sm_animation_data.mAnimationClips = bone_animation.mAnimationClips 6 7 bone_animation.triggerFrames = null 8 bone_animation.mAnimationClips = null 9 10 BuildSMAnimation 11 12 BuildAssetbundle sm_animation_data
虽然已经减少了实例化SmoothMoves动画时的大数据块复制带来的GC Alloc，但由于SMAnimationData中的triggerFrames 和 mAnimationClips两大数据，加载时的大量GC Alloc依旧不可避免。继续想办法压缩这两个大数据块。
3. 优化BoneAnimation.triggerFrames
a. 出发点
BoneAnimation.triggerFrames 是以clipIndex & frame 为键值的TriggerFrame数组，每个TriggerFrame都存储了相应clip的相应frame上所有骨骼关键帧的信息，即TriggerFrameBone列表（TriggerFrame.triggerFrameBones）。详细分析后发现，这些TriggerFrameBone列表间或列表内部，存在大量属性完全一致的TriggerFrameBone。以此为出发点，建立一个无重复的TriggerFrameBone集合，并让每个TriggerFrame中的TriggerFrameBone列表都引用该集合中的元素。
b. 建立TriggerFrameBone集合和索引表
b.1 在SMAnimationData中添加新成员List<TriggerFrameBone> triggerFrameBoneSet，作为TriggerFrameBone集合使用；
b.2 在TriggerFrame中添加新成员List<int> triggerFrameBoneIndexes，存储该TriggerFrame中原有的triggerFrameBones列表在SMAnimationData.triggerFrameBoneSet中的索引；（事实上项目中使用的List<byte>类型，就是这么抠门...）
这样在SMAnimationData.triggerFrames赋值后就可以建立SMAnimationData.triggerFrameBoneSet 和各个 TriggerFrame.triggerFrameBoneIndexes了：
1 // 建立TriggerFrameBone 集合
2 BuildTriggerFrameBoneSet
3 {
4 foreach tf in sm_animation_data.triggerFrames do
5 foreach tfb in tf.triggerFrameBones do
6 //此处遍历整个列表是否有属性完全一致的TriggerFrameBone，即是说需要一个对比两个TriggerFrameBone是否一致的接口
7 if sm_animation_data.triggerFrameBoneSet not contains one TriggerFrameBone equaling tfb
8 sm_animation_data.triggerFrameBoneSet.Add(tfb)
9 endif
10
11 tf.triggerFrameBoneIndexes.Add(sm_animation_data.triggerFrameBoneSet.IndexOf(tfb))
12 end
13
14 tf.triggerFrameBones.Clear()
15 end
16 }
如此，在对SMAnimationData进行序列化时，TriggerFrame.triggerFrameBones是没有内容的，而所有的TriggerFrameBone都在triggerFrameBoneSet中。实际效果表明，TriggerFrameBone重复率非常高，其数量可减少90%以上。
相应的在加载SMAnimationData完成时，要根据TriggerFrame中的triggerFrameBoneIndexes重建triggerFrameBones列表。
4. 优化BoneAnimation.mAnimationClips
BoneAnimation.mAnimationClips是以clip name为键值的AnimationClipSM_Lite数组，每个AnimationClipSM_Lite存储了该clip所有骨骼的颜色信息，即bones列表
a. 删除空的AnimationClipBone_Lite
AnimationClipSM_Lite.bones 列表中上存在大量没有实际意义的元素，即AnimationClipBone_Lite中的颜色信息为空，也就是下面的函数返回为true。
1 // 判断AnimationClipBone_Lite是否为空
2 public bool IsEmpty()
3 {
4 if (colorACurveSerialized.keyframes.Count > 0
5 || colorRCurveSerialized.keyframes.Count > 0
6 || colorGCurveSerialized.keyframes.Count > 0
7 || colorBCurveSerialized.keyframes.Count > 0
8 || colorBlendWeightCurveSerialized.keyframes.Count > 0)
9 {
10 return false;
11 }
12 else
13 {
14 return true;
15 }
16 }
在AnimationClipSM_Lite的构造函数中加入AnimationClipBone_Lite是否空的判断，如果为空则不添加到bones列表中。如此，还要调整原本对bones的访问：原代码中都使用boneDataIndex来对bones进行读取，即boneDataIndex即是bones列表的索引下标。将缩减后的bones列表要转换为以boneDataIndex为键值的映射表，如下
1 public void BuildBoneDict()
2 {
3 m_bone_dict = new Dictionary<int, AnimationClipBone_Lite>();
4
5 if (bones != null)
6 {
7 for (int i = 0; i < bones.Count; i++)
8 {
9 AnimationClipBone_Lite each_bone = bones[i];
10 m_bone_dict.Add(each_bone.boneDataIndex, each_bone);
11 }
12 }
13 }
代码中所有对bones的访问，都改用m_bone_dict，而bones列表仅起到序列化/反序列化的作用。
b. 删除AnimationClipBone_Lite中的无用帧
AnimationClipBone_Lite中的存储是该骨骼的颜色变化曲线，以下两种情况可以优化：
b.1 当颜色变化为一条直线，那除了直线两端的点以外，其它点都是多余的
b.2 当颜色变化仅有一个点，且其blendWeight值为0时，该点是多余的
Unity3d插件SmoothMoves加载速度优化,布布扣,bubuko.com