版本记录
| 版本号 | 时间 |
|---|---|
| V1.0 | 2021.04.20 星期二 |
前言
随着App的持续功能迭代和常年的运营，最终包都会越来越大，包太大苹果那边会给限制，不利于用户下载。所以App瘦身也是一项需要持续做的事。正好我这几天就在做瘦身的事，这里记录一下，大家一起学习和交流。
为什么要进行包的瘦身？
随着产品不停的进行功能迭代，代码以及图片都越来越多，包的体积越来越大，但是包太大的话一个是用户下载的流量消耗很大，二是苹果也对用户包大小下载有限制。所以，都是需要注意的，所以我们就要进行包的瘦身。
测量方案
在瘦身之前你需要知道你的包现在有多大，同时也需要在某一个阶段需要查看最终包的大小。
苹果这边体积计算方式有很多种：
- 1） 安装体积（
App Store看到的体积）。 - 2） 下载体积（实际下载占用的流量大小，用户是无感知的，因为看不到）
200M限制下载看的是这个体积。 - 3） 自己的脚本计算体积，使用构建后的
LinkMap文件计算arm64架构下代码段的体积 + 工程目录下Pods文件夹下出去代码的资源文件得出。
因为前两种苹果会根据系统和机型做不同处理，所以体积是不同的，也不具有衡量性。所以我们采用第三种方式作为我们的衡量指标，这种相对比较稳定，也易于衡量。
1. LinkMap文件测量
我这边使用LinkMap-master对可执行文件大小进行计算，这里放的都是你的代码等链接数据，比如说你新增加了代码，那么这个linkMap就会变大。首先你需要获取linkMap文件，选中一个target，在Xcode Build Setting里Write Link Map File设置为YES，然后设置linkMap文件的输出路径，在Path to Link Map File里填写你要输出文件的路径即可。
获取到linkMap文件以后，就使用一个常用的Mac程序进行解析了，还可以给出各个业务线不同的体积大小。这里由于敏感性我就不给出来我们项目的大小截图了。
注意：这里一定不能用
debug包的linkMap，而是要用release的，这两个包因为优化的差异，亲测大小要差不少。
2. 资源包测量
还有一个就是资源包大小的测量，这里我就是跑的脚本，直接计算项目里资源包有多大，最终会生成一个各个业务线的资源包体积大小，然后将这个结果和上面linkMap测量结果加起来就是最终的包估计大小。脚本最终还生成了excel文档，给出了各个业务线不同的包的大小。
瘦身方案
包缩减的方案有很多，但是不管使用任何方法，归根结底都是从两个地方出发：
- 减少包内资源的体积，包括图片等
- 减少代码，即可执行文件的体积
1. 减少资源包体积
这里可以从下面几个方向入手：
- 减少不用的图片，比如使用
LSUnusedResources进行扫描，里面还可以设置白名单，排除对某一个资源包的扫描。 - 压缩现有的图片资源，由于
png是无损压缩，所以你不用担心压缩导致失真的问题。压缩工具比较多，比如熟知的tinyPng网站就很不错，简单好用，不用下载任何程序。
2. 减少代码体积
- 删除废弃的代码
- 有些三方模块比较重的话可以废弃或者用一些小的替换。
除了我上面提到的两种我实践过的方案外，还有另外几个方向可以尝试：
- 图片格式的转化，比如
png可以转化为webp。- 苹果提供的
ODR的使用。
我们目前的包体积，还在可控范围内，所以还没有这两张方式进行缩减，同时，业务线比较多，也需要和平台各个业务线一起统筹做这个事。
参考文章
后记
本篇主要讲述了
App的包瘦身计算，感兴趣的给个赞或者关注~~~
