一、前言

百度APP作為日活過億的國民級應(yīng)用，經(jīng)過這些年的發(fā)展，從最初的搜索，發(fā)展到現(xiàn)在包含搜索、Feed、視頻、直播、小說、購物、小程序、網(wǎng)盤和眾多垂類模塊的超級應(yīng)用，為服務(wù)更多用戶滿足更多用戶需求不斷迭代，應(yīng)用像滾雪球一樣越滾越大，包體積從最初的幾十MB發(fā)展到最高時的420MB，每個版本自然迭代會有至少3MB的漲幅，過大的包體積帶來的負(fù)面作用開始顯現(xiàn)，400M的體積對下載轉(zhuǎn)化率和卸載率提出了很大的挑戰(zhàn)，因此包體積成為百度超級APP發(fā)展的攔路虎。

22年Q3開啟包體積優(yōu)化項目，從編譯器優(yōu)化(OC&Swift&C++優(yōu)化、LTO優(yōu)化、剝離調(diào)試符號、三方SDK優(yōu)化)、圖片優(yōu)化(無用圖片、HEIC圖片優(yōu)化、Asset Catalog圖片優(yōu)化、圖片壓縮)、資源瘦身(大資源優(yōu)化、無用配置文件、重復(fù)資源)、代碼瘦身(無用類、無用方法、無用模塊、精簡重復(fù)代碼、工具類瘦身、AB實驗固化)和工程架構(gòu)(Xcode打包、防劣化)等方向做優(yōu)化。

在滿足正常業(yè)務(wù)迭代情況下，優(yōu)化落地收益50M，百度APP包體積從七月初的395M下降到十二月末的352M，同一時間段內(nèi)，國內(nèi)大廠主流APP中，微信從502M上漲到530M，抖音從390M上漲到432M，快手從310M上漲到357M。在很少的人力投入下取的這個成果，效率非常顯著，此外，我們沉淀了各個優(yōu)化方向的基建工具，完善了防劣化機(jī)制，為包體積持續(xù)優(yōu)化和防止無序增長打下來堅實的基礎(chǔ)。

二、背景

2.1 包大小優(yōu)化的必要性

2.1.1 包體積每增加6M，應(yīng)用下載轉(zhuǎn)化率下降1%

根據(jù)Google Play的統(tǒng)計：包體積每增加 6M，應(yīng)用下載轉(zhuǎn)化率下降 1%，APK包體大小每減少10MB ，全球平均下載轉(zhuǎn)化率會提升1.75%，不同市場的數(shù)據(jù)各有不同，具體請參考如下圖表。雖然AppStore沒有給出類似數(shù)據(jù)，但是根據(jù)同樣道理，安裝包大小的減少必然會提升應(yīng)用下載轉(zhuǎn)化率。

2.1.2 App Store OTA下載大小限制，不利于APP的推廣

下載包大小超出 200 MB 時 ，會出現(xiàn)兩種情況：

• iOS 13 以下的用戶，無法通過蜂窩數(shù)據(jù)下載 APP；
• iOS 13 及以上的用戶，需要手動設(shè)置才可以使用蜂窩網(wǎng)絡(luò)下載 APP。

2.1.3 磁盤不足時刪除首選

下載包體積太大，會占用更多的設(shè)備存儲空間，對于低存儲的設(shè)備的用戶也會有一定的影響，可能成為磁盤不夠時的首選。

2.1.4 減少用戶的下載意愿

如果蜂窩數(shù)據(jù)選型默認(rèn)是低數(shù)據(jù)模式，那么下載包大小就更會影響用戶決策，可能會減少用戶的下載意愿。

2.1.5 其他負(fù)面影響

包體積太大，更多的的代碼邏輯，加載的類太多，增加premain時間，帶來比較慢的啟動速度，同時增加啟動階段SIGKILL發(fā)生的概率，讓性能等基礎(chǔ)體驗變差。此外，過于復(fù)雜冗余的代碼還會增加代碼修改的風(fēng)險，所以包大小不是一個孤立的指標(biāo)，它從側(cè)面的反映出 APP 的健康狀態(tài)。

2.2 安裝包生成過程

