iPhone安装包的优化

这是一次安装包大小优化的实践。

随着业务的增加,工程中引入越来越多的业务代码和第三方库, 整个安装包越来越大。以今日头条5.7.5为例 最近几个版本的ipa大小如下:

5.7 -> 72.2M (+0.8M) 正常业务增量
5.6 -> 71.4M (+14M) 主要原因:接入某SDK后安装包的增加(约13M) 京东SDK(约1M)
5.5 -> 57.4M (+1.7M) 正常业务增量
5.4 -> 55.1M (+28M) 主要原因:加入Swift 系统会加入语言库来支持(约27M)
5.3 -> 27.5M 之前做过一次资源文件和类文件的清理

优化安装包分为如下几个步骤:

  1. 分析安装包的构成,一个安装包分为二进制代码文件,资源,配置文件。需要知道各个方面的占比。
  2. 知道各个方向的优化策略,譬如二进制文件如何优化,资源文件如何优化
  3. 执行优化,得出结果

分析

首先进行第一步,分析安装包的构成: 88M的安装包解压后变成220MB。
ipa是一个压缩包, 安装包里的主要构成是(图片+文档+二进制文件),我们下面的分析

1.图片优化:

从上面来看,图片的压缩比最小。几乎没有压缩,这也说明每减少一张图片,就实实在在的减少了ipa的大小。 为了验证上面的数据,我们来做一些实验: 我们新建一个项目, 测试资源图片对安装包的大小的影响: 目录结构如下:


其中资源信息如下:

然后进行打包Archive→Export.得到IPA文件

从上面的结果来看,安装包的大小基本等于图片资源的大小,可以看一下IPA的内容详情视图(下图), 发现图片确实没有怎么压缩:

结论1:JPG资源图片的压缩比很小,每减少一张图片,就实实在在的减少了ipa的大小。

下面我们进一步使用ImageOptim对图片进行压无损缩优化(如下图)。看能否优化下安装包大小。

压缩后,总文件大小为:屏幕快照 2016-10-25 下午8.58.24.png, 优化掉了1MB的大小。 我们然后进行打包操作,最终的安装包确实也小了0.8MB,从11.6MB变成了10.8MB,。还是有优化的,如下图所示:



此时我们看xcode里的工程配置,COMPRESSPNGFILES 是YES的,有一些说法是这个变量的设置和ImageOptim冲突, 这里看起来不是如此。

结论2:ImageOptim有时候还是确实能优化资源大小,进而减少安装包大小的。

是否因此可以完全确定ImageOptim的优化能力, 我觉得看情况而定, 上面的几种图片都是我iPhone手机里的相片导出的。是JPG的格式。

我们再对PNG做一些测试, 找一些资源图片放到工程中(我就不截图了,直截大小):

打包后的大小是:

系统帮我们优化掉1.1MB。 同样我们队图片进行一轮无损压缩优化, 经过ImageOptim优化后效果:

我们进行打包,得到的安装包的大小是:还是2.2MB(特意将系统优化关闭):

结论3: 对于我找的这几个png图片,ImageOptim的优化没有起到作用。

在我们项目中也对所有资源图片使用ImageOptim进行了优化,20多MB的资源最后优化掉1MB左右, 这里怀疑ImageOptim对PNG的优化能力一般。 而且如果能优化的PNG资源,系统默认可以进行一些优化。

2.文档资源


从上面来看,文档有一定的压缩比,大概40%,也就是如果工程里有40MB的文档,体验到压缩包里大概是40*0.6=24MB。

3.二进制安装包


二进制代码的压缩率是最高的。

上面都是研究不同的资源对最后安装包大小的影响情况,现在有了一些理论依据,我们就可以开始对安装包进行优化工作了。

实践

所以先从图片开始优化吧:

1.如何优化图片:

  1. 使用一些工具来检测unused 文件。 比较推荐的是github上的一份开源代码:
    https://github.com/tinymind/LSUnusedResource 编译运行看到的页面是这样的:

    指定搜索路径, 第二行(EXClude)指定哪些文件夹路径不被扫描。

    然后这些资源可以清除掉了。但是存在着图片被误删除的可能性,譬如代码中使用图片的方式是:[UIImage imageNamed:[NSString stringWithFormat:"icon_%d.png",index]]; 这种情况下,图片可能被误删,所以删除的时候不妨10张一组的进行,用眼睛过滤一遍。

  2. 删除完图片,是否还可以对已有的图片做优化呢。
    现在网上有非常多的关于ImageOptim对资源图片进行无损压缩的方式, 在文章开头部分我们也对ImageOptim的优化能力进行了一些验证,通过上面的实验,我觉得结论不能确定,但值得一试。

2.文档资源的优化

文档资源主要是排查:

  1. 是否有不必要的文档资源,如果过期的旧版本所需要的文档资源 清理即可。
  2. 优化文档资源大小,主要是优化精简文档内容。

3.二进制包优化

