先看下Apple對安裝包大小的限制：

資源優化

1.刪除無用資源

解壓ipa文件，檢查是否有無用資源存在。

現在應該沒有APP需要支持iPhone4以下的機型了，所以1X的圖片可以全部刪掉。3X的圖片是保留還是刪掉看具體情況。

重復的圖片分兩種，一種是名字一樣的圖片，如果你使用.xcassets來管理圖片，那么Xcode的左邊欄會有警告提示圖片名字重復，直接按提示一一處理即可。另一種是名字不一樣但是文件一樣的圖片，我們使用了一個Python腳本（@甘超江 大神出品）來掃描，每次編譯的時候執行該腳本，如果有掃描命中則會讓Xcode編譯失敗，此時需要人工去處理。需要注意的一點就是使用.xcassets來管理圖片的時候回存在一個映射關系，通過imageNamed:方法使用的名字和圖片的真實名字有可能不一樣，腳本掃描的時候需要特別處理下。

未使用的圖片可以通過LSUnusedResources掃描出來，不過要注意的是可能會有誤傷，該工具是全匹配，一些拼接名字來使用的圖片要注意手動剔除。筆者就因為誤刪圖片被懲罰過o(╯□╰)o

一些音頻、視頻和多余的plist文件以及readme文件什么的目測只能肉眼掃描了，我們沒用到這些資源暫時沒這個問題。

2.資源壓縮

首先是圖片壓縮，ImageOptim工具可以實現無損壓縮。

另外關于圖片，建議使用Apple推薦的.xcassets來管理，它會把里邊的所有png格式的圖片壓縮成一個Assets.car文件，壓縮比率比其他方式管理圖片要高。不過測試發現jpg圖片不會在Assets.car文件里。

另如果你有用到音頻或視頻資源，也可以考慮壓縮。

3.H5頁面遠端化

如果你的H5有本地頁面和資源，可以考慮全部遠端化。本地資源主要是一些js、html文件和圖片。

編譯選項優化

這個最有用的一個選項是Deployment PostPRocessing和Strip Linked Product，兩個需要都設置為YES才有用。

原理是打開這兩個選項后構建ipa會去除掉symbol符號，就是那些類名啊函數名啊啥的。這樣子的影響就是運行時你沒法進行線程回溯，符號都沒了回溯了也是亂碼。但是不會影響正常的崩潰日志生成和解析。在本機專門測試過，如果使用符號表來解析崩潰日志，則完全不受影響。

其他編譯選項見下方的思維導圖。

可執行文件優化

1.未使用類的掃描

原理直接參考微信的這篇文章，主要是使用otool這個工具去取出可執行文件里的一些編譯信息，可以拿到該可執行文件里所有的類和函數列表，以及使用過的類，兩者相減就得到一個初步的未使用的類的列表，不過可能會有誤傷，需要一一確認。

2.功能重復的第三方庫

比如model層的mantle和realm，JsonKit和SBJson等功能類似的只需要一個就好，或者直接用系統自帶的Json序列化工具。可以肉眼掃描也可以自己寫腳本去掃描。如果使用了Cocoapods來管理第三方庫的話，查詢起來會更方便一些。

3.空函數及默認實現的函數都可以刪掉。

有些函數只是實現了一個[super function],例如didReciveMemoryWarning，或者viewDidAppear如果沒做額外的處理其實都是可以刪除的。

4.統計項目中各工程在可執行文件的大小占比

可以在每個版本開發結束時統計一下各工程所占可執行文件的大小，這樣可以看到size的趨勢。

我寫了個腳本可以用來統計每個工程靜態庫的大小和framework的大小，見這里

效果圖如下:

不過要注意的是，此處的工程靜態庫指的是這個工程的整體產出，而不是引入的某個第三方的靜態庫：

其他

重構以避免重復代碼，以及未使用函數的掃描和刪除都對減少ipa size有幫助，不過這兩者不像上面提到的那些方法效果好，而且難度更大一些。尤其是重構，如果一開始設計的不好，可能一些重復的代碼到處都是，比如屏幕寬高的宏，計算給定字符串高度的代碼，給定寬高和顏色畫一張圖片等等這些代碼都很可能被復制的很多份。

引入第三方庫要慎重評估是否值得，有時候為了一個功能引入了一個很大的第三庫，造成ipa size的顯著增加，但是其實你只用到了其中一小部分功能，這個時候可以考慮自己實現其功能，而不是引入該庫。

我們在實踐中發現，技術上對于減少ipa大小最有用的主要是刪掉未使用圖片、去掉一些重復功能的第三方庫以及編譯選項去掉symbol符號。從產品角度砍掉部分雞肋的功能效果卻更明顯，版本在迭代的過程中會有很多功能的嘗試，功能收斂對ipa size的減少也很有幫助。

最后附上思維導圖一張

參考鏈接和拓展閱讀

1.iOS APP可執行文件的組成

2.iOS 可執行文件瘦身方法

3.減少iOS應用程序的大小

4.你的iOS安裝包真的“脫光”了么