Aeee59f7c3869062915816c00a5535bc
iOS 瘦包,常见方式梳理

关于瘦包这个话题,之前大家讨论的已经够多了。

之所以再写这篇文章,主要是对前段时间工作的一个总结、梳理。同时也补全优化这个系列。

PS:

本文主要是思路、常见方式的梳理,工具的介绍。

具体的优化数据、内容,就不对外说明了。

那么,开始吧~


1. 预备知识

1.1 App Thinning

什么是 App Thinning?当然是减小包体积了,这也要说明吗?

当然不是.. 这里的 App Thinning 是指,iOS 9 之后引入的一项优化。官方描述如下:

The App Store and operating system optimize the installation of iOS, tvOS, and watchOS apps by tailoring app delivery to the capabilities of the user’s particular device, with minimal footprint. This optimization, called app thinning, lets you create apps that use the most device features, occupy minimum disk space, and accommodate future updates that can be applied by Apple. Faster downloads and more space for other apps and content provides a better user experience.

即,Apple 会尽可能的,自动降低分发到具体用户时,所需要下载的 App 大小。这其中又包括三项主要的功能:SlicingBitcodeOn-Demand Resources

1.1.1 Slicing

当向 App Store Connect 上传 .ipa 后,App Store Connect 构建过程中,会自动分割该 App,创建特定的变体(variant)以适配不同设备。然后用户从 App Store 中下载到的安装包,即这个特定的变体。这一过程,就是 Slicing。

Slicing 是创建、分发不同变体以适应不同目标设备的过程。

而变体之间的差异,又具体体现在架构和资源上。换句话说,App Slicing 仅向设备传送与之相关的资源(取决于屏幕分辨率,架构等等)

其中,2x 和 3x 的细分,要求图片放在 Asset Catalog 中管理。Bundle 内的则还是会同时包含。

下图中,右侧的则是各个不同的 variant。

1.1.2 Bitcode

Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the App Store.

Bitcode 是一种程序中间码。包含 Bitcode 配置的程序将会在 App Store Connect 上被重新编译和链接,进而对可执行文件做优化。这部分都是在服务端自动完成的,所以假如以后 Apple 推出了新的 CPU 架构或者以后 LLVM 推出了一系列优化,我们也不再需要为其发布新的安装包了,Apple Store 会为我们自动完成这步,然后提供对应的 variant 给具体设备

对于 iOS 而言,Bitcode 是可选的(Xcode7 后新项目,默认开启),对于 watchOS 和 tvOS,Bitcode 则是必须的。开启方式如下:

开启 Bitcode,有这么两点需要特别注意:

  • 全部都要支持
  • 崩溃定位

所谓全部,就是指我们依赖的静态库、动态库,都必须包含 Bitcode。另外用 Cocoapods 管理的第三方库,都需要开启 Pods 工程中的 BitCode。否则,会编译失败。

另外,开启 Bitcode 后,最终的可执行文件是 Apple 自动生成的,同时会产生新的符号表文件,所以我们无法使用自己包生成的 dSYM 符号化文件来进行符号化。

For Bitcode enabled builds that have been released to the iTunes store or submitted to TestFlight, Apple generates new dSYMs. You’ll need to download the regenerated dSYMs from Xcode and then upload them to Crashlytics so that we can symbolicate crashes.

For Bitcode enabled apps, ensure that you have checked “Include app symbols for your application...” so that we can provide the most accurate crash reports.

上面是 fabric 中关于 Downloading Bitcode dSYMs 的描述。

在上传到 App Store 时需要勾选 “Include app symbols for your application...” 。勾选之后 Apple 会自动生成对应的 dSYM,然后可以在 Xcode —> Window —> Organizer 中, 或者 Apple Store Connect 中下载对应的 dSYM 来进行符号化:


那么你可能疑惑,Bitcode 对 App Thining 有什么作用?

New Features in Xcode 7 中,有这么一段描述:

Bitcode. When you archive for submission to the App Store, Xcode will compile your app into an intermediate representation. The App Store will then compile the bitcode down into the 64 or 32 bit executables as necessary.

即,App Store 会再按需将这个 bitcode 编译进 32 / 64 位的可执行文件。

所以,网上铺天盖地的,都是说 Bitcode 完成了具体架构的拆分,从而实现瘦包。

但我对这个观点持怀疑态度,我认为架构的拆分是由 Slicing 完成的,Bitcode 的优势,更多体现在性能、以及后续的维护上。

PS:

因为在写这篇文章的时候,美图秀秀已经放弃了 32位 以及 iOS 8,另外,其他依赖有的没开启 Bitcode,推动代价较大,故对这个结论,暂时没有验证。

1.1.3 On-Demand Resources

On-Demand Resource,即一部分图片可以被放置在苹果的服务器上,不随着 App 的下载而下载,直到用户真正进入到某个页面时才下载这些资源文件。

