前言

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

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

一、安裝包的構成

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

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

1.1、Assets.car 檔案

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

1.2、Mach-O 檔案

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

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

在 Build Settings 中打開 LD_GENERATE_MAP_FILE 開關，構建 App 的程序中就會生成一個名叫 Link Map 的 txt 檔案，它能展示每個段、每個節、每個函式在 Mach-O 中的分布和大小，這些資訊是包大小優化中經常使用的，

二、資源大小優化

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

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

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

我們通過實驗發現：

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 中每張圖片使用的編碼壓縮演算法，在今日頭潭訓境下，整理的結果如下：

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

2.2、使用 RGB with palette 壓縮圖片

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

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

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

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

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

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

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

其中 --number-of-colors 控制顏色陣列維護顏色的數量；--quality 控制圖片的質量變為原來的百分比，我們的經驗表明，當 --number-of-colors 從 16 開始向上調整，--quality 維持 40-80，能夠在顯著減少包大小的同時維持肉眼看不到的質量變化，經過 UI 同學的像素眼審查，確認優化前后的圖片看起來無差別，

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 檔案時，也會自帶一些優化操作，比如：將若干張小圖片自動合并為一張 Packed Image，因此，將若干個 Assets.car 合并，可以減少重復的 BOM Block，也可以最大化享受到 actool 自帶的優化效果，

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

2.4、文本檔案壓縮

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

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

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

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

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

這一方案能在業務入侵較少的前提下完成壓縮優化，我們首先將這一方案應用在了 Lottie 影片的 JSON 檔案上，產生了 400KB 的包大小收益，后續這一方案也可以進一步拓展，應用在更多型別的檔案上，

三、Mach-O 檔案優化

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

3.1、使用 -Oz 編譯引數

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

蘋果給的參考資料是 4.5% 的包體積收益，

我們在評估了執行效率、堆疊決議、穩定性和編譯速度后，對大部分源代碼開啟了 Oz 編譯，包體積減小 4MB 以上，

3.2、使用鏈接時優化 LTO

Link-Time Optimization 鏈接時優化，是 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 的資訊，動態聯結器 dyld 在做符號系結時，會讀取被系結的動態庫或可執行檔案的 Export Info 資訊，得到一個符號對應的實際呼叫地址，如果正在被系結的符號，在目標動態庫的 Export Info 中缺失，dyld 則會拋出例外，表現為 App 崩潰，

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

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

3.4、屬性動態化

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

（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 子類，這些子類往往擁有大量屬性，這里也就存在著包大小優化空間，

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

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

2、所有 JSONModel 的子類繼承自新的父類，新的父類實作 resolveInstanceMethod，在該方法中用 class_addMethod 統一為屬性添加 get/set 方法，物件型別的屬性使用關聯物件的方式存取，基礎型別的屬性使用額外生成的 IVAR 存取，

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

3.5、__TEXT 段遷移

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

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

3.6、二進制段壓縮

Mach-O 檔案占據了 Install Size 中很大一部分比例，但并不是檔案中的每個段/節在程式啟動的第一時間都要被用到，可以在構建程序中將 Mach-O 檔案中的這部分段/節壓縮，然后只要在這些段被使用到之前將其解壓到記憶體中，就能達到了減少包大小的效果，同時也能保證程式正常運行，由于蘋果的一些限制，我們目前只壓縮了 __TEXT,__gcc_except_tab 與 __TEXT,__objc_methtype兩個節，然后在 _dyld_register_func_for_add_image 的回呼中對它進行解壓，該方案累計優化了 3.5 MB Install Size，

四、總結

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

五、加入我們

在實踐包大小優化的程序中，我們發現，做優化，既需要靜下心來做技術攻堅，也需要與各方協作配合，我們作為今日頭條平臺架構 iOS 團隊，在性能優化、基礎組件、業務架構、研發體系、安全合規、線下質量基礎設施、線上問題定位歸因平臺等方向持續深耕，負責保障和提升今日頭條的產品質量和開發效率，聚焦于今日頭條的同時向外延伸，

如果你對技術充滿熱情，喜歡追求極致，渴望用自己的代碼改變數億用戶的體驗，歡迎加入我們，我們期待你與我們共同成長，目前我們在北京、深圳均有招聘需求，簡歷投遞郵箱：tech@bytedance.com；郵件標題：姓名 - 作業年限 - 今日頭條 - 平臺架構 - iOS/Android ，

參考資料

[1] 干貨｜今日頭條iOS端安裝包大小優化—思路與實踐

[2] Palette Images

http://www.manifold.net/doc/mfd9/palette_images.htm

[3] WWDC 2019 What's New in Clang and LLVM

https://developer.apple.com/videos/play/wwdc2019/409/

[4] WWDC 2016 What's New in LLVM

https://developer.apple.com/videos/play/wwdc2016/405/

[5] 今日頭條優化實踐：iOS 包大小二進制優化，一行代碼減少 60 MB 下載大小

歡迎關注「 位元組跳動技術團隊 」

簡歷投遞聯系郵箱「 tech@bytedance.com 」

點擊閱讀原文，快來加入我們吧！