Unity 打包总结和资源的优化和处理

1. Texture，都去掉alpha通道，作为背景展示的图片，基本都没有透明要求，有特殊要求的则放到atlas里面

a. Loading图这类需要比较精细的，则把图片设置为Automatic TrueColor，设置真彩色，保证不失真

b. 地图、缩略图、UI背景图等等要求不精细的，则可以设置为自动压缩格式（有压缩情况，都需要图片宽高尺寸是2的幂，可以在Advance里面设置toNearest）

 

注意：ios下会自动把图片宽高拉伸为2的幂次方尺寸，这样会导致图片显示失真，解决办法是制作图片的时候就保证是2的幂大小。如果图片显示的区域确实不能做出2的幂大小，可以用补黑边的方式把图片做出2的幂大小，设置图片的时候，就需要调整图片的UV

要点：android下，带alpha通道的图片，自动压缩是以ETC2 8bit的方式压缩的，不带alpha通道，是压缩成ETC 4bit的格式（ETC2 支持alpha通道），ios下是压缩成PVRTC 4格式。手机硬件对各种格式图片的加载效率不一样，RGBA32是最慢的。所以需要对图片进行处理，改压缩方式，ETC和pvr是加载最快的。

 

2. animation clip

动作片段的优化，主要是减少动作的无用帧，就是两个Keyframe之间的旋转或者位移或者缩放的差别很小很小，则可以把Keyframe去掉，这样一个几百k的动作片段优化下来可能只有几十k，还是相当可观的

 static List<Keyframe> TrimScaleKeyframes(AnimationClipCurveData curve)
         {
             List<Keyframe> keyframes = __keyframes;
             float maxValue, minValue, averageValue;
             keyframes.Clear();
             List<KeyframeSample> samples = TakeSamples(curve, out maxValue, out minValue, out averageValue);
             int depth = curve.propertyName.Split('/').Length;
             var kcount = samples.Count;
             keyframes.Add(samples[].keyframe);
             bool lastIsRemoved = false;
             Keyframe lastKeyframe = new Keyframe();
             var epsilon = m_scaleError;
             float error = ;
             for (int k = ; k < kcount - ; ++k)
             {
                 var kf = samples[k].keyframe;
                 var diff = samples[k].pos.y - keyframes[keyframes.Count - ].value;
                 error += diff;
                 if (Mathf.Abs(error) > epsilon)
                 {
                     if (lastIsRemoved)
                     {
                         keyframes.Add(lastKeyframe);
                         lastIsRemoved = false;
                     }
                     keyframes.Add(kf);
                     error = ;
                 }
                 else
                 {
                     lastIsRemoved = true;
                     lastKeyframe = kf;
                 }
             }
             keyframes.Add(samples[kcount - ].keyframe);
             if (keyframes.Count == )
             {
                 if (Math.Abs(keyframes[].value - keyframes[].value) < Mathf.Abs(m_positionError))
                 {
                     keyframes[] = KeyframeUtil.GetNew(keyframes[].time, keyframes[].value, TangentMode.Linear, TangentMode.Linear);
                     keyframes[] = KeyframeUtil.GetNew(keyframes[].time, keyframes[].value, TangentMode.Linear, TangentMode.Linear);
                 }
             }
             return keyframes;
         }

 

3. 检查无效的脚本

很多时候美术制作资源的时候，为了即时看到效果，会把脚本给挂上去，但是制作完以后通常会忘了把脚本卸载。通常这些资源会打包成bundle资源，这个时候脚本就会缺失，加载bundle的时候会一直报警告消息，这样会增加CPU的开销，严重的话会引起卡顿。所以检查无效的脚本是很有必要的。不过有哪些无效脚本，这个就需要统计了，是个体力活

 

4. 特效的检查

游戏里面的特效非常多，几百上千个。而特效里面引用相同材质的情况是很多的，如果不把这些材质的剔出来，会造成很多资源的冗余。一个最简单的办法就是把所有特效的材质贴图都抠出来打包成一个bundle文件，加载特效的时候动态加载材质贴图，还是会减少几MB内存的。