关于这点,目前未有这方面的打算,故不继续深入研究。

注意:如果还需要支持 iOS 9 以下系统,那么无法使用这个功能,否则上传的时候会失败。


1.2 包体积

首先理清两个概念:

  • .ipa(iOS App Store Package):iOS 应用程序归档文件,即提交到 App Store Connect 的文件。
  • .app(Application) :是应用的具体描述,即安装到 iOS 设备上的文件。

当我们拿到 Archive 后的 .ipa,使用 “归档实用工具” 打开后,Payload 目录下放的就是 .app 文件, 二者大小相当。

至于包体积,我们评判的标准,当然是以 App Store 上看到的为准。但是上传到 App Store Connect 处理完后,会自动帮我们生成在具体设备上看到的大小,如下:

这其中,又可以分成这两类:Universal具体设备
Universal 指通用设备,即未应用 App Slicing 优化,同时包含了所有架构、资源。所以把体积特别大。

同时,观察 .ipa 文件的大小,可以发现和 Universal 对应的安装大小相当,稍微小一点,因为 App Store 对 .ipa 又做了加密处理。

再额外补充一点,有时候下载 App 的时候,会提示:“此项目大于150MB,除非此项目支持增量下载,否则您必须连接至WiFi才能下载。”。 这里的 150M 限制,是针对下载大小

  • 下载大小:通过 Wi-Fi 下载的压缩 App 大小。
  • 安装大小:此 App 将在用户设备上占用的磁盘空间大小。

所以,我们要瘦包的话,关键在与减小 .app 文件的大小。另外,.ipa 文件的大小,可以作为最终的评判标准,不需要严格的上传验证。


1.3 .app 组成

提到瘦包,我们肯定是要对这个包的具体组成,进行分析,然后才能有目的的进行优化。

.app 文件显示包内容后,会看到 一大堆杂乱的文件。按照个人习惯,整理归类后,如下:

按照 Size 排序,这样哪部分占用比较严重就一目了然了。

这里介绍一个工具 Hazel

Hazel 是一款可以自动监控并整理文件夹的工具,其官网的介绍就是简单的一句话:Automated Organization for Your Mac。

它的使用有点类似于网络服务 IFTTT,你可以设定一个 if 条件,如果被监控的文件夹出现符合条件的项,那么对其执行 then 的操作(也可以通过邮箱的收件过滤规则来理解)。

即,我们可以自定义规则,来达到文件归类。

比如这里,为了对 .app 内的文件进行细分,针对文件的具体情况,我添加了“按类型”、“按模块” 两套规则,具体如下:

这样,每次有新的 .app,都可以对相关的文件进行自动划分,一劳永逸。强烈推荐~


回到我们的分析环节,按照优先级,以及具体的业务需求,接下去,我将会对 “可执行文件、资源、动态库、Extension” 这四部分进行详细优化、说明。

2. Architectures

因为美图秀秀已经放弃了 32位 以及 iOS 8,所以多架构本身的影响,就不去考虑了。

当然,去掉 armv7 后,可执行文件以及库的大小,必然会大大减小。即本地 .ipa 的大小也会大大减小。

但是需要注意,iOS 9 之后的设备,App Store 上显示的安装大小,不受影响。原因就是之前提到的 App Slicing。

这里不再细说,去不去 32位 支持,还是据项目实际情况看,没什么参考价值。


3. Resources

资源部分的优化,说白了就是对内的一次审查,规范化。

按照个人习惯,我会把资源进一步细分成如下:(同样,可以借助 Hazel 来完成)

其中,图片 和 Bundle 这两个文件夹,都指代图片资源。

  • 图片:Assets.car
  • Bundle:非放在 Asset Catalog 中管理的图片资源。包括 Bundle,散落的 png/jpg 等。

其他几个,就很好理解了。比如字体,就是内置的 .ttf / .otf 等字体文件。

音频又包括 .mp3 / .mp4 / .caf / .dat 等音频文件。

在回到瘦包,针对资源部分,我这里按照这几种方式来进行:

  • 无用文件删除
  • 重复文件删除
  • 大文件压缩
  • 图片管理方式规范
  • On-Demand Resource

其中,On-Demand Resource 上文已经提到,这里不再累述。游戏类的,有前置关卡依赖的,建议资源改用这种动态下载的方式。


3.1 无用文件删除

无用文件删除,主要包含图片和非图片部分。

非图片部分,资源较少,使用方式固定。比如音频,字体。这部分,需要靠人力去排查。

美图秀秀在这方面的优化空间有限,因为本身就没怎么依赖这些东西。

而无用图片,就比较多了。

主要使用一个开源的 Mac app,LSUnusedResources,来进行冗余图片的排查。

