前言

今日頭條 iOS 端從 2016 年起就關(guān)注到了安裝包大小的問題，并啟動了包大小優(yōu)化。2017 年，我們將當(dāng)時的經(jīng)驗(yàn)發(fā)表為技術(shù)文章 《干貨｜今日頭條iOS端安裝包大小優(yōu)化—思路與實(shí)踐》[1]。

如今三年過去了。今日頭條在繼續(xù)探索包大小優(yōu)化時實(shí)踐了更多思路，包括構(gòu)建配置、圖片壓縮、__TEXT 段遷移、二進(jìn)制段壓縮等。這些優(yōu)化項(xiàng)在業(yè)務(wù)入侵較少的前提下給今日頭條帶來了顯著的包大小收益。同時，整個業(yè)界在包大小優(yōu)化上也產(chǎn)出了更多方案。因此我們更新文章，期待與大家共同交流包大小優(yōu)化這件事。

表格：今日頭條落地的優(yōu)化項(xiàng)和收益一覽

一、安裝包的構(gòu)成

當(dāng)我們通過構(gòu)建，獲得了一個經(jīng)過了 App Slicing 后的 ipa 文件后，將其用 zip 解壓縮方式解壓，進(jìn)入 .app 文件后，我們就可以直觀地看到安裝包中的內(nèi)容。

一個安裝包，往往包含資源與 iOS 上的可執(zhí)行文件 Mach-O 文件兩部分，資源又可以分為 Asset Catalog 的構(gòu)建產(chǎn)物 Assets.car 文件和其他資源。其中 Assets.car 文件和 Mach-O 文件，是我們投入較多精力優(yōu)化的部分。

1.1、Assets.car 文件

Assets.car 文件是工程中 Asset Catalog 的構(gòu)建產(chǎn)物。Xcode 工具鏈中的 actool 負(fù)責(zé)構(gòu)建 Assets.car。在構(gòu)建 Assets.car 的過程中，actool 會按照一定策略選取編碼算法，對其中的 png 圖片重新編碼。

圖：Asset Catalog

1.2、Mach-O 文件

Mach-O 文件是 iOS 上的可執(zhí)行文件，它是由代碼源文件經(jīng)過編譯和靜態(tài)鏈接獲得。經(jīng)過 App Slicing 之后的 Mach-O 文件往往僅包含單個架構(gòu)。使用 MachOView 等工具，我們可以直觀了解 Mach-O 中包含的內(nèi)容。

同時，Link Map 文件能更進(jìn)一步幫助我們分析 Mach-O 文件的構(gòu)成。

在 Build Settings 中打開 LD_GENERATE_MAP_FILE 開關(guān)，構(gòu)建 App 的過程中就會生成一個名叫 Link Map 的 txt 文件，它能展示每個段、每個節(jié)、每個函數(shù)在 Mach-O 中的分布和大小。這些信息是包大小優(yōu)化中經(jīng)常使用的。

二、資源大小優(yōu)化

“壓縮資源”往往是最容易被聯(lián)想到的包大小優(yōu)化方案，但實(shí)際操作起來，卻也包含技巧。今日頭條在資源優(yōu)化上做了諸多嘗試。

2.1、使用合適的資源壓縮配置

今日頭條目前最低支持的 iOS 系統(tǒng)版本為 iOS 9。然而，大部分 Pod 庫的 Podspec 文件中指定的deployment_target（最低支持版本）由于未及時修改，依然還是 iOS 8，這就導(dǎo)致了這些 Pod 庫中指定的 resource_bundles 在構(gòu)建出 Assets.car 時，是以 iOS 8 為最低支持版本的。

我們通過實(shí)驗(yàn)發(fā)現(xiàn)：

1、將 Pod 庫和主工程的最低支持版本從 iOS 8.0 提升成 iOS 9.0

2、開啟 Pod 庫和主工程 Xcode Build Settings 中的 ASSETCATALOG_COMPILER_OPTIMIZATION space 選項(xiàng)

這兩項(xiàng)設(shè)置可以改變 actool 構(gòu)建 Assets.car 時選取的編碼壓縮算法，減小包大小。我們可以使用 xcrun assetutil --info Assets.car 命令檢查 Assets.car 中每張圖片使用的編碼壓縮算法。在今日頭條環(huán)境下，整理的結(jié)果如下：

由于 Assets.car 中 png 圖片的編碼壓縮算法得到了改變，這兩項(xiàng)配置在今日頭條落地時獲得了 2.31MB 的包大小收益。

2.2、使用 RGB with palette 壓縮圖片

