首先需要了解下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貌似不支持这种解压缩方式)