在ipa包上傳AppStore后，App Thinning會針對不同設(shè)備型號的硬件架構(gòu)產(chǎn)生不同的編譯產(chǎn)物，用戶不同設(shè)備從AppStore會有不同的下載包，解壓縮安裝后是最后的安裝包。

2.3 包體積指標(biāo)

2.3.1 下載包大小和安裝包大小

• 下載包大小是指APP壓縮包(也就是 .ipa 文件)所占的空間，用戶在下載APP時，下載的是壓縮包，這樣做可以節(jié)省流量；
• 當(dāng)壓縮包下載完成后，就會自動解壓，解壓過程也就是通常所說的安裝過程，安裝大小就是指壓縮包解壓后所占用的磁盤空間；
• 在Appstore產(chǎn)品信息頁->信息->大小，看到數(shù)據(jù)是安裝包大小，不是下載包大小，不同的系統(tǒng)安裝包大小是不一樣的；

• 那么蘋果后臺的下載大小和安裝大小如何查看？
  開發(fā)者在iTues-Connect后臺可以看到不同平臺的安裝包大小和下載包大小，查看路徑是App Store Connect->TestFlight->Build活動->選擇版本->文件大小。

2.3.2 安裝包體積作為衡量標(biāo)準(zhǔn)

對于iOS端來說通常將安裝包體積作為衡量標(biāo)準(zhǔn)，這是基于以下兩個原因，第一、安裝包和下載包大小正相關(guān)，安裝包體積減小后，下載包體積自然也會減小；第二、AppStore官方頁面給出的是每個APP的安裝包大小，APP使用者可非常直觀地獲取這個信息，**但是要想獲取下載包大小，必須具有開發(fā)者權(quán)限，**這顯然不可能。

三、IOS端安裝包組成部分

組成部分	說明
Mach-O文件	iOS系統(tǒng)上的可執(zhí)行文件
Watch	APP中帶有WatchApp
Widget組件	Widget通過在 iOS 主屏幕放置小組件，讓用戶可以隨時訪問 APP中的內(nèi)容，Widget 可以保持更新，從而讓用戶獲得最新信息，當(dāng)需要更多細(xì)節(jié)時，點擊Widget 會直接帶到 APP中的適當(dāng)位置
APP自定義動態(tài)庫	APP中自定義的動態(tài)庫， 動態(tài)庫在應(yīng)用編譯打包的時候，僅把鏈接信息編譯到應(yīng)用二進(jìn)制可執(zhí)行文件中，將 framework 的加載推遲到運行時，因此，應(yīng)用在提交評審時的代碼段大小計算，是不會將動態(tài)庫的代碼段計算計算在內(nèi)，從而能夠節(jié)省出一大截代碼段大小空間
swift系統(tǒng)庫	swift系統(tǒng)庫，低版本系統(tǒng)上無swift系統(tǒng)庫，需iPA包中自帶，12.2以上系統(tǒng)自帶swift系統(tǒng)庫
Assets資源	Assets.car文件，使用Assets.xcassets管理的圖片資源會統(tǒng)一打包進(jìn)入該文件
根目錄下的圖片資源	直接添加進(jìn)工程的圖片文件，如png、jpeg、svg、webp、AppIcon等圖片資源
bundle資源	用bundle管理資源,里面可以是圖片,也可以是其他的配置文件
其他配置文件	除Assets、bundle資源和根目錄下的圖片資源為外，其他配置文件，如plist、js、css、json、端智能模型文件等

四、國內(nèi)外廠商APP體積分析

我們針對國內(nèi)外主流APP的安裝包做一個簡單分析，重點統(tǒng)計了IPA包主要組成部分，如Mach-O文件、bundle圖片資源和Assets圖片資源，原始文件來源是22年9月份AppStore商店安裝包，經(jīng)過分析有如下結(jié)論：

