背景
随着业务的迭代，我们的游戏包体也会随之变得臃肿庞大。包体的大小往往影响着我们的游戏下载的转化率，特别是在全球化的大环境下，新兴市场中大约 70% 的用户会在下载前考虑 app 的大小（来源Google报告）。游戏包体的大小直接关系到了游戏厂商推广渠道的成本问题。
定位问题
工具
- 推荐TreeSize。下载并解压我们打好的android包，右键通过TreeSize分析。TreeSize可以通过不同形态的UI显示，快速定位到当前内存占用较大的模块。
- UPR工具。通过集成UPR工具生成报告，我们可以通过内存快照截图，反推查看对应的资源是否符合预期来进行资源的调整，从而减小包体大小。
分析问题
-
资源
资源一般都是包体过大的罪魁祸首。Apk解压后的目录下，Assets/Android一般存放的都是我们的资源文件。通过TreeSize对文件的分析，我们可以大概得到我们占比比较重的几个模块，然后针对这些模块进行拆分分析，解决我们的问题。
下面列举几个常见的资源问题：- 冗余资源。包括但不限于视频资源、测试图片资源、demo场景资源、冗余预制体等，删除这些多余的资源（写一个反查找引用的工具进行检查会更稳健一些）
- 字体库种类过多。UI在设计界面的时候，往往会引入很多使用率很低的字体库，可以通过跟UI协商，确定一至三个的字体，避免字体库的冗余。大一些的字体库在10M左右，如果能节省下来是比较可观的。平衡动态字体和静态字体，一般选用一种方式即可。
- Shader变体过多。可以通过修改Shader字段，减少Shader变体数量。Unity优化着色器变体
- 针对小图进行图集的生成。对长宽都在512以下的图片，进行图集的处理（需要平衡渲染的需求，不要导致DrawCal过分升高影响性能）。
- 注意：小图在合成图集的时候，可以将没有带Alpha通道的图合成一张图集，然后使用不带Alpha通道的压缩格式去压缩，能更大程度的压缩图片大小
- 修复图片长宽，使其为4的倍数。我们知道ETC2或者ASTC压缩格式，必须要求图片的长宽均为4的倍数才可以。可以通过编写工具方式来进行查找并修改，这边有个python工具的传送门可以参考一下。
-
代码和配置
处理完资源，我们会发现lib这个文件夹也占了挺大的比例的。lib文件夹里面存放的就是我们的C#代码，通过IL2CPP生成的SO文件啦。- 构建release包，可以更准确的判断lib库的大小。Debug包附带了Debug代码逻辑，会使得so变大
- 开启代码裁剪。开启BuildSetting下的Strip Engine Code，调整裁剪的尺度（跟你的C#代码有关，裁剪过大会使得一些反射调用的逻辑出错，越高级别的裁剪需要测试验证）。如果裁剪粒度不适合可以调整裁剪粒度，或者通过添加裁剪过滤清单进行添加。
- 删除无用的表格配置
- 删除无用的协议（protobuff或者Json等）
总结
通过对资源和代码的处理，我们可以对包体的大小进一步的控制。但是非常重要的一点是：我们在这个过程中，可以沉淀一些标准的美术规范或者程序编码规范，构建稳定的资源管线，对后续的包体大小控制，才是一个长远的对策！
