iOS安裝包瘦身 - 全部實測
“如果不能衡量，就無法管理”。-- 管理大師彼得.德魯克
先確定目標
“如果不能衡量，就無法管理”。對於效能優化來講，不能衡量就無法知道優化結果的好壞。
我們的目標是什麼？是給“下載包”瘦身，而不是“上傳稽核包”。區別在於稽核包，會包含所有硬體架構的二進位制內容。上傳後蘋果會自動幫我們拆分開，針對不同手機生成不同的下載包。下載包的大小可以到app 開發者後臺自己看。
下載包的大小
最終安裝到手機上佔用的空間就是“安裝大小”，它一定會大於“下載大小”。儘量減少小檔案、或把小檔案都合併在一起可以有效減小“安裝大小”。
安裝大小可以在手機上檢視：設定-》通用-》iPhone儲存空間，找到你要檢視的app。
我們這裡目標在於“安裝大小”。
不要忘記app thinning
千萬不要忘記蘋果的app thinning，它從3個方面有效縮減了安裝大小。
App Slicing
把你上傳的包重新組合下，會給每個機型生成特定的安裝包。它的原理是，
1，只包含當前裝置的二進位制檔案：armv7s的機器不需要arm64的二進位制檔案。
2，只包含當前檔案的圖片：視網膜屏就不需要2x圖了。
這裡要說明一點，有的開發者會只生成arm64下執行程式碼，以為省去armv7s的大小。實際上這隻影響了上傳稽核包的大小。因為最後蘋果會自動重打包。
On Demand Resource
按需下載資源，不常用資源可以設定ODR資源，也可以有效減少安裝包大小。只要在工程裡開啟，再配合ORD用法。本質還是從網路側下載資源。現在誰都有個伺服器，把資源放自己伺服器上就可以了。我能想到的場景，就是單機App、沒有自己伺服器的App、耗頻寬的音訊類大檔案。
BitCode
誤傳可以減小尺寸，我試過沒有明顯效果。在編譯選項裡開啟就行。
資源瘦身
主要指圖片、音訊、視訊等其他非原始碼檔案。思路就是
1，刪除不用的、重名的、相似的。
2，再就是採用壓縮技巧
3，非常用資源專為按需下載。類似App Thinning的ODR思路。
4，storyboard和xib也非常佔資源，影秀城App目前已經全部改成程式碼佈局了。
還有更精細的技術，比方把不影響顯示效果的情況下把32bit圖片轉為8bit圖片。
資源瘦身
這一步驟的重點在於有好的工具幫助發現無用資源、壓縮資源。
這篇文章介紹的非常詳細了： 《質量監控-圖片減包》
我也有個發現，影秀城App裡圖片資源大約在4.5M，用圖片工具壓縮後顯示減少了1.8M。但打包後，發現App的安裝大小並沒有顯著變化。原因是：
App打包過程本身也會採用壓縮演算法，之前圖片資源壓縮比很高；通過圖片工具處理後的圖片資源已經無法再壓縮了，所有打包後大小並無顯著變化。
程式碼瘦身
先把簡單的幾步做了，確認編譯選項：
Optimization Level: Fastest,
Smallest Deployment Postprocessing: Yes
Strip linked Product: Yes
Symbols Hidden by default: Yes
Make Strings Read-only: Yes
沒毛病的好，這些都是Release版本的預設選項。
再就是不要使用動態庫
主要留意pod中把“use_frameworks!”這樣註釋掉，否則產生動態庫，而不是靜態庫。
重點是發現和移除無用程式碼
還是文章開頭那句話，沒有度量就沒法進行優化。
利用工具可以檢視每個靜態檔案和每個.o檔案大小； 工具在這裡 從重點著手：
檢視靜態庫和.o檔案大小
這個工具 可以檢視OC中未使用的方法。
稍微改一下後，這個作者還提供了工具。查詢是否在程式碼裡呼叫了被廢棄的系統函式。
刪除無用程式碼帶來另一個福利就是，App的啟動速度變快了。
專案實踐
1，在影秀城App裡，最大收益還是來自於刪除了無用資源和無用程式碼。
2，無用資源和無用程式碼還是反應了UI設計師和iOS工程師在專案管理上的無序。
3，今後在專案中的改進：
-- 開發完成後開發人員通過工具進行自查，然後再提交個測試。
-- 測試人員通過檢查包大小，對於異常包增值要提出異議。
思考&總結
1，效能類的優化必須要有量化的結果可以檢視，明確目標。
-- 有的文章裡錯誤的以上傳稽核的包大小作為了優化目標。
-- 核實優化結果，比方圖片壓縮後，其實並沒減少“下載大小”。
2，效能類優化，必須要有合適的工具進行輔助。
3，瞭解下App Thinning的概念。
4，對於小廠來講，最重要的就是 及時 刪除無用資源、無用程式碼，不至於以後無法收拾。
5，對iOS開發到一定程度不能滿足於寫寫程式碼。要做全方面瞭解、瞭解些背後的故事。比方，這個編譯過程。
人只有碰到一堵牆彈回來，才會瞭解真正的自己。所以我要去找堵牆...