• 從APP包體積來看，QQ和微信包體積最大(500M+)，處于第一梯隊，百度和抖音居于第二梯隊(380M+)，快手(320M)處于第三梯隊，美團(tuán)、淘寶和頭條包體積是在250M左右 ，是國內(nèi)大廠中體積最小的，國外的主流APP如Facebook和YouTube在280M左右，包體積控制的還是比較節(jié)制的。
• 國外的APP大量使用動態(tài)庫，F(xiàn)acebook自定義動態(tài)庫有53個，主mach-o體積只有8.3M，代碼主要在動態(tài)庫，國內(nèi)自定義動態(tài)庫基本6個左右，像美團(tuán)和百度基本沒有自定義動態(tài)庫；
• Swift的使用是大勢所趨，國外大廠在用，國內(nèi)大廠除了美團(tuán)沒有Swift動態(tài)庫(暫沒發(fā)現(xiàn))，其他廠都有，這與Apple的努力密不可分，2019年Apple發(fā)布了 Swift 5.0 版本，宣布了 ABI 穩(wěn)定后，像手淘也擁抱了Swift;
• bundle和Asset使用對比，Asset是所有大廠APP主流，美團(tuán)APP用bundle較廣泛，bundle圖片webP優(yōu)化較多；
• 從圖片的角度來比較，不論是bundle圖片資源還是Assets圖片資源，百度APP是其他APP的好幾倍，冗余資源很多，這是我們的優(yōu)化方向；
• SVG、iconfont的使用，國內(nèi)大廠像QQ和淘寶，大量使用SVG矢量圖和iconfont字體文件構(gòu)建純色圖以此來降低圖片體積，這也是百度APP需要推動優(yōu)化的方向。

五、技術(shù)方案

5.1 資源優(yōu)化

百度APP有30M的資源，這兒資源是指plist、js、css、json、端智能模型文件等，因這些文件的優(yōu)化方式跟圖片優(yōu)化差異很大，所以把兩者區(qū)分開來。內(nèi)置的大塊資源(單個文件大于80K)就有16M，所以具有很大的優(yōu)化空間，資源優(yōu)化分為三個部分，分別是大資源優(yōu)化、無用配置文件和重復(fù)資源優(yōu)化。

5.2 工程架構(gòu)優(yōu)化

其他優(yōu)化手段解決的是存量問題，良好的防劣化機(jī)制解決的是增量問題，以避免包體積無序增長，百度APP結(jié)合Linkmap和Mach-O文件搭建了體積檢測流水線，對每個版本每個庫的包體積劣化問題做了挖掘，結(jié)合配額和卡口制度，控制體積增長在合理范圍內(nèi)。

此外，蘋果公司為進(jìn)一步提高開發(fā)者的生產(chǎn)效率，于22年10月份發(fā)布了Xcode14，新版本編譯器具有全新的增強(qiáng)功能，更強(qiáng)大的并行編譯能力，可明顯提升項目構(gòu)建速度，其中，XCode14的升級對包體積帶來比較明顯的優(yōu)化，官方給出數(shù)據(jù)是應(yīng)用程序下載包體積減小了 30%，百度APP實踐過程中有26M的收益，體積減少了6.5%。

5.3 圖片優(yōu)化

解壓IPA包后發(fā)現(xiàn)，asset和bundle里面圖片有94M,這是我們重點優(yōu)化的對象，百度APP采用如下方式對不同的圖片資源進(jìn)行了優(yōu)化。

