这是一个关于Unity游戏包体优化方案的全面介绍

打包规则

• 所有非editor下的托管代码会编译为dll，dll会进入包体。
• 所有StreamingAssets下的文件会被复制到包体。
• 所有Resource下的资源会被无条件打包。
• 所有加入到构建中的场景以及他们所引用的所有资源都会进入包体，如场景使用了模型，模型使用了材质，材质使用了shader和贴图，这些资源都被引用了。
• 其他一些闪屏，icon等
• plugin下的本地库等会视情况打包

Unity文档中的优化方案

先看一下Unity文档中对于优化iOS包体的建议：

http://docs.unity3d.com/Manual/iphone-playerSizeOptimization.html

文档最后最后列出清单如下：

• 最小化资源(assets)，对贴图使用PVRTC压缩，并且尽可能减小分辨率
• 设置striping level 为 use micro mscorlib
• 设置 script call optimization 为 Fast but no excetions
• 不要在代码中使用任何System.dll或System.Xml中的东西，这些库和micro mscorlib不兼容
• 移除不必要的代码依赖
• 设置API兼容等级为.net2.0 subset,注意.net2.0 subset对一些库有限制和兼容性问题
• 不要使用JS数组
• 避免泛型容器使用值类型，包括结构体

可以看出来优化大小主要有以下几个方面、资源大小，代码优化，Unity设置。

Unity设置

先说Unity设置，因为这个最简单，功能是固定的，使用情况也是固定的，基本只要程序正常执行，选择包最小的设置即可。

Striping Level 裁剪等级

裁剪等级设置的越小，代码裁剪的越多，包体也就越小，但是会带来一些限制，所以酌情使用即可。具体可参考Unity文档。

.net subset .net子集

.net中常用功能均在.net子集中，如果你只使用了这些功能，就可以选用.net子集，.net子集比.net2.0大约小1M-2M

script call optimization （iOS）（不详）

根据文档，选择Fast but no exceptions会减少大小，但具体减少多少未测试，且选择这项从字面理解应该是出现异常应用会闪退。

削减架构支持

比如安卓如果只打算支持armv7设备，则不要选择x86或arm+x86，iOS同理（bitcode待测试）

代码优化

代码优化能带来的效果有限，简单说下.

移除不必要的代码依赖

如果你的代码中存在一些大型库的源码或dll，如json.net，但却并没有用到，应该将其移除，这些代码或dll可能占用比较大的空间（json.net的dll占用1M），如果经过il2cpp编译则可能更大。

JS数组问题（不详，一般也不会用到JS脚本）

文档中提到，具体不详

避免值类型作为泛型（不详，且难以避免）

文档中提到，具体不详

资源优化

资源占用大小最多，资源类型和优化方式也非常多，具体选择优化方案也需要根据实际情况和经验来判断。

Assets与StreamingAssets的区别

要理清资源优化的关键，先搞清Assets与StreamingAssets的区别

StreamingAssets下的文件，在打包时会直接复制进包里，只能通过IO或者WWW读取成Assets之后才能使用

Assets是一般的资源，比如拖拽在脚本上的引用的物体，图片，声音等，以及放在Resources下的文件。直接访问代码的引用或者Resources.load使用。

可以看出来Assets和StreamingAssets的第一个区别就是StreamingAssets需要IO读取成Assets，而Assets好像Unity会在引用到时，或者Resources.load时自动载到内存中

StreamingAssets打包时是直接复制的文件，jpg还是原来的jpg,png还是原来的png，文件一点也不会变，而Assets是经过Unity处理过的，处理成了3D引擎或者硬件可以直接使用的格式，比如图片在nvidia显卡中以dds或dxt格式使用。于是，可以理解streamingAssets是磁盘上的资源，assets是内存中的资源，需要注意的是并非所有Assets都是内存格式打包的。

下面将streamingAssets这类资源成为流资源，将Assets称为内存资源。

图片

图片是游戏中使用最多的资源，使用方式繁多，因此将会花大篇幅介绍优化理论和技巧。

有了以上理论就可以解释Unity的Inspector图片预览中显示的大小和磁盘中文件的大小不一致了，预览窗口显示的是内存格式，所以格式和大小都不一样。

图片资源在Unity中以内存资源打包，空间占用大小只和尺寸和格式有关，所以你在外部无论如何压缩图片质量，图片大小，只要不改变内存大小和内存格式，那么打包大小始终不变。

阅读下面之前，请先阅读Unity文档中关于图片导入的部分

http://docs.unity3d.com/Manual/class-TextureImporter.html

图片内存尺寸

通常为了GPU性能3D贴图资源最好使用2的n次幂，普通2D资源为了使用方便可以没有这个要求，图片尺寸优化只需要在质量可以接受情况下使用越小的越好，直接在Unity中调节max size即可。

图片内存格式

显卡能使用的只能是内存格式，Unity中的内存格式分为了3类，compressed,16bit,trueColor。

关于Alpha通道，Alpha通道是图片通道中的一个，通常表示透明，但并不一定表示透明，如果一张图片有Alpha通道，或者有透明像素，那么这张图片就带有Alpha通道。

TrueColor

trueColor,真彩色，颜色值最多，质量最好，大小最大，一般只用在追求美术质量的2D图片上。

• RGB24bit 不带A通道的图片格式
• Alpha8bit 只带有Alpha通道信息
• RGBA32bit 同时带有RGBA通道
• ARGB32bit 同时带有RGBA通道，与RGBA不同处不详