这个 App 的原理是,对某一文件目录下所有的源代码文件进行扫描,用正则表达式匹配出所有的@"xxx"字符串(会根据不同类型的源代码文件使用不同的匹配规则),形成“使用到的图片的集合”,然后扫描所有的图片文件名,查看哪些图片文件名不在“使用到的图片的集合”中,然后将这些图片文件呈现在结果中。

扫描速度快,扫描结果可以直接进行删除,导出等操作。

但是这工具,存在一点问题,会出现误报。主要还是因为项目中,使用到的图片方式不一。

比如,icon_01_01.png、icon_1_1_highlighted.png这样的命名,都会被标记为无用。

查看源码,主要是因为模糊匹配这部分的源码,限定了至多一个下标索引的情况。

即,只会处理这类的:

  • prefix + suffix + number
  • prefix + number + suffix
  • number + prefix + suffix

但显然,和项目现有的一些命名存在冲突。故,修改对应的正则,使之满足自己项目即可。

另外,喵神还提供了一个脚本 FengNiao,比较新,使用 Swift 开发的。FengNiao 的原理和 LSUnusedResources 差不多,都是先查找出项目中所有使用到的字符串和项目中所有的资源文件。然后二者进行匹配对比,计算差集就是未使用的资源。另外,FengNiao 是命令行工具,所以可以在 Xcode 中添加 Run Script,在每次构建的时候自动检测未使用的资源。

PS:

但是使用后发现,同样也会存在很多误报的情况。也需要改源码,才能适配现有的工程。故没有深入使用。

当然,工具毕竟是工具,筛选出来的结果,还需要进行一轮人工校验,才能大胆的删除。

这部分的优化,视项目的具体情况而定。如果之前团队内部一直做的很规范,那这部分的优化空间也会比较小。


3.2 重复文件删除

重复文件,即两个内容完全一致的文件。这类文件的命名上,一般是不一样的。

这部分,主要是借助 fdupes 这个开源工具,它可以校验各资源的 MD5。

fdupes 是 Linux 下的一个工具,它由 Adrian Lopez 用 C 语言编写并基于 MIT 许可证发行,该应用程序可以在指定的目录及子目录中查找重复的文件。fdupes 通过对比文件的 MD5 签名,以及逐字节比较文件来识别重复内容,fdupes 有各种选项,可以实现对文件的列出、删除、替换为文件副本的硬链接等操作。

文件对比以下列顺序开始:

大小对比 > 部分 MD5 签名对比 > 完整 MD5 签名对比 > 逐字节对比

效率、准确率都极其高。强力推荐!

最终的检测结果,如下:

会细分出相同文件的大小,以及位置。

然后,就是具体的进行优化了。


3.3 大文件压缩

图片本身的压缩,建议使用 ImageOptim。它直接整合了Win、Linux上诸多著名图片处理工具的特色功能,比如:PNGOUT,AdvPNG,Pngcrush,OptiPNG,JpegOptim,Gifsicle 等。

Xcode 提供的给我们两个编译选项来帮助压缩 PNG 图像:

  • Compress PNG Files:打包的时候自动对图片进行无损压缩,使用的工具为 pngcrush,压缩比还是相当高的,比较流行的压缩软件 ImageOptim 也是使用 pngcrush 进行压缩 PNG 的。

  • Remove Text Medadata From PNG Files:移除 PNG 资源的文本字符,比如图像名称、作者、版权、创作时间、注释等信息。

在开启 Xcode 内置的 PNG 压缩后,使用 ImageOptim 对图片再手动进行一轮压缩,发现表现是正向的。

但之前今日头条有篇文章,里面提到一个观点:

在查阅了一些文档后,我们了解到,Xcode在构建的过程中,有一个步骤叫做compile asset catalog。在这个步骤中,Xcode会自行对png图片作压缩,并且会压缩成能够快速读取渲染的格式。如果我们对工程中的图片进行了ImageOptim的压缩,在compile asset catalog的过程中,Xcode会用自己的算法重新压缩,而这个”重新压缩“的过程,相当于将ImageOptim的压缩“回滚“了,很可能反而增大了图片。

但在我验证过程中,未发现因为使用了 ImageOptim 压缩,而引起的增大现象。(会出现增大情况,但不是由于 ImageOptim,下午会提到。)

所以这里,我的建议是,保持 Xcode 提供的 Compress PNG Files 开启,再用 ImageOptim 对图片进行一轮压缩,尤其是 Bundle 内的,因为 Bundle 是直接拷贝进项目,并不会被 Xcode 进行压缩。还有 JPEG 格式的图像,也需要手动进行压缩。


3.4 图片管理方式规范

这部分,有一些常见的问题需要规避。

首先,我们要知道,工程中所有使用 Asset Catalog 管理的图片(在 .xcassets 文件夹下),最终输出的时候,都会被压缩到 Assets.car 内。

top Created with Sketch.