在今日頭條投入包大小優(yōu)化的早期，我們曾嘗試對 Asset Catalog 中的 png 圖片做無損壓縮，但實(shí)踐后發(fā)現(xiàn)，雖然放入 Asset Catalog 的圖片大小有了明顯減小，但是構(gòu)建的產(chǎn)物的大小卻幾乎沒有變化。

經(jīng)過探究，我們發(fā)現(xiàn)，Xcode 中，構(gòu)建 Asset Catalog 的工具 actool 會首先對 Asset Catalog 中的 png 圖片進(jìn)行解碼，得到 Bitmap 數(shù)據(jù)，然后再運(yùn)用 actool 的編碼壓縮算法進(jìn)行編碼壓縮處理。無損壓縮通過變換圖片的編碼壓縮算法減少大小，但是不會改變 Bitmap 數(shù)據(jù)。對于 actool 來說，它接收的輸入沒有改變，所以無損壓縮無法優(yōu)化 Assets.car 的大小。

那是否有其他的壓縮方式能優(yōu)化 Assets.car 的大小呢？我們猜測對圖片做合適的有損壓縮是一個思路。

于是我們嘗試了 RGB with palette 編碼方式[2]。RGB with palette 編碼的得到的字節(jié)流首先維護(hù)了一個顏色數(shù)組。顏色數(shù)組每個成員用 RGBA 四個分量維護(hù)一個顏色。圖像中的每個像素點(diǎn)則存儲顏色數(shù)組的下標(biāo)代表該點(diǎn)的顏色。顏色數(shù)組維護(hù)的顏色種類和數(shù)量由圖片決定，同時可以人為的限制顏色數(shù)組維護(hù)顏色的種類的上限，默認(rèn)為最大值 256 種。這種編碼方式正如它的名字：palette（調(diào)色板）。

App 中大部分圖片雖然使用了很多種類的顏色，但這些顏色中大多數(shù)都非常接近，從視覺上很難分辨，比如大量扁平風(fēng)格的 icon。這種類型的圖片非常適合用 palette 編碼且減少顏色數(shù)組大小的方式來進(jìn)行有損壓縮，既能減少顏色數(shù)量實(shí)現(xiàn)有損壓縮，也能保證保留的顏色貼近原始圖片，使得經(jīng)過有損壓縮后的也看起來質(zhì)量無損。我們在今日頭條上落地，獲得了 3.15MB 包大小收益。

在具體執(zhí)行中，我們使用了 ImageOptim 工具改變圖片的編碼方式為 RGB with palette ：

imageoptim -Q --no-imageoptim --imagealpha --number-of-colors 16 --quality 40-80 ./1.png

其中 --number-of-colors  控制顏色數(shù)組維護(hù)顏色的數(shù)量；--quality  控制圖片的質(zhì)量變?yōu)樵瓉淼陌俜直取Ｎ覀兊慕?jīng)驗(yàn)表明，當(dāng) --number-of-colors  從 16 開始向上調(diào)整，--quality 維持 40-80，能夠在顯著減少包大小的同時維持肉眼看不到的質(zhì)量變化。經(jīng)過 UI 同學(xué)的像素眼審查，確認(rèn)優(yōu)化前后的圖片看起來無差別。

 2.3、Assets.car 合并

今日頭條使用 CocoaPods 進(jìn)行組件集成，各個組件攜帶的 Asset Catalog 文件以 Podspec 中 resource_bundles 的方式引入，最終會以 Bundle 下的 Assets.car 文件的形式體現(xiàn)在安裝包內(nèi)。

以 7.9.4 版本為例，安裝包內(nèi)有 106 個 Bundle 包含 Assets.car 文件：

Assets.car 文件本質(zhì)上是 BOM 文件，同時，Xcode 在使用 actool 構(gòu)建 Assets.car 文件時，也會自帶一些優(yōu)化操作，比如：將若干張小圖片自動合并為一張 Packed Image。因此，將若干個 Assets.car 合并，可以減少重復(fù)的 BOM Block，也可以最大化享受到 actool 自帶的優(yōu)化效果。

在構(gòu)建的過程中，今日頭條通過在 Build Phases 中加入腳本，將多個庫中 Asset Catalog 中的圖片合并到一個 Asset Catalog 中，再經(jīng) actool 構(gòu)建成 Assets.car 產(chǎn)物。這一優(yōu)化產(chǎn)生了 2.1MB 的包大小收益。同時，從理論上分析，這一優(yōu)化也可以減少運(yùn)行時 Assets.car 的解析操作，對圖片讀取的響應(yīng)耗時有正向收益。

