對(duì) App 包大小做優(yōu)化的目的，就是節(jié)省用戶(hù)流量，提高用戶(hù)下載速度。
App Store 規(guī)定了安裝包大小超過(guò) 150MB 的 App 不能使用 OTA（over-the-air）環(huán)境下載，也就是只能在 WiFi 環(huán)境下下載。所以，150MB 就成了 App 的生死線，一旦超越了這條線就很有可能會(huì)失去大量用戶(hù)。
如果 App 要再兼容 iOS7 和 iOS8 的話，蘋(píng)果官方還規(guī)定主二進(jìn)制 text 段的大小不能超過(guò) 60MB。如果沒(méi)有達(dá)到這個(gè)標(biāo)準(zhǔn)，甚至都沒(méi)法提交 App Store。而實(shí)際情況是，業(yè)務(wù)復(fù)雜的 App 輕輕松松就超過(guò)了 60MB。雖然我們可以通過(guò)靜態(tài)庫(kù)轉(zhuǎn)動(dòng)態(tài)庫(kù)的方式來(lái)快速避免這個(gè)限制，但是靜態(tài)庫(kù)轉(zhuǎn)動(dòng)態(tài)庫(kù)后，動(dòng)態(tài)庫(kù)的大小差不多會(huì)增加一倍，這樣 150MB 的限制就更難守住。
而實(shí)際情況是，業(yè)務(wù)復(fù)雜的 App 輕輕松松就超過(guò)了 60MB。雖然我們可以通過(guò)靜態(tài)庫(kù)轉(zhuǎn)動(dòng)態(tài)庫(kù)的方式來(lái)快速避免這個(gè)限制，但是靜態(tài)庫(kù)轉(zhuǎn)動(dòng)態(tài)庫(kù)后，動(dòng)態(tài)庫(kù)的大小差不多會(huì)增加一倍，這樣 150MB 的限制就更難守住。另外，App 包體積過(guò)大，對(duì)用戶(hù)更新升級(jí)率也會(huì)有很大影響。
官方 App ThinningApp Thinning 是由蘋(píng)果公司推出的一項(xiàng)可以改善 App 下載進(jìn)程的新技術(shù)，主要是為了解決用戶(hù)下載 App 耗費(fèi)過(guò)高流量的問(wèn)題，同時(shí)還可以節(jié)省用戶(hù) iOS 設(shè)備的存儲(chǔ)空間。現(xiàn)在的 iOS 設(shè)備屏幕尺寸、分辨率越來(lái)越多樣化，這樣也就需要更多資源來(lái)匹配不同的尺寸和分辨率。 同時(shí)，App 也會(huì)有 32 位、64 位不同芯片架構(gòu)的優(yōu)化版本。如果這些都在一個(gè)包里，那么用戶(hù)下載包的大小勢(shì)必就會(huì)變大。App Thinning 會(huì)專(zhuān)門(mén)針對(duì)不同的設(shè)備來(lái)選擇只適用于當(dāng)前設(shè)備的內(nèi)容以供下載。比如，iPhone 6 只會(huì)下載 2x 分辨率的圖片資源，iPhone 6plus 則只會(huì)下載 3x 分辨率的圖片資源。
蘋(píng)果公司使用 App Thinning 之前， 每個(gè) App 包會(huì)包含多個(gè)芯片的指令集架構(gòu)文件。以 Reveal.framework 為例，使用 du 命令查看到主文件在 Reveal.framework/Versions/A 目錄下，大小有 21MB。

