前言

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

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

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

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

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

一個(gè)安裝包，往往包含資源與 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 的過(guò)程中，actool 會(huì)按照一定策略選取編碼算法，對(duì)其中的 png 圖片重新編碼。

圖：Asset Catalog

1.2、Mach-O 文件

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

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

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

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

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

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

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

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

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

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

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

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

2.2、使用 RGB with palette 壓縮圖片

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

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

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

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

App 中大部分圖片雖然使用了很多種類(lèi)的顏色，但這些顏色中大多數(shù)都非常接近，從視覺(jué)上很難分辨，比如大量扁平風(fēng)格的 icon。這種類(lèi)型的圖片非常適合用 palette 編碼且減少顏色數(shù)組大小的方式來(lái)進(jìn)行有損壓縮，既能減少顏色數(shù)量實(shí)現(xiàn)有損壓縮，也能保證保留的顏色貼近原始圖片，使得經(jīng)過(guò)有損壓縮后的也看起來(lái)質(zhì)量無(wú)損。我們?cè)诮袢疹^條上落地，獲得了 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)樵瓉?lái)的百分比。我們的經(jīng)驗(yàn)表明，當(dāng) --number-of-colors  從 16 開(kāi)始向上調(diào)整，--quality 維持 40-80，能夠在顯著減少包大小的同時(shí)維持肉眼看不到的質(zhì)量變化。經(jīng)過(guò) UI 同學(xué)的像素眼審查，確認(rèn)優(yōu)化前后的圖片看起來(lái)無(wú)差別。

 2.3、Assets.car 合并

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

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

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

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

2.4、文本文件壓縮

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

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

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

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

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

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

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

在資源優(yōu)化的同時(shí)，我們也關(guān)注到，Mach-O 文件始終占據(jù)了今日頭條安裝包 80% 左右的體積。Mach-O 文件的優(yōu)化必不可少。下面我們以時(shí)間順序，介紹我們落地的 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] 中對(duì) Oz 有過(guò)介紹。Oz 的核心原理是對(duì)重復(fù)的連續(xù)機(jī)器指令外聯(lián)成函數(shù)進(jìn)行復(fù)用，和“內(nèi)聯(lián)函數(shù)”的原理正好相反。因此，開(kāi)啟 Oz，能減小二進(jìn)制的大小，但同時(shí)理論上會(huì)帶來(lái)執(zhí)行效率的額外消耗。對(duì)性能（CPU）敏感的代碼使用需要評(píng)估。

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

我們?cè)谠u(píng)估了執(zhí)行效率、堆棧解析、穩(wěn)定性和編譯速度后，對(duì)大部分源代碼開(kāi)啟了 Oz 編譯，包體積減小 4MB 以上。

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

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

3.3、修正 Exported Symbols 配置

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5、__TEXT 段遷移

安裝包經(jīng)過(guò)壓縮后的 Download Size 若超過(guò) 200 MB，在蜂窩網(wǎng)絡(luò)下載 App 就會(huì)受到限制，這對(duì)新增會(huì)有較大影響。在 2020 年下半年，我們探索實(shí)踐了 __TEXT 段遷移技術(shù)：在鏈接階段使用 -rename_p 選項(xiàng)將 __TEXT,__text 遷移到 __BD_TEXT,__text，減少蘋(píng)果對(duì)可執(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 中很大一部分比例，但并不是文件中的每個(gè)段/節(jié)在程序啟動(dòng)的第一時(shí)間都要被用到?？梢栽跇?gòu)建過(guò)程中將 Mach-O 文件中的這部分段/節(jié)壓縮，然后只要在這些段被使用到之前將其解壓到內(nèi)存中，就能達(dá)到了減少包大小的效果，同時(shí)也能保證程序正常運(yùn)行。由于蘋(píng)果的一些限制，我們目前只壓縮了 __TEXT,__gcc_except_tab 與 __TEXT,__objc_methtype兩個(gè)節(jié)，然后在 _dyld_register_func_for_add_image 的回調(diào)中對(duì)它進(jìn)行解壓。該方案累計(jì)優(yōu)化了 3.5 MB Install Size。

四、總結(jié)

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

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

最新評(píng)論