這是一次安裝包大小優化的實踐。

隨着業務的增加，工程中引入越來越多的業務代碼和第三方庫，整個安裝包越來越大。以今日頭條5.7.5為例最近幾個版本的ipa大小如下：

5.7 -> 72.2M (+0.8M) 正常業務增量

5.6 -> 71.4M (+14M) 主要原因：接入某SDK後安裝包的增加(約13M) 京東SDK（約1M）

5.5 -> 57.4M (+1.7M) 正常業務增量

5.4 -> 55.1M (+28M) 主要原因：加入Swift 系統會加入語言庫來支持（約27M）

5.3 -> 27.5M 之前做過一次資源文件和類文件的清理

優化安裝包分為如下幾個步驟：

分析安裝包的構成，一個安裝包分為二進制代碼文件，資源，配置文件。需要知道各個方面的佔比。
知道各個方向的優化策略，譬如二進制文件如何優化，資源文件如何優化
執行優化，得出結果

分析

首先進行第一步，分析安裝包的構成： 88M的安裝包解壓後變成220MB。

ipa是一個壓縮包，安裝包里的主要構成是（圖片+文檔+二進制文件），我們下面的分析

1.圖片優化：

從上面來看，圖片的壓縮比最小。幾乎沒有壓縮，這也說明每減少一張圖片，就實實在在的減少了ipa的大小。為了驗證上面的數據，我們來做一些實驗：我們新建一個項目，測試資源圖片對安裝包的大小的影響：目錄結構如下：

其中資源信息如下：

然後進行打包Archive→Export.得到IPA文件

從上面的結果來看，安裝包的大小基本等於圖片資源的大小，可以看一下IPA的內容詳情視圖（下圖），發現圖片確實沒有怎麼壓縮：

結論1：JPG資源圖片的壓縮比很小，每減少一張圖片，就實實在在的減少了ipa的大小。

下面我們進一步使用ImageOptim對圖片進行壓無損縮優化（如下圖）。看能否優化下安裝包大小。

壓縮後，總文件大小為：屏幕快照 2016-10-25 下午8.58.24.png，優化掉了1MB的大小。我們然後進行打包操作，最終的安裝包確實也小了0.8MB，從11.6MB變成了10.8MB，。還是有優化的，如下圖所示：

，

此時我們看xcode里的工程配置，COMPRESSPNGFILES 是YES的，有一些說法是這個變量的設置和ImageOptim衝突，這裡看起來不是如此。

結論2：ImageOptim有時候還是確實能優化資源大小，進而減少安裝包大小的。

是否因此可以完全確定ImageOptim的優化能力，我覺得看情況而定，上面的幾種圖片都是我iPhone手機里的相片導出的。是JPG的格式。

我們再對PNG做一些測試, 找一些資源圖片放到工程中（我就不截圖了，直截大小）：

打包後的大小是：

系統幫我們優化掉1.1MB。同樣我們隊圖片進行一輪無損壓縮優化，經過ImageOptim優化後效果：

我們進行打包，得到的安裝包的大小是:還是2.2MB（特意將系統優化關閉）：

結論3：對於我找的這幾個png圖片，ImageOptim的優化沒有起到作用。

在我們項目中也對所有資源圖片使用ImageOptim進行了優化，20多MB的資源最後優化掉1MB左右，這裡懷疑ImageOptim對PNG的優化能力一般。而且如果能優化的PNG資源，系統默認可以進行一些優化。

2.文檔資源

從上面來看，文檔有一定的壓縮比，大概40%，也就是如果工程里有40MB的文檔，體驗到壓縮包里大概是40*0.6=24MB。

3.二進制安裝包

二進制代碼的壓縮率是最高的。

上面都是研究不同的資源對最後安裝包大小的影響情況，現在有了一些理論依據，我們就可以開始對安裝包進行優化工作了。

實踐

所以先從圖片開始優化吧：

1.如何優化圖片：

* 使用一些工具來檢測unused 文件。比較推薦的是github上的一份開源代碼：

https://github.com/tinymind/LSUnusedResource 編譯運行看到的頁面是這樣的：

指定搜索路徑，第二行（EXClude）指定哪些文件夾路徑不被掃描。

然後這些資源可以清除掉了。但是存在着圖片被誤刪除的可能性，譬如代碼中使用圖片的方式是：[UIImage imageNamed:[NSString stringWithFormat:”icon_%d.png”,index]]；這種情況下，圖片可能被誤刪，所以刪除的時候不妨10張一組的進行，用眼睛過濾一遍。

* 刪除完圖片，是否還可以對已有的圖片做優化呢。

現在網上有非常多的關於ImageOptim對資源圖片進行無損壓縮的方式，在文章開頭部分我們也對ImageOptim的優化能力進行了一些驗證，通過上面的實驗，我覺得結論不能確定，但值得一試。

2.文檔資源的優化

文檔資源主要是排查：

是否有不必要的文檔資源，如果過期的舊版本所需要的文檔資源清理即可。
優化文檔資源大小，主要是優化精簡文檔內容。

