瘦身方案:
原因:
1.App包体积过大，对用户的安装率和更新率会有影响
2.公司要求iOS安装包大小最大不得超过150MB
3.iOS13之前的系统以前明确要求150M以上的安装包,必须在wifi环境下才能下载安装,从iOS13开始放宽到200M,而且设置里面给了用户选择的配置.
分析包体大的原因
通过对ipa包解压,可以看到我们的Mach-o, framework, Assert.car, 以及其他resource的占比, 找到占比较大的地方
代码优化:
1.版本差异化监控
在自动打包平台增加了一些用于监控版本差异的脚本，用于对比各个版本间包大小的增长量。如果发现当前版本的包大小较上一版本有较大增长，则会以钉钉报警的方式通知给开发人员。
2.技术手段排查dead code
1.无用类排查: (最终清理30个, ipa优化700k)
MachO文件中有__DATA.__objc_classrefs段和__DATA.__objc_classlist段段, otool工具导出这两个段之后,使用脚本筛选出差集对应的类后，还需要进行一遍人工选择。因为动态使用的类、从nib或storyboard初始化的类以及在同一个文件中定义的多个类会被误判为未使用的类。这需要结合业务进行一次梳理
2.无用方法排查: (300+方法累计0.5M, 清理工作较大,所以只清理了一小部分)
__DATA.__objc_selrefs 段，提取可执行文件里引用到的方法名：使用这种方法取到的差集，还需要排除掉系统API中的protocol方法等。考虑到删除方法的工作量和风险都相对较大，所以我们只删除了部分能够确认没有引用的方法
3.无用的第三方库清理, 如果仅仅使用了其中的某一个功能,采取部分加载的方式或者自己实现, 优化5M
4.属性动态化
我们通常使用@property修饰的属性,系统默认会帮我生成_开头的成员变量以及set/get方法,如果我们仅仅是给属性赋值或者使用, 可以使用成员变量的方式 self->XX, 访问和赋值
3.buildSettings-> Link Time Optimization设置为Incremental(优化2M)
苹果在2016年的WWDC What’s new in LLVM中详细介绍了这一功能。LTO能带来的优化有：
（1）将一些函数內联化
（2）去除了一些无用代码
（3）对程序有全局的优化作用
LTO也会带来一点副作用。LTO会降低编译链接的速度, 降低link map的可读性, 所以建议测试环境关闭, 线上环境打开
4.资源优化:
失败的尝试:.
1.png图片压缩(因为xcode自带的会压缩)
2.废弃asset catalog(因app slicing(apple根据不同的设备生成和下发不同的安装包)而得不偿失)
有效的优化:
- 1.冗余图片排查: 优化5M
- 2.不常用的图片使用On-Demand Resources, 按需加载,优化5M 一部分图片可以被放置在苹果的服务器上，不 随着 App 的下载而下载，直到用户真正进入到某个⻚面时才下载这些资源 文件 NSBundleResourceRequest对资源请求,请求完读取图片的规则不变
- 3.大图通过云端下载,大的资源文件,比如gif, mp4等, 云端加载, 只把关键的比如首页展示的放本地, 优化30M
