分類： 資源、編譯、執(zhí)行的代碼
瘦身：
1、 資源文件（尤其是圖片)
https://github.com/tinymind/LSUnusedResources/
1)檢查文件里面沒有
直接使用到的；
- 檢查出來的圖片并不是一定沒有使用的，有可能有一些是一組的，或者作為資源使用的，這個根據(jù)自己的項目來確定是否有用，不過，這個軟件已經(jīng)幫助我們過濾了一次，所以范圍小了很多。
- 按照項目圖片命名的特殊性，進行判斷特殊的圖片是否使用了。【項目圖片命名應(yīng)該按照約定的規(guī)則】
- 壓縮圖片， 尤其是大的圖片 imageopim
- 不影響是覺的情況下，可以壓縮改變通道。 32bit —> 8bit
- xib 這些文件占用相對大點，改為代碼寫布局
2、冗余的代碼
1、沒有使用的代碼
1)WBBlades 檢查沒有用的文件
里面列出來文件很多，但是，需要思考，我們排除掉第三方庫等等，這個看看需要怎么修改？
- 過濾出來的，并不是一定是沒有用的，自己還是要到代碼里面搜索，因為有些是判斷不出來的 【不支持，以及項目可能存在bug】
2、優(yōu)化重復(fù)的代碼
1)代碼組織在同一個地方, 重復(fù)代碼的優(yōu)化
- 代碼瘦身，不應(yīng)該破壞代碼的開發(fā)原則， 比如：開閉原則
3、app thinning
1> app thiing 會把上傳的包重新組合， 給沒給機型申城特定的安裝包。
- 只包含當(dāng)前設(shè)備的二進制文件： armv7s的機制不需要arm64的二進制文件
- 只包含當(dāng)前文件的圖片， 視網(wǎng)膜屏就不需要2x圖了。
把你上傳的包重新組合下，會給每個機型生成特定的安裝包。它的原理是，
2> On Demand Resource (按需下載)
不是很常用的資源放到后臺
3> BitCode
誤傳可以減小尺寸，我試過沒有明顯效果。在編譯選項里打開就行。
4> 確認(rèn)編譯選項：
Optimization Level: Fastest,Smallest
Deployment Postprocessing: Yes
Strip linked Product: Yes
Symbols Hidden by default: Yes
Make Strings Read-only: Yes
https://github.com/kobe1941/shell 統(tǒng)計各個靜態(tài)庫的大小
https://github.com/xuezhulian/selectorsunref iOS瘦身，沒有使用的方法
盡可能的用數(shù)據(jù)來進行衡量一下
我們的目標(biāo)是什么？是給“下載包”瘦身，而不是“上傳審核包”。區(qū)別在于審核包，會包含所有硬件架構(gòu)的二進制內(nèi)容。上傳后蘋果會自動幫我們拆分開，針對不同手機生成不同的下載包。下載包的大小可以到app 開發(fā)者后臺自己看。
小結(jié)：
1、 主要看資源文件的大小優(yōu)化
2、一大片的不是使用的代碼，應(yīng)該刪除
3、代碼優(yōu)化，對于占用大小影響不大，如果可以選擇，代碼的合理性應(yīng)該更加重要
4、靜態(tài)庫要不要處理？
5、 我們是下載包瘦身，而不是上傳審核包。 審核包是包括所有硬件架構(gòu)的二進制內(nèi)容， 上傳蘋果后會自動拆分開，針對不同的手機生成不同的下載包。 —— app開發(fā)者后臺查看。 但是，上傳包可以瘦身普通的內(nèi)容 —— 區(qū)分： （1）上傳包階段的瘦身 ， （2）下載包階段的瘦身
刪除無用代碼帶來另一個福利就是，App的啟動速度變快了。
啟動速度的時間長度， 和包的大小也是 有關(guān)系的 ， 因為啟動的過程就是加載的過程。 這個啟動的優(yōu)化，下一次詳細(xì)弄一下；
1、 看一下各個版本的記錄， 圖片壓縮是否有效果？
參考鏈接：
https://xie.infoq.cn/article/c2de1ff54b2f5b88170541b73
http://www.cocoachina.com/articles/859032
http://sindrilin.com/2018/12/11/image_subtraction.html
http://www.cocoachina.com/articles/859032
https://github.com/jezzmemo/iOSThin
http://m.itdecent.cn/p/77d306595698 這個工具
1、資源瘦身
2、編譯瘦身
3、可執(zhí)行文件優(yōu)化，
