特別是App Store 規(guī)定了安裝包大小超過150MB的 App 不能使用 OTA（over-the-air）環(huán)境下載，也就是只能在WiFi 環(huán)境下下載。所以，150MB就成了 App 的生死線，一旦超越了這條線就很有可能會失去大量用戶。
官方 App Thinning
App Thinning 是由蘋果公司推出的一項(xiàng)可以改善 App 下載進(jìn)程的新技術(shù)，主要是為了解決用戶下載 App 耗費(fèi)過高流量的問題，同時還可以節(jié)省用戶 iOS 設(shè)備的存儲空間。
無用圖片資源
圖片資源的優(yōu)化空間，主要體現(xiàn)在刪除無用圖片和圖片資源壓縮這兩方面。
刪除無用圖片的過程，可以概括為下面這6大步。
1.通過 find 命令獲取App安裝包中的所有資源文件，比如 find /Users/daiming/Project/ -name。
2.設(shè)置用到的資源的類型，比如 jpg、gif、png、webp。
3.使用正則匹配在源碼中找出使用到的資源名，比如 pattern = @"@"(.+?)""。
4.使用find 命令找到的所有資源文件，再去掉代碼中使用到的資源文件，剩下的就是無用資源了。
5.對于按照規(guī)則設(shè)置的資源名，我們需要在匹配使用資源的正則表達(dá)式里添加相應(yīng)的規(guī)則，比如 @“image_%d”。
6.確認(rèn)無用資源后，就可以對這些無用資源執(zhí)行刪除操作了。這個刪除操作，你可以使用 NSFileManger 系統(tǒng)類提供的功能來完成。
圖5 刪除無用圖片資源的過程
如果你不想自己重新寫一個工具的話，可以選擇開源的工具直接使用。我覺得目前最好用的是 LSUnusedResources，特別是對于使用編號規(guī)則的圖片來說，可以通過直接添加規(guī)則來處理。使用方式也很簡單，你可以參看下面的動畫演示：
圖片資源壓縮
目前比較好的壓縮方案是，將圖片轉(zhuǎn)成 WebP。WebP 是 Google公司的一個開源項(xiàng)目。
Google公司在開源WebP的同時，還提供了一個圖片壓縮工具 cwebp來將其他圖片轉(zhuǎn)成 WebP。cwebp 使用起來也很簡單，只要根據(jù)圖片情況設(shè)置好參數(shù)就行。
我的建議是，如果圖片大小超過了100KB，你可以考慮使用 WebP；而小于100KB時，你可以使用網(wǎng)頁工具 TinyPng或者GUI工具ImageOptim進(jìn)行圖片壓縮。這兩個工具的壓縮率沒有 WebP 那么高，不會改變圖片壓縮方式，所以解析時對性能損耗也不會增加。
代碼瘦身
App的安裝包主要是由資源和可執(zhí)行文件組成的，所以我們在掌握了對圖片資源的處理方式后，需要再一起來看看對可執(zhí)行文件的瘦身方法。
可執(zhí)行文件就是 Mach-O 文件，其大小是由代碼量決定的。通常情況下，對可執(zhí)行文件進(jìn)行瘦身，就是找到并刪除無用代碼的過程。而查找無用代碼時，我們可以按照找無用圖片的思路，即：
首先，找出方法和類的全集；
然后，找到使用過的方法和類；
接下來，取二者的差集得到無用代碼；
最后，由人工確認(rèn)無用代碼可刪除后，進(jìn)行刪除即可。
接下來，我們就看看具體的代碼瘦身方法吧。
LinkMap 結(jié)合 Mach-O 找無用代碼
我們可以通過分析 LinkMap 來獲得所有的代碼類和方法的信息
LinkMap文件分為三部分：Object File、Section 和 Symbols。如下圖所示：
我們可以使用 MachOView 這個軟件來查看Mach-O 文件里的信息。MachOView 同時也是一款開源軟件，如果你對源碼感興趣的話，可以點(diǎn)擊這個地址查看。
具體的查看方法，我將通過一個案例和你展開。
- 首先，我們需要編譯一個 App。在這里，我clone了一個GitHub上的示例 下來編譯。
- 然后，將生成的 GCDFetchFeed.app 包解開，取出 GCDFetchFeed。
-
最后，我們就可以使用 MachOView 來查看Mach-O 里的信息了。
image.png
通過 AppCode 找出無用代碼
用 AppCode 做分析的方法很簡單，直接在 AppCode 里選擇 Code->Inspect Code 就可以進(jìn)行靜態(tài)分析。
靜態(tài)分析完以后，我們可以在 Unused code 里看到所有的無用代碼，如下圖所示：
接下來，我和你說一下這些無用代碼的主要類型。
1.無用類：Unused class 是無用類，Unused import statement 是無用類引入聲明，Unused property 是無用的屬性；
2.無用方法：Unused method 是無用的方法，Unused parameter 是無用參數(shù)，Unused instance variable 是無用的實(shí)例變量，Unused local variable 是無用的局部變量，Unused value 是無用的值；
3.無用宏：Unused macro 是無用的宏。
4.無用全局：Unused global declaration 是無用全局聲明。
看似AppCode 已經(jīng)把所有工作都完成了，其實(shí)不然。下面，我再和你列舉下 AppCode 靜態(tài)檢查的問題：
1.JSONModel 里定義了未使用的協(xié)議會被判定為無用協(xié)議；
2.如果子類使用了父類的方法，父類的這個方法不會被認(rèn)為使用了；
3.通過點(diǎn)的方式使用屬性，該屬性會被認(rèn)為沒有使用；
4.使用 performSelector 方式調(diào)用的方法也檢查不出來，比如 self performSelector:@selector(arrivalRefreshTime)；
5.運(yùn)行時聲明類的情況檢查不出來。比如通過 NSClassFromString 方式調(diào)用的類會被查出為沒有使用的類，比如 layerClass = NSClassFromString(@“SMFloatLayer”)。還有以[[self class] accessToken] 這樣不指定類名的方式使用的類，會被認(rèn)為該類沒有被使用。像 UITableView 的自定義的 Cell 使用 registerClass，這樣的情況也會認(rèn)為這個 Cell 沒有被使用。
基于以上種種原因，使用AppCode檢查出來的無用代碼，還需要人工二次確認(rèn)才能夠安全刪除掉。
運(yùn)行時檢查類是否真正被使用過
define RW_INITIALIZED (1<<29)
bool isInitialized() {
return getMeta()->data()->flags & RW_INITIALIZED;
}
isInitialized 的結(jié)果會保存到元類的 class_rw_t 結(jié)構(gòu)體的 flags 信息里，flags 的1<<29 位記錄的就是這個類是否初始化了的信息。而flags的其他位記錄的信息，你可以參看 objc runtime 的源碼，如下：
// 類的方法列表已修復(fù)
#define RW_METHODIZED (1<<30)
// 類已經(jīng)初始化了
#define RW_INITIALIZED (1<<29)
// 類在初始化過程中
#define RW_INITIALIZING (1<<28)
// class_rw_t->ro 是 class_ro_t 的堆副本
#define RW_COPIED_RO (1<<27)
// 類分配了內(nèi)存，但沒有注冊
#define RW_CONSTRUCTING (1<<26)
// 類分配了內(nèi)存也注冊了
#define RW_CONSTRUCTED (1<<25)
// GC：class有不安全的finalize方法
#define RW_FINALIZE_ON_MAIN_THREAD (1<<24)
// 類的 +load 被調(diào)用了
#define RW_LOADED (1<<23)
flags 采用位方式記錄布爾值的方式，易于擴(kuò)展、所用存儲空間小、檢索性能也好。所以，經(jīng)常閱讀優(yōu)秀代碼，特別有助于提高我們自己的代碼質(zhì)量。
小結(jié)
今天這篇文章，我主要和你分享的是App安裝包的一些瘦身方案。
在我看來，可以把包瘦身方案根據(jù)App的代碼量等因素，劃分為兩種。
對于上線時間不長的新 App 和那些代碼量不大的 App來說，做些資源上的優(yōu)化，再結(jié)合使用AppCode 就能夠有很好的收益。而且把這些流程加入工作流后，日常工作量也不會太大。
但是，對于代碼量大，而且業(yè)務(wù)需求迭代時間很長的 App來說，包大小的瘦身之路依然任道重遠(yuǎn)，這個領(lǐng)域的研究還有待繼續(xù)完善。LinkMap 加 Mach-O 取差集的結(jié)果也只能作為參考，每次人工確認(rèn)的成本是非常大的，只適合突擊和應(yīng)急清理時使用。最后日常采用的方案，可能還是用運(yùn)行時檢查類的方式，這種大粒度檢查的方式精度雖然不高，但是人工工作量會小很多。