二进制包是由各种代码文件,静态库 动态库 经过编译后生成的可执行文件。 以头条二进制包125MB为例, 他是如何组成的?

上图可以看到armv7 占可执行文件的58MB。 arm64占可执行文件的66MB。 加起来=125MB。 进一步分析

通过右侧的pfile偏移可以大概算出每个段的大小,但不直观, 我们可以通过开启一些编译选项,生成可执行文件结构,然后借助一些工具生成更加直观的

  1. XCode开启编译选项Write Link Map File XCode -> target -> Build Settings -> 搜map -> 把Write Link Map File选项设为yes,并指定好linkMap的存储位置:

  2. 编译后到编译目录里找到该txt文件,文件名和路径就是上述的Path to Link Map File。
    ~/Library/Developer/Xcode/DerivedData/XXX-eumsvrzbvgfofvbfsoqokmjprvuh/Build/Intermediates/XXX.build/Debug-iphoneos/XXX.build/。 这个LinkMap里展示了整个可执行文件的全貌,列出了编译后的每一个.o目标文件的信息(包括静态链接库.a里的),以及每一个目标文件的代码段,数据段存储详情

如上图,weinAppID这个函数占得内存大小为1*16 + 13 = 29字节。 这样看下去也挺麻烦的, 找个工具归类一下。

  1. 归类,去https://github.com/huanxsd/LinkMap 下载这个mac工程 然后运行。

譬如内部播放器sdk MediaPlayer在arm64架构下大小为4.92MB, armv7也可以分析另一份armv7 linkmap文件大概4.5MB 二者加起来就是在二进制占据的总大小—10MB左右。 通过对上面的文件进行分析,就知道每个类在最终的可执行文件中占据的大小。 然后有针对性的进行优化就可以了。

4.编译选项优化:

如果项目是很早之前(xcode4,5)建立的,迭代到现在 的确可以检查一下有利于减少安装包的编译选项:

  1. Optimization Level 使用Fastest, Smalllest
    该选项对安装包大小影响几无,但可以提高app的性能。参考wwdc 2013-Session408 Optimize Your Code Using LLVM
  2. Strip Linked Product 设置为YES
    需要注意的是Strip Linked Product也受到Deployment Postprocessing设置选项的影响。在Build Settings中,我们可以看到, Strip Linked Product是在Deployment这栏中的,而Deployment Postprocessing相当于是Deployment的总开关。记得把Deployment Postprocessing也设置为YES, 该选项对安装包大小的影响非常大, 以头条客户端为例,如果不开启此设置,ipa大小是48MB,上线后appstore上显示的大小是65MB, 我们开启了此配置后,ipa大小变成40MB, appstore上显示45MB。 优化效果还是非常明显的。 PS:Deployment Postprocessing这个配置项如果使用xcode打包,xcode会默认把这个变量置为YES, 如果使用脚本打包,记得设置。
  3. Symbols Hidden by Default设置为YES
  4. Make Strings Read-Only 设置为YES

5.可能无效的办法:

将Enable C++ Exceptions和Enable Objective-C Exceptions设为NO,去掉异常支持; 如果你的项目比较大,有很多try cache, 想去掉这些异常可能是一个比较大的工作量,我在头条项目里尝试去掉了所有异常,打包测试,安装包大小没有 变化, 因为只是一个项目的测试,我只能比较怀疑去掉异常对最终安装包大小的优化能力。

6.一些额外的建议

iOS的项目,在安装包没有大到一定程度之前,研发和产品一般都关注较少,我们在平时的开发中也会有一些不好的习惯,在这里枚举一下:

  1. 不要为了一片树叶 引入一片森林。 有时候你只想接入一个base64编码的函数,结果接入了一个有几十个类文件的util库,除了你用到的这个函数,其余的可能再也不会有人用到, 另一个研发为了另一个RSA加密需求,结果又引入了另一个一个extensions库 。那些类文件都是成本,类文件,函数,甚至不同长度的函数名字都对最终的安装包大小产生影响。 积少成多, 安装包会越来越大。 而且代码量越大,app启动时候DYLD链接的工作量越大,启动耗时也会变长。
  2. 对于要接入到app的资源文件,要check一下大小,一个100*100大小的图片如果几十MB 肯定设计师在切图的时候有些问题,打包后也要check一遍。对于集体打包到Assert.car里的文件,可以找工具解开看一下。 我们遇到过打了一次包后 发现安装包大了几十MB,经过分析,发现是有一张图片意外的大,找人优化后 变成几百k。
  3. 注意平时的开发习惯,废弃模块及早清理。
  4. 同质的开源库(譬如AFnetworking vs ASIHttpRequest),只接入一种。
  5. 建立预警机制, 一般上线后,都是脚本打包,除了正常的生成ipa包之外,也要生成分析文件, 列出相对上一次上线包大了多少,类文件增加了多少。这样的机制也有助于防止安装包悄无声息的变成巨物。