3.二進制包優化

二進制包是由各種代碼文件，靜態庫動態庫經過編譯後生成的可執行文件。以頭條二進制包125MB為例，他是如何組成的?

上圖可以看到armv7 占可執行文件的58MB。 arm64占可執行文件的66MB。加起來=125MB。進一步分析

通過右側的pfile偏移可以大概算出每個段的大小，但不直觀，我們可以通過開啟一些編譯選項，生成可執行文件結構，然後藉助一些工具生成更加直觀的

XCode開啟編譯選項Write Link Map File XCode -> target -> Build Settings -> 搜map -> 把Write Link Map File選項設為yes，並指定好linkMap的存儲位置：
編譯後到編譯目錄里找到該txt文件，文件名和路徑就是上述的Path to Link Map File。
~/Library/Developer/Xcode/DerivedData/XXX-eumsvrzbvgfofvbfsoqokmjprvuh/Build/Intermediates/XXX.build/Debug-iphoneos/XXX.build/。這個LinkMap里展示了整個可執行文件的全貌，列出了編譯後的每一個.o目標文件的信息（包括靜態鏈接庫.a里的），以及每一個目標文件的代碼段，數據段存儲詳情

如上圖，weinAppID這個函數佔得內存大小為1*16 + 13 = 29位元組。樣看下去也挺麻煩的，找個工具歸類一下。

歸類，去
下載這個mac工程然後運行。

譬如內部播放器sdk MediaPlayer在arm64架構下大小為4.92MB， armv7也可以分析另一份armv7 linkmap文件大概4.5MB 二者加起來就是在二進制佔據的總大小—10MB左右。通過對上面的文件進行分析，就知道每個類在最終的可執行文件中佔據的大小。然後有針對性的進行優化就可以了。

4.編譯選項優化：

如果項目是很早之前（xcode4，5）建立的，迭代到現在的確可以檢查一下有利於減少安裝包的編譯選項：

Optimization Level 使用Fastest, Smalllest該選項對安裝包大小影響幾無，但可以提高app的性能。參考wwdc 2013-Session408 Optimize Your Code Using LLVM
Strip Linked Product 設置為YES需要注意的是Strip Linked Product也受到Deployment Postprocessing設置選項的影響。在Build Settings中，我們可以看到， Strip Linked Product是在Deployment這欄中的，而Deployment Postprocessing相當於是Deployment的總開關。記得把Deployment Postprocessing也設置為YES，該選項對安裝包大小的影響非常大，以頭條客戶端為例，如果不開啟此設置，ipa大小是48MB，上線後appstore上顯示的大小是65MB，我們開啟了此配置後，ipa大小變成40MB， appstore上顯示45MB。優化效果還是非常明顯的。 PS：Deployment Postprocessing這個配置項如果使用xcode打包，xcode會默認把這個變量置為YES，如果使用腳本打包，記得設置。
Symbols Hidden by Default設置為YES
Make Strings Read-Only 設置為YES

5.可能無效的辦法：

將Enable C++ Exceptions和Enable Objective-C Exceptions設為NO，去掉異常支持；如果你的項目比較大，有很多try cache，想去掉這些異常可能是一個比較大的工作量，我在頭條項目里嘗試去掉了所有異常，打包測試，安裝包大小沒有變化，因為只是一個項目的測試，我只能比較懷疑去掉異常對最終安裝包大小的優化能力。

6.一些額外的建議

iOS的項目，在安裝包沒有大到一定程度之前，研發和產品一般都關注較少，我們在平時的開發中也會有一些不好的習慣，在這裡枚舉一下：

不要為了一片樹葉引入一片森林。有時候你只想接入一個base64編碼的函數，結果接入了一個有幾十個類文件的util庫，除了你用到的這個函數，其餘的可能再也不會有人用到，另一個研發為了另一個RSA加密需求，結果又引入了另一個一個extensions庫。那些類文件都是成本，類文件，函數，甚至不同長度的函數名字都對最終的安裝包大小產生影響。積少成多，安裝包會越來越大。而且代碼量越大，app啟動時候DYLD鏈接的工作量越大，啟動耗時也會變長。
對於要接入到app的資源文件，要check一下大小，一個100*100大小的圖片如果幾十MB 肯定設計師在切圖的時候有些問題，打包後也要check一遍。對於集體打包到Assert.car里的文件，可以找工具解開看一下。我們遇到過打了一次包後發現安裝包大了幾十MB，經過分析，發現是有一張圖片意外的大，找人優化後變成幾百k。
注意平時的開發習慣，廢棄模塊及早清理。
同質的開源庫（譬如AFnetworking vs ASIHttpRequest），只接入一種。
建立預警機制，一般上線後，都是腳本打包，除了正常的生成ipa包之外，也要生成分析文件，列出相對上一次上線包大了多少，類文件增加了多少。這樣的機制也有助於防止安裝包悄無聲息的變成巨物。

原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/272717.html