rhc$ du -h Reveal.framework/*  0B  Reveal.framework/Headers  0B  Reveal.framework/Reveal 16K  Reveal.framework/Versions/A/Headers 21M  Reveal.framework/Versions/A 21M  Reveal.framework/Versions

后，再使用 file 命令，查看 Version 目錄下的 Reveal 文件：

rhc$ file Reveal.framework/Versions/A/Reveal 
Reveal.framework/Versions/A/Reveal: Mach-O universal binary with 5 architectures: [i386:current ar archive] [arm64]
Reveal.framework/Versions/A/Reveal (for architecture i386): current ar archive
Reveal.framework/Versions/A/Reveal (for architecture armv7):  current ar archive
Reveal.framework/Versions/A/Reveal (for architecture armv7s): current ar archive
Reveal.framework/Versions/A/Reveal (for architecture x86_64): current ar archive
Reveal.framework/Versions/A/Reveal (for architecture arm64):  current ar archive

可以看到， Reveal 文件里還有 5 個(gè)文件：
x86_64 和 i386，是用于模擬器的芯片指令集架構(gòu)文件；
arm64、armv7、armv7s ，是真機(jī)的芯片指令集架構(gòu)文件。
用 App Thinning 后，用戶(hù)下載時(shí)就只會(huì)下載一個(gè)適合自己設(shè)備的芯片指令集架構(gòu)文件。App Thinning 有三種方式，包括：App Slicing、Bitcode、On-Demand Resources。
App Slicing，會(huì)在你向 iTunes Connect 上傳 App 后，對(duì) App 做切割，創(chuàng)建不同的變體，這樣就可以適用到不同的設(shè)備。
On-Demand Resources，主要是為游戲多關(guān)卡場(chǎng)景服務(wù)的。它會(huì)根據(jù)用戶(hù)的關(guān)卡進(jìn)度下載隨后幾個(gè)關(guān)卡的資源，并且已經(jīng)過(guò)關(guān)的資源也會(huì)被刪掉，這樣就可以減少初裝 App 的包大小。
Bitcode ，是針對(duì)特定設(shè)備進(jìn)行包大小優(yōu)化，優(yōu)化不明顯。
那么，如何在你項(xiàng)目里使用 App Thinning 呢？其實(shí)，這里的大部分工作都是由 Xcode 和 App Store 來(lái)幫你完成的，你只需要通過(guò) Xcode 添加 xcassets 目錄，然后將圖片添加進(jìn)來(lái)即可.
然后，按照 Asset Catalog 的模板添加圖片資源即可，添加的 2x 分辨率的圖片和 3x 分辨率的圖片，會(huì)在上傳到 App Store 后被創(chuàng)建成不同的變體以減小 App 安裝包的大小。而芯片指令集架構(gòu)文件只需要按照默認(rèn)的設(shè)置， App Store 就會(huì)根據(jù)設(shè)備創(chuàng)建不同的變體，每個(gè)變體里只有當(dāng)前設(shè)備需要的那個(gè)芯片指令集架構(gòu)文件。
使用 App Thining 后，你可以將 2x 圖和 3x 圖區(qū)分開(kāi)，從而達(dá)到減小 App 安裝包體積的目的。如果我們要進(jìn)一步減小 App 包體積的話，還需要在圖片和代碼上繼續(xù)做優(yōu)化。為了減小 App 安裝包的體積，還能在圖片上做些什么？
無(wú)用圖片資源圖片資源的優(yōu)化空間，主要體現(xiàn)在刪除無(wú)用圖片和圖片資源壓縮這兩方面。而刪除無(wú)用圖片，又是其中最容易、最應(yīng)該先做的。像代碼瘦身這樣難啃的骨頭，我們就留在后面吧。那么，我們是如何找到并刪除這些無(wú)用圖片資源的呢？刪除無(wú)用圖片的過(guò)程，可以概括為下面這 6 大步。
通過(guò) find 命令獲取 App 安裝包中的所有資源文件，比如 find /Users/rhc/Project/ -name。
設(shè)置用到的資源的類(lèi)型，比如 jpg、gif、png、webp。
使用正則匹配在源碼中找出使用到的資源名，比如 pattern = @"@"(.+?)""。
使用 find 命令找到的所有資源文件，再去掉代碼中使用到的資源文件，剩下的就是無(wú)用資源了。
對(duì)于按照規(guī)則設(shè)置的資源名，我們需要在匹配使用資源的正則表達(dá)式里添加相應(yīng)的規(guī)則，比如 @“image_%d”。
確認(rèn)無(wú)用資源后，就可以對(duì)這些無(wú)用資源執(zhí)行刪除操作了。這個(gè)刪除操作，你可以使用 NSFileManger 系統(tǒng)類(lèi)提供的功能來(lái)完成,
可以選擇開(kāi)源的工具直接使用,目前最好用的是 LSUnusedResources.

圖片資源壓縮
對(duì)于 App 來(lái)說(shuō)，圖片資源總會(huì)在安裝包里占個(gè)大頭兒。對(duì)它們最好的處理，就是在不損失圖片質(zhì)量的前提下盡可能地作壓縮。目前比較好的壓縮方案是，將圖片轉(zhuǎn)成 WebP。
圖片壓縮工具 cwebp來(lái)將其他圖片轉(zhuǎn)成 WebP。cwebp 使用起來(lái)也很簡(jiǎn)單，只要根據(jù)圖片情況設(shè)置好參數(shù)就行。cwebp 語(yǔ)法如下

cwebp [options] input_file -o output_file.webp

你要選擇無(wú)損壓縮模式的話，可以使用如下所示的命令：

cwebp -lossless original.png -o new.webp

如果圖片大小超過(guò)了 100KB，可以考慮使用 WebP；而小于 100KB 時(shí)，可以使用網(wǎng)頁(yè)工具 TinyPng或者 GUI 工具ImageOptim進(jìn)行圖片壓縮。這兩個(gè)工具的壓縮率沒(méi)有 WebP 那么高，不會(huì)改變圖片壓縮方式，所以解析時(shí)對(duì)性能損耗也不會(huì)增加

代碼瘦身
App 的安裝包主要是由資源和可執(zhí)行文件組成的，所以我們?cè)谡莆樟藢?duì)圖片資源的處理方式后，需要再一起來(lái)看看對(duì)可執(zhí)行文件的瘦身方法。可執(zhí)行文件就是 Mach-O 文件，其大小是由代碼量決定的。通常情況下，對(duì)可執(zhí)行文件進(jìn)行瘦身，就是找到并刪除無(wú)用代碼的過(guò)程。而查找無(wú)用代碼時(shí)，我們可以按照找無(wú)用圖片的思路，即：
首先，找出方法和類(lèi)的全集；
然后，找到使用過(guò)的方法和類(lèi)；
接下來(lái)，取二者的差集得到無(wú)用代碼；
最后，由人工確認(rèn)無(wú)用代碼可刪除后，進(jìn)行刪除即可

LinkMap 結(jié)合 Mach-O 找無(wú)用代碼
怎么快速找到方法和類(lèi)的全集。我們可以通過(guò)分析 LinkMap 來(lái)獲得所有的代碼類(lèi)和方法的信息。獲取 LinkMap 可以通過(guò)將 Build Setting 里的 Write Link Map File 設(shè)置為 Yes，然后指定 Path to Link Map File 的路徑就可以得到每次編譯后的 LinkMap 文件了
LinkMap 文件分為三部分：Object File、Section 和 Symbols

其中：Object File 包含了代碼工程的所有文件；
Section 描述了代碼段在生成的 Mach-O 里的偏移位置和大小；
Symbols 會(huì)列出每個(gè)方法、類(lèi)、block，以及它們的大小。
通過(guò) LinkMap ，你不光可以統(tǒng)計(jì)出所有的方法和類(lèi)，還能夠清晰地看到代碼所占包大小的具體分布，進(jìn)而有針對(duì)性地進(jìn)行代碼優(yōu)化。
得到了代碼的全集信息以后，我們還需要找到已使用的方法和類(lèi)，這樣才能獲取到差集，找出無(wú)用代碼。

通過(guò) AppCode 找出無(wú)用代碼那么，有什么好的工具能夠找出無(wú)用的代碼嗎？當(dāng)代碼量過(guò)百萬(wàn)行時(shí) AppCode 的靜態(tài)分析會(huì)“歇菜”。但是，如果工程量不是很大的話，建議直接使用 AppCode 來(lái)做分析。畢竟代碼量達(dá)到百萬(wàn)行的工程并不多。那些代碼量達(dá)到百萬(wàn)行的團(tuán)隊(duì)，則會(huì)自己通過(guò) Clang 靜態(tài)分析來(lái)開(kāi)發(fā)工具，去檢查無(wú)用的方法和類(lèi)。用 AppCode 做分析的方法很簡(jiǎn)單，直接在 AppCode 里選擇 Code->Inspect Code 就可以進(jìn)行靜態(tài)分析。

運(yùn)行時(shí)檢查類(lèi)是否真正被使用過(guò)即使你使用 LinkMap 結(jié)合 Mach-O 或者 AppCode 的方式，通過(guò)靜態(tài)檢查已經(jīng)找到并刪除了無(wú)用的代碼，那么就能說(shuō)包里完全沒(méi)有無(wú)用的代碼了嗎？實(shí)際上，在 App 的不斷迭代過(guò)程中，新人不斷接手、業(yè)務(wù)功能需求不斷替換，會(huì)留下很多無(wú)用代碼。這些代碼在執(zhí)行靜態(tài)檢查時(shí)會(huì)被用到，但是線上可能連這些老功能的入口都沒(méi)有了，更是沒(méi)有機(jī)會(huì)被用戶(hù)用到。也就是說(shuō)，這些無(wú)用功能相關(guān)的代碼也是可以刪除的。

那么，我們要怎么檢查出這些無(wú)用代碼呢？通過(guò) ObjC 的 runtime 源碼，我們可以找到怎么判斷一個(gè)類(lèi)是否初始化過(guò)的函數(shù)，如下：

#define RW_INITIALIZED (1<<29)
bool isInitialized() {
   return getMeta()->data()->flags & RW_INITIALIZED;
}

isInitialized 的結(jié)果會(huì)保存到元類(lèi)的 class_rw_t 結(jié)構(gòu)體的 flags 信息里，flags 的 1<<29 位記錄的就是這個(gè)類(lèi)是否初始化了的信息。而 flags 的其他位記錄的信息，你可以參看 objc runtime 的源碼，如下：

// 類(lèi)的方法列表已修復(fù)
#define RW_METHODIZED         (1<<30)
// 類(lèi)已經(jīng)初始化了
#define RW_INITIALIZED        (1<<29)
// 類(lèi)在初始化過(guò)程中
#define RW_INITIALIZING       (1<<28)
// class_rw_t->ro 是 class_ro_t 的堆副本
#define RW_COPIED_RO          (1<<27)
// 類(lèi)分配了內(nèi)存，但沒(méi)有注冊(cè)
#define RW_CONSTRUCTING       (1<<26)
// 類(lèi)分配了內(nèi)存也注冊(cè)了
#define RW_CONSTRUCTED        (1<<25)
// GC：class有不安全的finalize方法
#define RW_FINALIZE_ON_MAIN_THREAD (1<<24)
// 類(lèi)的 +load 被調(diào)用了
#define RW_LOADED             (1<<23)

flags 采用位方式記錄布爾值的方式，易于擴(kuò)展、所用存儲(chǔ)空間小、檢索性能也好
既然能夠在運(yùn)行中看到類(lèi)是否初始化了，那么我們就能夠找出有哪些類(lèi)是沒(méi)有初始化的，即找到在真實(shí)環(huán)境中沒(méi)有用到的類(lèi)并清理掉。我們可以在線下測(cè)試環(huán)節(jié)去檢查所有類(lèi)，先查出哪些類(lèi)沒(méi)有初始化，然后上線后針對(duì)那些沒(méi)有初始化的類(lèi)進(jìn)行多版本監(jiān)測(cè)觀察，看看哪些是在主流程外個(gè)別情況下會(huì)用到的，判斷合理性后進(jìn)行二次確認(rèn)，最終得到真正沒(méi)有用到的類(lèi)并刪掉。