背景
app 體積越來越大爹橱，App Store 還有 100M 不能使用流量下載的限制。無論是領(lǐng)導(dǎo)或者產(chǎn)品經(jīng)理窄做，都希望包盡量小愧驱，而功能盡量多。
iOS 打包生成的可執(zhí)行文件 ipa椭盏，其實(shí)是個(gè)壓縮包组砚。可以通過 Mac 系統(tǒng)的顯示包內(nèi)容查看其完整的成分掏颊。里面包括了資源文件和可執(zhí)行文件糟红，以及一些開發(fā)人員無法控制的如簽名和權(quán)限文件等艾帐。
拿到減小包體積的工作任務(wù)時(shí)，首先是進(jìn)行資源文件的壓縮和無用資源的刪除盆偿。接下來柒爸，是精簡(jiǎn)代碼量或者通過動(dòng)態(tài)化的方案來代替Native來減小可執(zhí)行文件大小。這里不討論動(dòng)態(tài)化事扭，我們使用前者來完成任務(wù)捎稚。
現(xiàn)狀
精簡(jiǎn)代碼量需要有個(gè)指標(biāo)，特別是多人合作的工程里句旱，每個(gè)人負(fù)責(zé)不同的模塊阳藻。我們需要知道每個(gè)模塊代碼占最終包體的比例和大小。分析代碼量谈撒，顯然是不可以通過統(tǒng)計(jì)未編譯的代碼有多少行來進(jìn)行，宏和編譯選項(xiàng)等因素會(huì)導(dǎo)致編譯后與編譯前差別很大匾南。采用分析最終可執(zhí)行文件成份的方法啃匿。
解決方案
OC 時(shí)代，CocoaPods 的各個(gè) pod 是通過靜態(tài)庫(kù)方式打包進(jìn)最后的可執(zhí)行文件中的蛆楞，在主工程里的代碼和 pods 里的代碼溯乒，從最終結(jié)果看來，沒有區(qū)別豹爹，都在一個(gè)可執(zhí)行文件中裆悄。這里，我們借助于編譯過程生成的輔助文件 LinkMap臂聋。 LinkMap 大體來看由三部分組成——
Object files, Sections, Symbols光稼。Object files 列出了包含的所有的目標(biāo)文件.o和對(duì)應(yīng)的索引。Sections 從概覽上列出可執(zhí)行文件中代碼段和數(shù)據(jù)段的大小孩等。最后 Symbols 是我們分析的重點(diǎn)艾君，從代碼段的起始地址開始，按照地址順序依次列出了代碼中的函數(shù)肄方、全局變量等所占的代碼大小冰垄。每一行由四列，分別是起始地址权她、大小虹茶、對(duì)應(yīng)的文件的索引和具體的函數(shù)名等。
統(tǒng)計(jì) Symbols 的每一行隅要，可以得出每個(gè) .o 所占代碼的多少蝴罪，然后再根據(jù) .o 所在的 pod，可以得出每個(gè) pod 所占代碼的多少拾徙。.o 具體在哪一個(gè) pod 中洲炊，Object files可以看到，因?yàn)榱谐隽送暾奈募窂健Ｗ罱K暂衡，通過 CocoaPods 靜態(tài)庫(kù)集成的 pods询微，占可執(zhí)行文件代碼的多少，就統(tǒng)計(jì)出來了狂巢。
Swift 時(shí)代撑毛，使用動(dòng)態(tài)庫(kù)來集成 pods。最后的可執(zhí)行文件里唧领，會(huì)有內(nèi)嵌的動(dòng)態(tài)庫(kù)可執(zhí)行文件藻雌。不用 LinkMap 文件，統(tǒng)計(jì)動(dòng)態(tài)庫(kù)的可執(zhí)行文件可以得出各個(gè)模塊所占可執(zhí)行文件代碼的多少斩个。
優(yōu)化及后續(xù)
基于以上的分析結(jié)果胯杭，可以每周發(fā)布一個(gè)報(bào)告，公布各個(gè)模塊代碼量的大小和占比受啥。這樣有利于模塊負(fù)責(zé)人及時(shí)的刪除冗余和廢棄代碼做个，及時(shí)的精簡(jiǎn)代碼和重構(gòu)，提升代碼質(zhì)量滚局，減小包體積居暖。
