APP经过几年的迭代、几个APP的合并，包体大小从90M逐渐升级到了300M，如此恐怖的涨幅需要一次包体优化，优化IPA & APK 100M+，废话不多说直接上干货。
第一步，对iOS AdHoc ipa 和 APK包的分析整理表格，确认每个资源的占用体积大小，并确认初步解决方案
| 类型 | 大小 | 方案 | 步骤 |
|---|---|---|---|
| Assets 资源 | 202 MB | 删除无用、重复资源；远程下载 | 1.删除本地H5_xxx资源，由于访问量很低,故使用远端加载；2.删除本地无用音频资源包，对已有音频资源进行无损压缩。3.对所有图片进行一次压缩https://tinify.cn4.移除IJKMediaPlayer.framework, 节省89M，使用IJK源码制作组件导入Voipbase，本身项目里引入FFmpeg,IJK中同样打包了FFmpeg,库重复引用。做成pod私有仓库引入项目 |
| 主二进制 | 91 MB | 无用、重复代码清理，下线过期业务 | 几年的迭代项目中沉淀了很多废弃的xib,.m等文件，增加了很多无效类和资源导致包体变大，还会增加启动阶段类的注册导致启动过慢，删除之。 |
| 动态库 | 79M | Flutter业务下线转Native | 项目中虽然引入了Flutter，但主要还是Native开发，体验上还是和Native有不少差距，且需要不停的维护更新，后期建议移除 |
| H5离线包 | 3.1M | 点击率较低远程下载 | 放到OSS远端 |
| gif动图 | 6.2M | 转APNG WebP Lottie 或远程下载 | 需要设计师提供对应的格式 |
| 音视频 | 4.1M | 无用资源删除 | - |
| i18n语言包 | 11 MB | 无用、重复翻译清理 | 15个国家语言，添加容易删除难，用脚本捋出来4000多个无用key，但由于测试量太大且收益不高，暂缓 |
| nib | 4.3M | 尽量使用纯代码时间 | 纯代码或SwiftUI |
Appstore ipa，
注：SwiftSupport、Symbols仅Appstore 包含，ADHoc ipa(iOS11+) 优化后 安装大小217MB+， 下载大小133M。
开发人员从appstoreconnect上看到的是两个体积，下载大小和安装大小。 这里的大小分为两个口径：
下载大小 和 安装大小。
根据网页上的说明：
安装大小 是这个 app 安装后，会占用的磁盘大小；
下载大小 是 app 经过压缩后的大小。
用户在 app store 上看到的大小，就是 itunes connect 后台中显示的 安装大小。
而令开发者在意的，“超过 200 MB 的 app 必须连接至无线局域网才能下载”的规则中的 200 MB，指的其实是 下载大小。
只支持iOS13+对安装大小影响不大，但是对iPhone7~iPhoneXR的下载大小有显著下降，200MB+降为133MB左右
所以通过对比，果爹在最小版本iOS 13上对Swift module做了很大优化。
后续可优化方向：
GIF图片部分1MB以上可以尝试压缩或者替换方案，部分过期资源可以排查清除 散落图片资源移到Assets管理，部分图片在线加载？ *会增加OSS的下行流量成本；可以转lottie, 设计师图片转换为Json文件。待调研转化数据收益率。icon font.
减少动态库引用 *国内/国外依赖库分开，项目各自依赖；影响启动速度。
移除Flutter可以直接减少Framework中Flutter/App.framework及其依赖的alivcffmpeg、AliyunVideoCore共51MB（解压后）
腾讯P2P是否移除 18.7M. *未使用腾讯P2P方案，但实际库和代码还在工程里有19M
IJKMediaplayer.framework *移除Framework，使用源码导入，需要大量测试
XCode 最小编译版本号升级为13，SwiftMoudle 和符号文件产物会减少，加快下载速度 目前IOT是11，升级11,12会使用户无法更新。
第三方库的依赖很多，有些可以自己开发完成的尽量不要用第三方库，比如shareSDK.
