漫談 App 瘦身

前段時間部門開需求會，砍掉了應用中的部分需求。這簡直就是給應用瘦身的良機！這個時候測試又提出來：安卓端的 App 在應用市場的包只有 26M，而 iOS 端的 App 在 App Store 上卻有 88M。

會後,我就找來安卓的測試機,對比了百度、支付寶、微信、京東、新浪和抖音幾個 App 在應用市場和 App Store 上的大小，數據以下：

顯而易見，相同的應用，安卓端的應用安裝包遠小於 iOS 端。究其緣由，筆者雖也查閱了一些資料，鑑於對安卓系統的機制不瞭解不敢妄言。但由此肯定了一點，iOS 端的包體難以作到安卓端那麼小。

迴歸到給應用瘦身的實際問題上來，先來一波常規操做：刪除項目中冗餘的圖片資源！刪除項目中要砍掉的功能，各類冗餘的文件 /xib/storyboard！移除迭代掉的三方 SDK! 這一個版本簡化下來,App Store 中的安裝包大小由 88.1M 降爲 61.7M, 安裝包大小直線降低了百分之三十!

這個版本的簡化成效是較爲可觀的,但也值得反思：

1. 陳舊冗餘代碼/文件的大量存在: 一方面,聽說是由於項目的核心功能是從前幾個實驗app中迭代而來,簡單的 copy 看似大大縮短了開發工期，但公司的項目自己一直並不是組件化開發，冗餘龐雜在所不免。 在這裏，組件化的優點就顯現出來。
2. 反覆無常的需求變更，加之研發自己的惰性：需求的常常變動多少會摧殘研發敏感的心靈，一個功能今天要明天不要後天放一放也是蠻常見。長此以往，一個熬夜寫出來&本身又實在喜歡的功能板塊在面臨夭折時，研發可能就會先放着無論。這樣的操做多了，時間一長，幾經轉手，這樣的代碼/文件就會沉睡在項目中。和同行的一些大牛交流，他們也廣泛吐槽項目中存在不少這樣的問題。最爲離奇的是，一個作音視頻 SDK 的大牛說，他接手的功能裏有個控制器代碼有 5000 行，這個文件有三四年幾乎沒怎麼動過。一系列慘痛的教訓告訴咱們：當刪則刪，良好的編程習慣很是重要！作好提交工做，寫清楚提交內容便可！

說完這些表象，咱們具體來談談 App Thinning，有些人將 App Thinning 和 Bitcode 混爲一談。其實否則，Apple Guides and Sample Code 中介紹 App Thinning 的三個組成部分：App Slicing，Bitcode和On Demand Resources這三個部分：

• App Slicing(應用切片):

切片是爲不一樣的目標設備建立和交付應用程序包變體的過程。從 iOS9.0 開始, 你跟往常同樣往 iTunes 上提交.ipa文件。App Store 將根據您的應用支持的設備來建立和提供不一樣的變體。圖片資源根據其分辨率和設備系列進行切片。GPU 資源根據設備功能進行切片。

用戶在支持的設備上安裝應用程序，應用商店會下載基於用戶設備的應用程序變體。

從圖(2)中咱們能夠清楚看到：同一個應用的相同版本,在同使用 2x 圖片的機型(iPhone5s/iPhone6)上的包體大小相同，卻比使用 3x 圖片的 iPhone6plus 略小。也就證實了以上觀點。

• On Demand Resources(隨需應變資源):

按需資資源是一種資源，例如圖像和聲音，您可使用標記關鍵字和組內請求。商店託管 Apple 服務器上的資源併爲您管理下載。按需資源可實現更快的下載速度和更小的應用程序大小，從而改善首次發佈體驗。例如，遊戲應用能夠將資源劃分爲遊戲級別，而且僅當應用預期用戶將移動到該級別時才請求下一級資源。一樣，只有當用戶購買相應的應用購買時，應用才能請求應用內購買資源。

當再也不須要資源而且磁盤空間不足時，操做系統會清除按需資源。若是您導出應用程序以在商店外進行測試或者分發，則必須本身託管按需資源。請注意，不支持可執行的按需資源。

對於用戶而言，按需資源在後臺透明地工做，在用戶瀏覽應用程序功能時根據須要提供資源。

備註：要在應用程序中設置按需資源，請參閱 Apple Guides and Sample Code 中"On-Demand Resources Guide "。

Xcode默認啓用按需應變資源

• Bitcode(位碼):

Bitcode 經過消除針對不一樣架構的優化，以及只下載相關優化，從而使下載變得更小。

Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store. Xcode hides symbols generated during build time by default, so they are not readable by Apple. Only if you choose to include symbols when uploading your app to iTunes Connect would the symbols be sent to Apple. You must include symbols to receive crash reports from Apple. ----Apple Guides and Sample Code

位碼是編譯程序的中間表示形式。你上傳到 iTunes Connect 中包含位碼的應用程序將被編譯並連接到商店。包括位碼將容許蘋果在將來從新優化你的應用程序二進制而不須要提交一個新的應用程序版本到 App Store。

Xcode 隱藏了默認狀況下在構建期間生成的符號，所以蘋果沒法讀取這些符號，只有當你的應用程序上傳到 iTunes Connect 時包含符號，這些符號纔會被髮送到蘋果。你必須包含一些符號來接收來自蘋果的崩潰報告。

Xcode 默認啓用 Bitcode，但筆者在一次集成三方 SDK 時，文檔上要求關閉 Bitcode。所以,是否開啓該屬性也要靈活決定。

綜上可見， 蘋果官方對於應用瘦身的機制已然至關完善，開發者養成良好的編程習慣相當重呀。在探究應用瘦身的過程當中，筆者也看到有關於「無損壓縮圖片」「靜態庫瘦身」的這樣一些觀點，你們也可觀摩學習。