带有通道信息越少的格式，自然同样尺寸下，大小更小，所以如果一张图片没有透明或者不需要alpha通道，则不要保留alpha通道或透明像素，对于没有alpha的图片，Unity会自动选择没有alpha的格式，能够节约1/4的大小。

16bit

16bit,只包含16位色，因为颜色较少，一些渐变会出现过度不均匀，质量较差，大小比truecolor小。一般用于16位色质量可接受的图片上，或者需要alpha通道的3D贴图上。

16bit格式包含rgb16bit,rgba16bit,argb16bit,所包含的通道按照以上名字规律，需要注意的是格式大小只和bit数有关，也就是说rgb16bit,argb16bit虽然通道不一样，但都是16bit，所以大小一样，但argb16bit颜色更少，质量也越差，所以在重复一遍，不需要透明就不要保留alpha，透明不仅带来空间增大，质量也会变差。

Compressed

压缩格式，根据显卡需要的格式进行压缩，如iOS设备使用PowerVR处理器，则适合的贴图格式是PVRTC等，Android手机根据芯片不同有ETC，ATC，DXT，PVRTC等，但一般不会根据具体的手机打不同的包，所以一般选择ETC，需要注意最好不要手动选择压缩格式，应该选择auto Compress，Unity会自动选择最适合该平台的格式。如果选错格式，那么在运行时会对贴图进行转码，大大拉大加载时间。

压缩格式的图片大小，取决于不同的格式，但一般都会比trueColor或16bit小很多，质量一般还行，因此是3D贴图的首选，大部分压缩格式要求为2的n次幂，且大部分压缩格式不支持alpha或者支持alpha但效果不好。部分2D图片使用起来会稍微麻烦，比如强制为2的n次幂时sprite不能用。

Mipmap

有关mipmap的详细介绍可以参考https://en.wikipedia.org/wiki/Mipmap，简单的说mipmap是为了优化3D中的显存占用和显示效果的，开启这项图片增大33%，且相机距离较远时图片会变糊，因此，2D图片不能开启这项，3D中一般的贴图需要开启，其他酌情考虑。

图片优化总结

• 不留不必要的A通道，不留不必要的A通道，不留不必要的A通道
• 其实Unity已经做得足够智能了，一般你只需要选择贴图类型如texture,还是sprite,还是litmap，他就能自动处理好大多数了。
• 2D图片，移除mipmap，质量要求高的选用trueColor,要求低的选用16bit或compressed
• 3D贴图，酌情关闭mipmap,优先选用compressed，谨慎使用trueColor。
• 合理选择图片大小。

高级优化

16bit的优化

使用16bit时，会出现明显的颜色过度不均匀，可以通过RGBA4444和dithering优化显示效果，详细请看（翻墙才见图片）

http://electronic-blue.herokuapp.com/blog/2013/05/reduce-memory-usage-by-dithering/?utm_source=tuicool&utm_medium=referral

利用StreamingAssets的优化

一张1024x1024 RGB24的图片内存资源大小为3MB，而一张1024 x 1024的JPG图片如果优化得当仅几百K，可以将JPG图片放在StreamingAssets下，让后运行时读取，这么做确实能够在保证质量的条件下节省很多大小，但加载十分慢，需谨慎使用。

分离Alpha通道优化

压缩格式能够做到高质量小空间，但压缩格式一般对Alpha的支持较差，也就是说如果一张ARGB的图可以去掉A通道，就可以使用压缩格式来优化大小。

可以通过将Alpha通道提取出来作为另外一张图的R通道，那么我们将得到两张没有Alpha通道的图，且代表Alpha通道的图可以缩小尺寸，两张没有A通道的图一般可以比一张带A通道的图小，所以这个优化从原理上可行，也有很多游戏这么做，但是需要额外处理shader，且渲染时需要解析两张图等，综合考虑目前我们没有采用这种方式。

声音

声音资源在Unity打包时以流资源存在（待验证），也就是说文件大小会影响打包大小，Unity预览窗口中显示的大小是内存占用。在Unity中调节声音文件参数不会影响打包大小。

影响声音文件大小的因素 待补充

模型

选择模型导入中的mesh compression 可以减少模型占用包体大小，但会出现一些变形和UV精度丢失等，调节压缩到可接受的等级即可，如果是UV精度丢失（常见任务对称中心出现一条缝）可以将贴图画出UV线更多。

动作

选择动画导入中的Anim.Compression可以减少动画占用包体大小，同样可能出现动画变形等，调节到合适参数即可，一般选择keyFrame reducion。

场景

StaticBatch大小优化

场景本身在包体大小上并没有太多可以优化，但需要注意如果你的场景大量使用StaticBatch，你会发现勾选StaticBatch的场景打包后比不勾选StaticBatch要大，估计Unity在打包时把StaticBatch的网格合并成了一个，比如你有一棵树，这棵树本身只占一个模型大小，这棵树在场景中复制很多份仍然只占一个模型大小，但如果这些树勾选staticbatch，那么打包时会合并为一个树林，原来的树模型就不需要了，而是变为了一个大树林模型，大小自然变大了

解决办法：取消场景的StaticBatch，取消后DrawCall无法合并，通过调用StaticBatchingUtility.Combine进行批处理即可达到原来的效果。这个做法可能会导致场景加载时间变长，但一般感觉不出来（待测试）。

BuildReport插件

https://www.assetstore.unity3d.com/cn/#!/content/8162

Unity每次打包后会生成一个文件记录哪些资源被打包了，BuildReport可以解析这个文件让你非常方便的查看哪些资源占用空间多，针对性的处理。