还有一点，特效贴图很多都使用了alpha通道，渲染的时候容易造成重绘情况（alpha test和alpha blend），会加大CPU和开销。解决办法是拆分贴图的alpha，shader里面做alhpa的混合。这样会时游戏更加流畅一点，就是实现起来稍微麻烦一些

 

5. 场景处理

纹理合并+静态批处理，lightmap贴图设置自动压缩。一个是减少drawcall，一个是减少内存占用。静态批处理的

 

6. atlas贴图

和特效贴图类似，也是拆分alpha通道，在shader里面做混合。不过有一个很大的好处就是，atlas都是需要显示很精细的，做贴图压缩处理的时候基本都是使用true color，一个1024x1024的 RGBA32的图片在内存中会占用4MB的大小。做了alpha通道拆分后，就可以把alpha图片和RGB图片做自动压缩成ETC 4bit格式，占用的内存会大大减少。对于游戏同时会使用几个atlas的情况下，这种处理方式一个atlas大概就能减少2到3MB的内存，几个下来，20MB都有可能，还是很客观的

 

7. GameUI 游戏窗体界面

窗体界面在打包的时候把挂载的脚本去掉，加载窗体的时候动态挂上去。还有一点，打包的时候处理资源的依赖关系是很麻烦的，所以一劳永逸的办法是，把窗体引用的atlas和font都去掉，在加载窗体的时候再动态挂回来，有点像脚本的处理方式，只是代码实现上稍微复杂点，还是很简单的。这样也不用担心窗体打包成bundle后过大的问题。200个窗体，通过这样打包bundle，总共5MB左右，atlas和font单独打包成bundle。还有一点，有些项目是把atlas、font、UI打包成一个bundle资源，这样也可以解决重复依赖的问题。但是这样会增加内存开销，毕竟所有atlas、font、UI都一次性加载完了。所以一个文件打成一个bundle，在加载的时候可以使内存过度比较平缓。

 

8. 角色模型和怪物模型处理依赖

角色模型通常都会有几套动作，所以打包角色模型时都需要先把角色上的动作给去除掉，游戏中在动态挂上去。这样处理需要动作文件命名规范，有可能会用到配置表。

怪物、npc、坐骑等模型和动作基本都是一一对应的，不存在冗余的情况，所以不用拆分动作，直接全依赖打包

 

9. 音效、texutre不需要考虑依赖情况，直接打包。不过，因为这类资源本身都是经过压缩的，打包的时候可以尝试选择不压缩打包的方式打成bundle，加载bundle的时候就是加载的没有压缩的资源，可以提高加载资源的速度

 

10. 场景打包，unity 5.0以后加入了LZ4的压缩方式，对比LZMA的压缩方式，在加载速度上提升是非常大的，我测试过加载场景，使用LZMA的bundle同步加载时间是0.8s，使用LZ4的bundle加载的时间只有0.005s，快赶上不压缩的方式了。一个场景文件通过LZMA压缩后的大小是10MB， LZ4的大小是15MB，不压缩的大小就是25MB。所以个人推荐还是使用LZ4的方式打包场景，不过也不是所有的场景都需要用LZ4，毕竟还是大了有大概0.3倍的大小。所以可以把游戏的前面几张场景使用LZ4打包，后面的用LZMA。这样，玩家开始玩的时候还是能有不错体验的。最终怎么取舍还是看项目具体的需求吧

如果资源采用不压缩的方式打包，然后再对总资源进行zip压缩，包体最终是小了，不过提交到ios后台看到的包体大小却是zip解压后的大小。目测ios后台是会自动识别zip压缩的。一个办法是自己写压缩算法，个人觉得还是比较麻烦。在手机硬件提升越来越快的情况下，没有必要为了低端机做不压缩的处理。中高端机对于不压缩的资源加载和LZ4的资源加载，几乎无感，孰高孰低，仁者见仁吧