• 無用圖片優(yōu)化：基于開源工具二次開發(fā)，工具針對OC、swift、xib、html、js、css、json、plist文件掃描排查未引用的圖片，然后針對如下字符串拼接的常見case二次過濾：暗黑模式(后綴\dark,\day,\night)、后綴是數(shù)字的圖片序列(覆蓋如下后綴\%d,\%ld,\%zd,\_%lu)；
• Asset Catalog圖片優(yōu)化：之前在bundle需要放二倍圖和三倍圖，同一張圖片最后在用戶手機(jī)上會有兩份，iOS7系統(tǒng)有了Asset Catalog后，Asset Catalog為不同類型設(shè)備(分辨率不同)或者相同類型設(shè)備但不同配置(磁盤不同)提供定制化資源下載，當(dāng)用戶下載App時，只有跟用戶手機(jī)硬件設(shè)備參數(shù)相匹配的資源才會被下載，其他不會下載，從而降低下載包體積；
• HEIC圖片優(yōu)化：更改PNG和JPEG圖片編碼格式，選擇HEIC方案，基于以下優(yōu)點：1、體積最小，HEIC比PNG體積減少50%，WebP比PNG優(yōu)化30%；2、解碼效率高，跟WebP相比，HEIC硬解碼效率高，略慢于JPEG；
• WebP壓縮優(yōu)化：根據(jù)前面的結(jié)論有HEIC格式圖片后，圖片優(yōu)化工作就已經(jīng)結(jié)束了，其實不然，HEIC是iOS12以后推出來一種新格式，百度APP經(jīng)過這么多年開發(fā)積累了許多老圖片，對于帶有Alpha通道的并經(jīng)過壓縮的PNG圖片，轉(zhuǎn)換為HEIC格式后，在iOS12和13系統(tǒng)存在兼容性問題，Alpha通道全變?yōu)?，為此對于這種case，尤其是大圖，我們采用WebP壓縮優(yōu)化；
• TinyPng壓縮：WebP 在 CPU 消耗和解碼時間上會比 PNG 高兩倍，因為對于大于100KB的圖片我們使用 WebP，對于小于 100KB 圖片，使用TinyPng進(jìn)行壓縮，雖然壓縮率沒有 WebP 那么高，但是沒有改變圖片編碼方式，所以不會增加解析性能損耗。

5.4 編譯器優(yōu)化

編譯器是包體積優(yōu)化方向中性價比最高的，LLVM給我們提供了大量的編譯選項，對于OC、C、C++、Swift、資源壓縮和符號表都有大量優(yōu)化選擇，百度APP采用的方案如下所示：

5.5 代碼優(yōu)化

代碼優(yōu)化相對而言ROI較低，因為影響范圍較廣，質(zhì)量風(fēng)險較高，優(yōu)化過程中涉及到所有相關(guān)人員參與，無法集中處理。百度APP從無用類優(yōu)化、無用方法瘦身、無用模塊瘦身、精簡重復(fù)代碼、工具類瘦身、AB實驗固化等方向做了深度優(yōu)化。

六、各項優(yōu)化收益

各項主題優(yōu)化收益如下所示，對于有的優(yōu)化已經(jīng)收益落地了，其他的還需要排期，按收益從大到小排序，工程方向優(yōu)化-》編譯器方向-》圖片優(yōu)化-》資源文件優(yōu)化-》代碼瘦身。

七、總結(jié)

本文主要介紹了iOS包體積優(yōu)化必要性、下載包和安裝包兩個指標(biāo)的區(qū)別、安裝包組成部分和生成過程、國內(nèi)外大廠APP包體積分析，然后闡釋了百度APP包體積優(yōu)化的總體技術(shù)方案，最后介紹了百度APP具體實踐的優(yōu)化項及收益，后續(xù)我們會針對每個優(yōu)化類型詳細(xì)介紹其原理與實現(xiàn)，敬請期待。

—— END——

參考資料：

[1]App Thinning詳解：https://medium.com/bitmountn/app-thinning-reduces-ios-app-size-by-40-aa6d37e86771

[2]App Thinning官方介紹：https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f

[3]深入探索 iOS 包體積優(yōu)化：https://juejin.cn/post/6844904169938092045

[4]抖音品質(zhì)建設(shè) - iOS 安裝包大小優(yōu)化實踐篇：https://maimai.cn/article/detail?fid=1579866761&efid=3TGrvi9WKC5IclfDM-DFIQ

[5]正經(jīng)分析iOS包大小優(yōu)化：https://mp.weixin.qq.com/s/\_Mvl0FGriKsvAyRheU2Z7w

[6]XCode14介紹：https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes

推薦閱讀：基于FFmpeg和Wasm的Web端視頻截幀方案

百度研發(fā)效能從度量到數(shù)字化蛻變之路

百度內(nèi)容理解推理服務(wù)FaaS實戰(zhàn)——Punica系統(tǒng)

精準(zhǔn)水位在流批一體數(shù)據(jù)倉庫的探索和實踐

視頻編輯場景下的文字模版技術(shù)方案

淺談活動場景下的圖算法在反作弊應(yīng)用