2.4、文本文件壓縮

除了占比最大的圖片資源，今日頭條安裝包內(nèi)還有不少文本文件資源，如 JSON 文件、HTML 文件等。這些文本文件的壓縮也能帶來包大小優(yōu)化效果。

今日頭條落地的文本文件壓縮方案由三部分組成：

1、壓縮階段：在 Build Phase 中添加腳本，構(gòu)建期間對白名單內(nèi)的文本文件做 zip 壓縮；

2、解壓階段：在 App 啟動階段，在異步線程中進(jìn)行解壓操作，將解壓產(chǎn)物存放到沙盒中；

3、讀取階段：在 App 運(yùn)行時，hook 讀取這些文件的方法，將讀取路徑從 Bundle 改為沙盒中的對應(yīng)路徑；

這一方案能在業(yè)務(wù)入侵較少的前提下完成壓縮優(yōu)化。我們首先將這一方案應(yīng)用在了 Lottie 動畫的 JSON 文件上，產(chǎn)生了 400KB 的包大小收益。后續(xù)這一方案也可以進(jìn)一步拓展，應(yīng)用在更多類型的文件上。

三、Mach-O 文件優(yōu)化

在資源優(yōu)化的同時，我們也關(guān)注到，Mach-O 文件始終占據(jù)了今日頭條安裝包 80% 左右的體積。Mach-O 文件的優(yōu)化必不可少。下面我們以時間順序，介紹我們落地的 Mach-O 文件優(yōu)化項(xiàng)。

3.1、使用 -Oz 編譯參數(shù)

Oz 是 Xcode 11 新增的編譯優(yōu)化選項(xiàng)。WWDC 2019 《What’s New in Clang and LLVM》[3] 中對 Oz 有過介紹。Oz 的核心原理是對重復(fù)的連續(xù)機(jī)器指令外聯(lián)成函數(shù)進(jìn)行復(fù)用，和“內(nèi)聯(lián)函數(shù)”的原理正好相反。因此，開啟 Oz，能減小二進(jìn)制的大小，但同時理論上會帶來執(zhí)行效率的額外消耗。對性能（CPU）敏感的代碼使用需要評估。

蘋果給的參考數(shù)據(jù)是 4.5% 的包體積收益。

我們在評估了執(zhí)行效率、堆棧解析、穩(wěn)定性和編譯速度后，對大部分源代碼開啟了 Oz 編譯，包體積減小 4MB 以上。

3.2、使用鏈接時優(yōu)化 LTO 

Link-Time Optimization 鏈接時優(yōu)化，是 Xcode 自帶的一個編譯/鏈接參數(shù)。根據(jù) WWDC 2016 《What’s New in LLVM》[4]的介紹，LTO 對包大小和運(yùn)行效率都有正向影響。今日頭條在編譯和鏈接中均開啟 Incremental LTO 后，包體積減小 6.5MB。

3.3、修正 Exported Symbols 配置

Xcode Build Settings 中的 EXPORTED_SYMBOLS_FILE 配置，控制著 Mach-O 中 __LINKEDIT 段中 Export Info 的信息。動態(tài)鏈接器 dyld 在做符號綁定時，會讀取被綁定的動態(tài)庫或可執(zhí)行文件的 Export Info 信息，得到一個符號對應(yīng)的實(shí)際調(diào)用地址。如果正在被綁定的符號，在目標(biāo)動態(tài)庫的 Export Info 中缺失，dyld 則會拋出異常，表現(xiàn)為 App 崩潰。

雖然從原理上看，Export Info 中的信息不可或缺。但是，對于一個 Mach-O 文件來說，并非所有的符號都是需要暴露給其他動態(tài)庫或可執(zhí)行文件的。理想情況下，私有的符號應(yīng)該在編碼時就應(yīng)該以 __attribute__((visibility(hidden))) 修飾。但在歷史代碼難以逐個添加修飾符的情況下，Exported Symbols 配置給了工程一個維護(hù)公有符號白名單的機(jī)會。如果填寫了有效的 EXPORTED_SYMBOLS_FILE 配置，動態(tài)庫或者可執(zhí)行文件會在靜態(tài)鏈接時去掉白名單以外的符號，起到縮減包大小、增加逆向難度的作用。

今日頭條在使用 Exported Symbols 配置后，包大小減少了 2.1MB。

3.4、屬性動態(tài)化

屬性是 OC 中最常見的概念之一。然而，一個屬性并沒有我們想象的這么小。通過分析 Mach-O 文件，我們發(fā)現(xiàn)，一個屬性可以分為三個部分：

