背景
随着业务的迭代,我们的游戏包体也会随之变得臃肿庞大。包体的大小往往影响着我们的游戏下载的转化率,特别是在全球化的大环境下,新兴市场中大约 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等)
总结
通过对资源和代码的处理,我们可以对包体的大小进一步的控制。但是非常重要的一点是:我们在这个过程中,可以沉淀一些标准的美术规范或者程序编码规范,构建稳定的资源管线,对后续的包体大小控制,才是一个长远的对策!
标签:裁剪,游戏,可以,TreeSize,字体库,包体,缩减,资源 From: https://www.cnblogs.com/fzuljz/p/16871739.html