首先需要了解下ipa包的组成： ipa是一个压缩包， 安装包里的主要构成是（图片+文档+二进制文件）
那么总的原则就是找到这些无效的东西清理掉。还有就是修改编译器的一些设置。
（1）项目从混编改为纯OC或者纯swift编程
（2）无用资源文件清理
（3）工具类、工具方法合并
（4）无用业务排查下线 ，无用类清理，无用第三方库清理
（4）编译选项优化
（5）部分资源文件云端下载
这个是头条的优化体积文章，里面提到了很多工具的使用www.jianshu.com/p/2c914530b…
资源优化，清除无效图片，类，方法等
资源优化
删除无用图片
使用 LSUnusedResources 查找无用图片。注意 [UIImage imageNamed:[NSString stringWithFormat:"icon_%d.png",index]]; 这种使用图片的方式，可能会被误删。 使用Assets.xcassets来管理图片也可以减小安装包的体积
删除重复资源
其他技巧（选用） 用 LaunchScreen.storyboard 替换启动图片。
本地大图片都使用 webp。
资源按需加载，非必要资源都等到使用时再从服务端拉取。 查找重复文件
我们通过 fdupes 工具来扫描查找重复文件。fdupes 是通过校验所有资源的 MD5，筛选出项目的重复资源。文件比较顺序依次为：
大小对比 部分 MD5 签名对比 完整 MD5 签名对比 逐字节对比
可执行文件优化
使用 LinkMap 分析库的使用情况
三方库优化
- 删除不使用的三方库。
- 功能用的少但是体积大的三方库可以考虑自己重写。
- 合并功能重复的三方库。
代码分析
- 用 AppCode 进行代码扫描。
- 利用AppCode 检测未使用的代码：菜单栏 ->Code->InspectCode。 最后要说：xcode BulidSetting中的设置都可以区分debug和release，如果觉得在开发的时候还想用到这些，就把debug和release分开设置就可以了
- 去掉无用的类及文件。
- 清理 import。
- 去掉空方法。
- 去掉无用的 log。
- 去掉无用的变量。
按责分配模块，review 代码，去除重复代码。也是工作量比较大的一个模块
其他技巧（选用）
-
将业务打包成动态库。如果动态库的加载时机不控制好，会影响 App 的启动速度，权衡使用。
-
动态化。将一部分 Native 界面用 RN/Weex 重写。
-
去除 Swift 代码，Swift 的标准库是打包在安装包里的，一般都有 10M+。然后苹果官方说等到 Swift Runtime 稳定之后会合并到 iOS 系统里，那时候使用 Swift 就不会显著增加包大小了。
苹果官方的策略
开启 BitCode
编译选项改进
1、配置编译选项
（Levels选项内）Generate Debug Symbols 设置为NO，这个配置选项应该会让你减去小半的体积。注意这个如果设置成NO就不会在断点处停下
2、舍弃架构armv7
armv7用于支持4s和4，4s是2011年11月正式上线，虽然还有小部分人在使用，但是追求包体大小的完全可以舍弃了。
3、build setting 里 DEAD_CODE_STRIPPING = YES（好像默认就是YES）。 确定 dead code（代码被定义但从未被调用）被剥离，去掉冗余的代码，即使一点冗余代码，编译后体积也是很可观的。
4、编译器优化级别
Build Settings->Optimization Level有几个编译优化选项，release版应该选择Fastest, Smalllest[-Os]，这个选项会开启那些不增加代码大小的全部优化，并让可执行文件尽可能小。
5、去除符号信息
Strip Debug Symbols During Copy 和 Symbols Hidden by Default 在release版本应该设为yes，可以去除不必要的调试符号。Symbols Hidden by Default会把所有符号都定义成”private extern”，设了后会减小体积。
6、Strip Linked Product：DEBUG下设为NO，RELEASE下设为YES，用于RELEASE模式下缩减app的大小；
7、编译器优化，去掉异常支持。Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO，Other C Flags添加-fno-exceptions
8、LTO，即Link Time Optimization。
苹果在2016年的WWDC What’s new in LLVM中详细介绍了这一功能。LTO能带来的优化有： （1）将一些函数內联化
（2）去除了一些无用代码
（3）对程序有全局的优化作用
在build setting中开启Link-Time Optimization为Incremental。苹果还声称LTO对app的运行速度也有正向帮助。
但LTO也会带来一点副作用。LTO会降低编译链接的速度，因此只建议在打正式包时开启；开启了LTO之后，link map的可读性明显降低，多出了很多数字开头的“类”（LTO的全局优化导致的），导致我们还经常需要手动关闭LTO打包来阅读link map。
暂时可以看到了主流优化就是这些了，最后多说下7，8：
从我们的项目来看，因为我们项目中只用了非常少量的try catch来处理一些异常，把这些代码注释掉并且关闭Enable C++ Exceptions, Enable Objective-C Exceptions这两个选项之后，项目的linkmap体积从3.7mb减少了约140kb。
Link-Time Optimization
在链接时而非编译时的优化方式，可以增加程序运行时的速度
优化内联函数（个人认为是文件间的函数做内联优化）
移除没有被调用的方法和代码
整体优化-让你的程序变得更屌
小结：
图片资源的优化：
1.无用图片的删子除 2.有用图片进行无损压缩
文档资源的优化
文档资源主要是排查：
是否有不必要的文档资源，如果过期的旧版本所需要的文档资源 清理即可。
优化文档资源大小，主要是优化精简文档内容。
3.二进制包优化 二进制包是由各种代码文件，静态库 动态库 经过编译后生成的可执行文件。 这里推荐一个归类工具：github.com/huanxsd/Lin… 通过对上面的文件进行分析，就知道每个类在最终的可执行文件中占据的大小。 然后有针对性的进行优化就可以了。
图片大小 = 图片格式容量 * 像素个数
使用display p3则每个通道占用16位，那么占用内存大小是imageWidthimageHeight8 字节
如何选择正确的图片格式不要主动选择图片格式，让格式选择你。
webP
WebP是google创造出的一种图片格式，在无损压缩的情况下，比png要小28%左右。 是正常图片的1/3
WebP的劣势
把WebP说得这么天花乱坠，但是WebP也是有自己的劣势的：
压缩时间长，大概是png的8倍左右（不过一般都是在服务端压缩，客户端解码，所以服务端可以做个预压缩） 解码时间比png长，大概几十毫秒。
WebP是节省了流量（图片小），增加了解码时间，换句话说就是：同样的图片，网络越快（图片更小的WebP就没有明显优势），图片越多（WebP要解码），WebP比png要慢。
UIWebView，WKWebView都不支持WebP。（UIWebView可以用NSUrlProtocol来解决，但是WKWebView还没有太完美的办法，谁知道的请告诉我下）
不支持流式解压缩（即图片加载的时候会由模糊慢慢变清晰的过程，WebP貌似不支持这种解压缩方式）