（1）成員變量部分：成員變量本質(zhì)是一個大小 32B 的結(jié)構(gòu)體，結(jié)構(gòu)體中三個指針（Offset、Name、Type）指向的內(nèi)容的大小分別為 8B、10B、10B，其中 Name、Type 指針指向的內(nèi)容的大小和成員變量的類型、名字長度相關(guān)。總大小大約 60B。

@interface presentViewController ()@property (nonatomic,strong) UIImageView *imageView;@property (nonatomic,strong) UIButton *button;@property (nonatomic,strong) NSString *name;@end

（2）自動生成的 set/get 方法部分：set/get 方法本質(zhì)是一個大小 24B 的結(jié)構(gòu)體，結(jié)構(gòu)體包含三個指針 Name、Type、Implementation，指向的內(nèi)容大小大概為 10B、10B、20B。一個方法大小大概是64B，set、get 兩個方法就是 128B。

（3）property 部分：property 的本質(zhì)仍然是個結(jié)構(gòu)體，大小是 16B，結(jié)構(gòu)體中兩個指針指向內(nèi)容的大小分別大概是 10B、10B，和屬性的名字和類型相關(guān)。總大小大概 36B。

即一個屬性占用的包大小大約為 224B。

如果我們用 @dynamic 修飾一個屬性，不生成成員變量、get/set 方法，則一個屬性可以由 224B 減少到 36B，即僅包含 property 部分的大小。

同時，代碼中存在大量通過腳本自動生成的 JSONModel 子類，這些子類往往擁有大量屬性。這里也就存在著包大小優(yōu)化空間。

于是我們通過修改生成 JSONModel 子類的腳本，實(shí)現(xiàn)了：

1、屬性全部使用 @dynamic 修飾，基礎(chǔ)變量額外生成 IVAR

2、所有 JSONModel 的子類繼承自新的父類，新的父類實(shí)現(xiàn) resolveInstanceMethod，在該方法中用 class_addMethod 統(tǒng)一為屬性添加 get/set 方法。對象類型的屬性使用關(guān)聯(lián)對象的方式存取，基礎(chǔ)類型的屬性使用額外生成的 IVAR 存取。

這一優(yōu)化獲得了 800KB 的包大小收益，并且評估對讀寫的性能影響損耗可以接受。

3.5、__TEXT 段遷移

安裝包經(jīng)過壓縮后的 Download Size 若超過 200 MB，在蜂窩網(wǎng)絡(luò)下載 App 就會受到限制，這對新增會有較大影響。在 2020 年下半年，我們探索實(shí)踐了 __TEXT 段遷移技術(shù)：在鏈接階段使用 -rename_p 選項(xiàng)將 __TEXT,__text 遷移到 __BD_TEXT,__text，減少蘋果對可執(zhí)行文件的加密范圍，提升可執(zhí)行文件的壓縮效率，從而減少 Download Size。

使用該方案我們最終減少了 60 MB 的 Download Size 以及 2 MB 的 Install Size。詳細(xì)的原理可以參考：《今日頭條優(yōu)化實(shí)踐：iOS 包大小二進(jìn)制優(yōu)化，一行代碼減少 60 MB 下載大小》[5]。

3.6、二進(jìn)制段壓縮

Mach-O 文件占據(jù)了 Install Size 中很大一部分比例，但并不是文件中的每個段/節(jié)在程序啟動的第一時間都要被用到。可以在構(gòu)建過程中將 Mach-O 文件中的這部分段/節(jié)壓縮，然后只要在這些段被使用到之前將其解壓到內(nèi)存中，就能達(dá)到了減少包大小的效果，同時也能保證程序正常運(yùn)行。由于蘋果的一些限制，我們目前只壓縮了 __TEXT,__gcc_except_tab 與 __TEXT,__objc_methtype兩個節(jié)，然后在 _dyld_register_func_for_add_image 的回調(diào)中對它進(jìn)行解壓。該方案累計(jì)優(yōu)化了 3.5 MB Install Size。

四、總結(jié)

在以上優(yōu)化項(xiàng)落地的同時，我們還與業(yè)務(wù)協(xié)作，通過挖掘無用代碼、無用資源等手段，進(jìn)一步優(yōu)化著安裝包大小。使得今日頭條在高速的業(yè)務(wù)迭代下，包大小仍能保持穩(wěn)定。

以上就是怎樣優(yōu)化今日頭條IOS安裝包的詳細(xì)內(nèi)容，更多關(guān)于今日頭條IOS安裝包大小優(yōu)化的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！