版本记录

前言

随着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的使用。
  我们目前的包体积，还在可控范围内，所以还没有这两张方式进行缩减，同时，业务线比较多，也需要和平台各个业务线一起统筹做这个事。

参考文章

1. siOS-APP瘦身

后记

本篇主要讲述了App的包瘦身计算，感兴趣的给个赞或者关注~~~