縮減iOS安裝包大小是很多中大型APP都要做的事，一般首先會對資源文件下手，壓縮圖片/音頻，去除不必要的資源。這些資源優(yōu)化做完后，我們還可以嘗試對可執(zhí)行文件進行瘦身，項目越大，可執(zhí)行文件占用的體積越大，又因為AppStore會對可執(zhí)行文件加密，導致可執(zhí)行文件的壓縮率低，壓縮后可執(zhí)行文件占整個APP安裝包的體積比例大約有80%~90%，還是挺值得優(yōu)化的。下面介紹一下在研究可執(zhí)行文件過程中發(fā)現(xiàn)的可以優(yōu)化的點。研究的過程使用了linkmap，linkmap的介紹跟生成可以參考另一篇文章—iOS可執(zhí)行文件的組成。
編譯選項

1.編譯器優(yōu)化級別

Build Settings->Optimization Level有幾個編譯優(yōu)化選項，release版應該選擇Fastest, Smalllest，這個選項會開啟那些不增加代碼大小的全部優(yōu)化，并讓可執(zhí)行文件盡可能小。

2.去除符號信息

Strip Debug Symbols During Copy 和 Symbols Hidden by Default 在release版本應該設為yes，可以去除不必要的調(diào)試符號。Symbols Hidden by Default會把所有符號都定義成”private extern”，具體意思和作用我還不清楚，有待研究，但設了后會減小體積。這些選項目前都是XCode默認選項，但舊版XCode生成的項目可能不是，可以檢查一下。

其他優(yōu)化還可以參考蘋果的官方文檔—CodeFootprint.pdf
第三方庫統(tǒng)計

項目里會引入很多第三方靜態(tài)庫，如果能知道這些第三方庫在可執(zhí)行文件里占用的大小，就可以評估是否值得去找替代方案去掉這個第三方庫。我們可以從linkmap中統(tǒng)計出這個信息，我寫了個node.js腳本，可以通過linkmap統(tǒng)計每個.o目標文件占用的體積和每個.a靜態(tài)庫占用的體積，并進行排序。詳見這里(需翻墻)。
ARC->MRC

有人提出用ARC寫的代碼編譯出來的可執(zhí)行文件是會比用MRC大的，原因大致是ARC代碼會在某些情況多出一些retain和release的指令，例如調(diào)用一個方法，它返回的對象會被retain，退出作用域后會被release，MRC就不需要，匯編指令變多，機器碼變多，可執(zhí)行文件就變大了。還有其他細節(jié)實現(xiàn)的區(qū)別，先不糾結了。

那用ARC究竟會增大多少體積？我覺得從匯編指令的增多減少去算是很難算準確的，這東西涉及細節(jié)太多，還是得從統(tǒng)計的角度計算。做了幾個對比試驗，統(tǒng)計了幾個同時支持ARC/MRC的開源項目在開啟/關閉ARC的情況下__TEXT代碼段的大小對比。只對比__TEXT代碼段是因為：

ARC對可執(zhí)行文件大小的影響幾乎都是在代碼段

可執(zhí)行文件會進行某種對齊，例如有些段在不足32K的時候填充0直到對齊32K，若用可執(zhí)行文件大小對比結果可能是對齊后的，不準確。

實驗數(shù)據(jù)：

結果是ARC大概會使代碼段增加10%的size，考慮代碼段占可執(zhí)行文件大約有80%，估計對整個可執(zhí)行文件的影響會是8%。

可以評估一下8%的體積下降是不是值得把項目里某些模塊改成MRC，這樣程序的維護成本上升了，一般不到特殊情況不建議這么做。
無用代碼

在項目里新建一個類，給它添加幾個方法，但不要在任何地方import它，build完項目后觀察linkmap，你會發(fā)現(xiàn)這個類還是被編譯進可執(zhí)行文件了。

按C++的經(jīng)驗，沒有被使用到的類和方法編譯器都會優(yōu)化掉，不會編進最終的可執(zhí)行文件，但object-c不一樣，因為object-c的動態(tài)特性，它可以通過類和方法名反射獲得這個類和方法進行調(diào)用，所以就算在代碼里某個類沒被使用到，編譯器也沒法保證這個類不會在運行時通過反射去調(diào)用，所以只要是在項目里的文件，無論是否又被使用到都會被編譯進可執(zhí)行文件。

對此我們可以通過腳本，遍歷整個項目的文件，找出所有沒有被引用的類文件和沒有被調(diào)用的方法，在保證沒有其他地方動態(tài)調(diào)用的情況下把它們?nèi)サ?。如果整個項目歷時很長，歷時代碼遺留較多，這個清理對可執(zhí)行文件省出的空間還是挺可觀的。
類/方法名長度

觀察linkmap可以發(fā)現(xiàn)每個類和方法名都在__cstring段里都存了相應的字符串值，所以類和方法名的長短也是對可執(zhí)行文件大小是有影響的，原因還是object-c的動態(tài)特性，因為需要通過類/方法名反射找到這個類/方法進行調(diào)用，object-c對象模型會把類名，方法名列表都保存下來。

可以考慮在編譯前把所有類和方法名進行混淆，把長名字替換成短名字，這樣做的好處除了縮小體積外，還對安全性有很大提升，別人拿到可執(zhí)行文件對它class-dump出來的結果都是混淆后的類和方法名，就無法從類和方法名中猜出某個方法是做什么的，就難以掛鉤子進行hack。不過這樣有個缺點就是crash堆棧反解出來的堆棧方法名會是混淆后的，需要再加一層混淆->原名的轉換，實現(xiàn)和使用成本有點高。

實際上這部分占用的長度比較小，中型項目也就幾百K，對安全性要求高的情況可以試試。
冗余字符串

代碼上定義的所有靜態(tài)字符串都會記錄在在可執(zhí)行文件的__cstring段，如果項目里Log非常多，這個空間占用也是可觀的，也有幾百K的大小，可以考慮清理所有冗余的字符串。另外如果有特別長的字符串，建議抽離保存成靜態(tài)文件，因為AppStore對可執(zhí)行文件加密導致壓縮率低，特別長的字符串抽離成靜態(tài)資源文件后壓縮率會比在可執(zhí)行文件里高很多。
CheckList

最后簡單把縮減iOS安裝包大小的各種方法列出來作為CheckList：

本文鏈接：http://www.cocoachina.com/ios/20150202/11084.html