前言

app的大小是一个关乎app在用户手机上存亡的事情,以前,我的手机由于内存空间较小,开启了手机的自动清理功能,经常清理一些不常用的app,记录,缓存等,如果app被用户清理掉了,基本上也就失去了这个用户,app的占用空间的大小是至关重要的因素.所以App瘦身在app的开发迭代中也是至关重要的一环,下面我将从实际经验说下我是如何做App瘦身的

影响App大小的因素

• 业务代码
• 资源文件
• 自定义库
• 第三方库
• Settings设置
  ...
  如果想了解代码层面是如何影响app大小的,可以看下我的另外一片文章Clang探究及应用

其他的比如说,bitcode、xcode设置Png Compress模式等,都不太满足条件
我主要从这几方面、分阶段的进行优化

• 业务梳理,和各个业务方、产品沟通确定业务是否还需要保留,对于可以删除的业务相关代码进行移除

• 自定义工具库优化,以往由于开发人员众多,没有统一的资源、代码管理规范,项目中会累计很多相似的功能代码,这里主要是进行相似功能代码合并,要么采用pod库管理,要么通过路由调用

• 第三方库排查,排查清理一些老旧的或者没有使用的第三方库,进行删除、替换,对于引入的一些debug工具,如果采用的是pod方式管理,我们可以在podfile中进行配置,比如pod 'MLeaksFinder', :configurations => ['Debug'],而且有些pod库还会关联其他库,比如MLeaksFinder会依赖FBRetainCycleDetector,如果我们只配置了MLeaksFinder的debug环境,没有配置FBRetainCycleDetector的debug环境,那么FBRetainCycleDetector在打release包时也是会被打包进去的,所以我们对FBRetainCycleDetector也要做debug配置

• 无用方法排查,项目开发迭代中经常会有新增的类、方法等,导致一些类文件、方法等遗忘在角落,这里推荐几个比较好用的工具
  fui、SMCheckProject、AppCode,但是这些工具检查出来的都不能确保一定是可以丢弃的,需要二次确认

• 冗余资源排查,我个人经常使用LSUnusedResources

• 图片压缩,推荐一个好用的工具PngquantPicture,支持批量遍历文件夹及子文件夹,压缩后存储在原路径,可以很方便一次性的压缩完成整个Assets文件夹,或者进行webp转换,经过比对后,直接压缩后的大小和webp相差无几,而且使用webp的话还得额外引入支持webp的相关库

• 对于资源文件>10k的,考虑能否进行网络资源配置,这里10k是个人综合比较项目资源大小后的结果,包括图片、音频、视频等

• Architechtures移除armv7

• 根据MachO文件分析各个类、库所占用的空间大小,LinkMap

• 随着业务的迭代,会有很多代码被遗弃,他们在项目中有被引用,但是在app中却没有提供功能入口,这样的比较难排查,
  我们可以在打包的版本中,从所有需要做代码资源优化的文件夹中,获取所有定义的类、方法,结合埋点统计,将长时间未调用的类、方法统计出来,确认后进行删除

当然还有apple推荐的On Demand Resources,暂未进行尝试
下面列下3个阶段的优化结果:

• V1 123.7->90.3
• V2 93.5->91.2
• V3 91.2 ->86.5