前言

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

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

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

一、安裝包的構成

當我們通過構建，獲得了一個經過了 App Slicing 后的 ipa 文件后，將其用 zip 解壓縮方式解壓，進入 .app 文件后，我們就可以直觀地看到安裝包中的內容。

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

1.1、Assets.car 文件

Assets.car 文件是工程中 Asset Catalog 的構建產物。Xcode 工具鏈中的 actool 負責構建 Assets.car。在構建 Assets.car 的過程中，actool 會按照一定策略選取編碼算法，對其中的 png 圖片重新編碼。

圖：Asset Catalog

1.2、Mach-O 文件

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

同時，Link Map 文件能更進一步幫助我們分析 Mach-O 文件的構成。

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

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

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

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

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

我們通過實驗發(fā)現：

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

2、開啟 Pod 庫和主工程 Xcode Build Settings 中的 ASSETCATALOG_COMPILER_OPTIMIZATION space 選項

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

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

2.2、使用 RGB with palette 壓縮圖片

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

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

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

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

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

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

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

其中 --number-of-colors  控制顏色數組維護顏色的數量；--quality  控制圖片的質量變?yōu)樵瓉淼陌俜直?。我們的經驗表明，?--number-of-colors  從 16 開始向上調整，--quality 維持 40-80，能夠在顯著減少包大小的同時維持肉眼看不到的質量變化。經過 UI 同學的像素眼審查，確認優(yōu)化前后的圖片看起來無差別。

 2.3、Assets.car 合并

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

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

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

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

2.4、文本文件壓縮

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

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

1、壓縮階段：在 Build Phase 中添加腳本，構建期間對白名單內的文本文件做 zip 壓縮；

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

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

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

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

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

3.1、使用 -Oz 編譯參數

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

蘋果給的參考數據是 4.5% 的包體積收益。

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

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

Link-Time Optimization 鏈接時優(yōu)化，是 Xcode 自帶的一個編譯/鏈接參數。根據 WWDC 2016 《What's New in LLVM》[4]的介紹，LTO 對包大小和運行效率都有正向影響。今日頭條在編譯和鏈接中均開啟 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 信息，得到一個符號對應的實際調用地址。如果正在被綁定的符號，在目標動態(tài)庫的 Export Info 中缺失，dyld 則會拋出異常，表現為 App 崩潰。

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

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

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

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

（1）成員變量部分：成員變量本質是一個大小 32B 的結構體，結構體中三個指針（Offset、Name、Type）指向的內容的大小分別為 8B、10B、10B，其中 Name、Type 指針指向的內容的大小和成員變量的類型、名字長度相關。總大小大約 60B。

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

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

（3）property 部分：property 的本質仍然是個結構體，大小是 16B，結構體中兩個指針指向內容的大小分別大概是 10B、10B，和屬性的名字和類型相關?？偞笮〈蟾?36B。

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

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

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

于是我們通過修改生成 JSONModel 子類的腳本，實現了：

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

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

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

3.5、__TEXT 段遷移

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

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

3.6、二進制段壓縮

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

四、總結

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

以上就是怎樣優(yōu)化今日頭條IOS安裝包的詳細內容，更多關于今日頭條IOS安裝包大小優(yōu)化的資料請關注腳本之家其它相關文章！