先看下Apple對安裝包大小的限制:html
解壓ipa文件,檢查是否有無用資源存在。ios
如今應該沒有APP須要支持iPhone4如下的機型了,因此1X的圖片能夠所有刪掉。3X的圖片是保留仍是刪掉看具體狀況。git
重複的圖片分兩種,一種是名字同樣的圖片,若是你使用.xcassets來管理圖片,那麼Xcode的左邊欄會有警告提示圖片名字重複,直接按提示一一處理便可。另外一種是名字不同可是文件同樣的圖片,咱們使用了一個Python腳本(@甘超江 大神出品)來掃描,每次編譯的時候執行該腳本,若是有掃描命中則會讓Xcode編譯失敗,此時須要人工去處理。須要注意的一點就是使用.xcassets來管理圖片的時候回存在一個映射關係,經過imageNamed:方法使用的名字和圖片的真實名字有可能不同,腳本掃描的時候須要特別處理下。github
未使用的圖片能夠經過LSUnusedResources掃描出來,不過要注意的是可能會有誤傷,該工具是全匹配,一些拼接名字來使用的圖片要注意手動剔除。筆者就由於誤刪圖片被懲罰過o(╯□╰)oshell
一些音頻、視頻和多餘的plist文件以及readme文件什麼的目測只能肉眼掃描了,咱們沒用到這些資源暫時沒這個問題。微信
首先是圖片壓縮,ImageOptim工具能夠實現無損壓縮。app
另外關於圖片,建議使用Apple推薦的.xcassets來管理,它會把裏邊的全部png格式的圖片壓縮成一個Assets.car文件,壓縮比率比其餘方式管理圖片要高。不過測試發現jpg圖片不會在Assets.car文件裏。函數
另若是你有用到音頻或視頻資源,也能夠考慮壓縮。工具
若是你的H5有本地頁面和資源,能夠考慮所有遠端化。本地資源主要是一些js、html文件和圖片。測試
這個最有用的一個選項是Deployment Postprocessing
和Strip Linked Product
,兩個須要都設置爲YES纔有用。
原理是打開這兩個選項後構建ipa會去除掉symbol符號,就是那些類名啊函數名啊啥的。這樣子的影響就是運行時你無法進行線程回溯,符號都沒了回溯了也是亂碼。可是不會影響正常的崩潰日誌生成和解析。在本機專門測試過,若是使用符號表來解析崩潰日誌,則徹底不受影響。
其餘編譯選項見下方的思惟導圖。
原理直接參考微信的這篇文章,主要是使用otool這個工具去取出可執行文件裏的一些編譯信息,能夠拿到該可執行文件裏全部的類和函數列表,以及使用過的類,二者相減就獲得一個初步的未使用的類的列表,不過可能會有誤傷,須要一一確認。
好比model層的mantle和realm,JsonKit和SBJson等功能相似的只須要一個就好,或者直接用系統自帶的Json序列化工具。能夠肉眼掃描也能夠本身寫腳本去掃描。若是使用了Cocoapods來管理第三方庫的話,查詢起來會更方便一些。
有些函數只是實現了一個[super function],例如didReciveMemoryWarning,或者viewDidAppear若是沒作額外的處理其實都是能夠刪除的。
能夠在每一個版本開發結束時統計一下各工程所佔可執行文件的大小,這樣能夠看到size的趨勢。
我寫了個腳本能夠用來統計每一個工程靜態庫的大小和framework的大小,見這裏
效果圖以下:
不過要注意的是,此處的工程靜態庫指的是這個工程的總體產出,而不是引入的某個第三方的靜態庫:
重構以免重複代碼,以及未使用函數的掃描和刪除都對減小ipa size有幫助,不過這二者不像上面提到的那些方法效果好,並且難度更大一些。尤爲是重構,若是一開始設計的很差,可能一些重複的代碼處處都是,好比屏幕寬高的宏,計算給定字符串高度的代碼,給定寬高和顏色畫一張圖片等等這些代碼都極可能被複制的不少份。
引入第三方庫要慎重評估是否值得,有時候爲了一個功能引入了一個很大的第三庫,形成ipa size的顯著增長,可是其實你只用到了其中一小部分功能,這個時候能夠考慮本身實現其功能,而不是引入該庫。
咱們在實踐中發現,技術上對於減小ipa大小最有用的主要是刪掉未使用圖片、去掉一些重複功能的第三方庫以及編譯選項去掉symbol符號。從產品角度砍掉部分雞肋的功能效果卻更明顯,版本在迭代的過程當中會有不少功能的嘗試,功能收斂對ipa size的減小也頗有幫助。
最後附上思惟導圖一張
參考連接和拓展閱讀
原文:http://www.zoomfeng.com/blog/ipa-size-thin.html