簡介：包大小增量分析

作者：閑魚技術(shù)-金喏

1.背景

??不知大家是否注意到，閑魚的包大小在隨著服務(wù)用戶的增多和新業(yè)務(wù)的持續(xù)迭代不斷增長。在過去的半年時間，Android端包大小漲了43%，iOS端也漲了26%，若再不加管控，按照目前的增長速度再過1年可直逼200M。
??包大小對應(yīng)用的下載轉(zhuǎn)化率和留存率起到至關(guān)重要的作用，瘦包作為閑魚技術(shù)今年的重點項目，意義非同凡響。
??對于閑魚來說，瘦包能提升應(yīng)用的下載轉(zhuǎn)化率。首先是蘋果公司不支持流量下載超過200M的包，包越大下載時間越長失敗率越高，且據(jù)Google play統(tǒng)計，包大小每增加6M，下載轉(zhuǎn)化率會下跌1%。此外也能提升用戶的留存率，因為當(dāng)用戶手機內(nèi)存不夠用時，肯定是優(yōu)先刪除占內(nèi)存比較大的app。
??對開發(fā)來說，定期清理廢棄代碼、不用的SDK和整理重復(fù)的資源，有助于提高代碼的健康度和架構(gòu)的合理性。
??但隨著每一次客戶端發(fā)布，業(yè)務(wù)導(dǎo)致的增量使包大小默默攀升。業(yè)務(wù)需求是要做的，包大小也是要控的，為了讓每一次新需求集成時，開發(fā)們能切實感受到對整體包大小的影響，讓每一次包大小變動都有跡可循，需要對包大小進(jìn)行科學(xué)分析。
??現(xiàn)在開發(fā)每次提交代碼后，會觸發(fā)打包平臺自動打包，包構(gòu)建成功后會自動進(jìn)行包對比分析，并發(fā)回開發(fā)包增量分析報告郵件。在介紹這個包增量分析工具之前，先給大家科普下安裝包的構(gòu)成。

2.安裝包構(gòu)成

2.1 Android包構(gòu)成

??Android安裝包是以后綴名為“apk”的壓縮包。閑魚安裝包解壓后的主要構(gòu)成如下：
??AndroidManifest.xml 配置文件：包含包名、組件、權(quán)限的配置信息等。
??resources.arsc android資源索引表：包含資源名稱、類型、值、ID和配置信息。
??classes.dex ：是很多.class文件處理后的產(chǎn)物，最終可以在 Android 運行時環(huán)境執(zhí)行。
??/assets ：放置隨包打入的文件，如text、二進(jìn)制數(shù)據(jù)等。
??/res 資源文件：存放圖片、字符串、布局文件、xml文件等，運行打包時沒有使用的文件資源不會打入包中。
??/lib ：程序運行時依賴的庫。

2.2 iOS包構(gòu)成

??iOS安裝包是后綴為“ipa”的壓縮包，解壓后主要包含以下幾部分：
??簽名文件：里面的CodeResources包含對bundle中的所有資源文件的簽名信息。
??資源文件：程序運行過程中需要的資源，比如圖片、音頻、視頻、nib文件、配置文件等。
??可執(zhí)行文件：是通過編譯器、連接器將我們編寫的代碼、靜態(tài)庫、動態(tài)庫編譯成的文件，是程序的主體。其中靜態(tài)庫在鏈接時會被完整的復(fù)制到可執(zhí)行文件中，被多次使用就有多份拷貝，動態(tài)庫則是鏈接時不復(fù)制，程序運行時由系統(tǒng)動態(tài)加載到內(nèi)存，系統(tǒng)只加載一次，多個程序共用。
??bundle文件：工程中使用的其他第三方或資源的bundle。

3.包分析方案

3.1 Android包分析

??apk壓縮包按照資源文件類型分類，主要有：so資源（程序運行依賴的庫，如接入UC瀏覽器內(nèi)核SDK時，引入的so達(dá)到驚人的12M）、圖片資源（png、webp、jpg等）、Java代碼（dex文件）、xml代碼這幾類，此外還可橫向統(tǒng)計flutter相關(guān)資源情況。
??由于可以拿到單個文件的信息，所以我們開發(fā)了工具解析apk包中的內(nèi)容，從文件類型角度分析包資源占比情況，以及將資源文件按照大小排序展示，并以圖表形式直觀告訴開發(fā)資源情況。

3.2 iOS包分析

??我們現(xiàn)在是從靜態(tài)庫、動態(tài)庫、資源維度來分析包內(nèi)容和增量。

3.2.1 靜態(tài)庫大小

??通過分析link map文件獲得靜態(tài)庫大小，網(wǎng)上有很多l(xiāng)ink map的解析工具。核心是解析link map文件中的Object files和Symbols中的數(shù)據(jù)。

#Object files: [ 0] linker synthesized [ 1] /Users/xy/build/workspace/Pods/MNN/MNN.framework/MNN(MNNReluInt8-24695ca527c0186b07.o) [ 2] /Users/xy/build/workspace/Pods/MNN/MNN.framework/MNN(MNNGemmInt16to32_4x4_Unit-416f183fdf349b160b82.o) [ 3] /Users/xy/build/workspace/Pods/MNN/MNN.framework/MNN(CPUPermute.o)

??每一行代表對應(yīng)可執(zhí)行文件的編號，如CPUPermute.o文件編號是3。

#Symbols: #Address Size File Name 0x100006CA0 0x000000EC [ 3] __MNN10CPUPermuteC2EPNS_7BackendEPKNS_2OpE 0x100006D8C 0x0000004C [ 3] __MNN2Op15main_as_PermuteEv 0x100006DD8 0x00000008 [ 3] __MNN10CPUPermute8onResizeERKNSt3_$body 0x100006DE0 0x00000580 [ 3] __MNN10CPUPermute9onExecuteERKNSt3_$body 0x100007360 0x00000034 [ 3] __MNN38___CPUPermuteCreator__OpType_Permute__Ev 0x100007394 0x00000070 [ 3] __MNN10CPUPermuteD1Ev

??在Symbols部分，Address是偏移地址，Size是所占內(nèi)存大小，File所指的編號就是Object files中的文件編號，將Symbols中所有相同編號的Size累加起來，即可獲得該編號對應(yīng)可執(zhí)行文件的大小了。
??然后根據(jù)可執(zhí)行文件的目錄信息，可知該文件所屬的靜態(tài)庫，從而計算出對應(yīng)靜態(tài)庫代碼大小。此外靜態(tài)庫大小在計算時需要排除對應(yīng)的dead Stripped Symbols 的大小來獲得真正的二進(jìn)制大小，因為這些是無用的符號，鏈接的時候不會加入。

3.2.2 動態(tài)庫大小

??動態(tài)庫通常位于安裝文件根目錄下的Frameworks目錄中，通常是一個后綴為.framework的文件夾。
??由于動態(tài)庫在arm64架構(gòu)下比較大，且蘋果在拆包階段會將打包好的通用的主二進(jìn)制和動態(tài)庫拆分成單架構(gòu)的主二進(jìn)制和動態(tài)庫，所以只要是涉及二進(jìn)制只計算arm64單架構(gòu)的情況即可。
??動態(tài)庫大小是直接用lipo 拆成arm64單架構(gòu)大小后計算framework文件夾占磁盤大小獲得。

3.2.3 模塊大小

??模塊大小為庫大小+該模塊所有資源文件占磁盤的大小，若為動態(tài)庫的模塊，則資源大小僅計算拷貝到主bundle的資源。分析結(jié)果如下圖所示：

3.需求增量卡口

??瘦包主要靠開發(fā)努力，要讓大家在平時開發(fā)中有瘦包的意識，最好有工具能讓開發(fā)在日常開發(fā)中清楚知道每個文件/模塊的大小，切實感受到需求集成后對整體包大小的影響和相關(guān)文件/模塊變動情況，從而促進(jìn)開發(fā)進(jìn)行相應(yīng)的優(yōu)化。

3.1 增量自動分析

??通過將前面介紹的包分析能力集成到打包腳本，在每次包構(gòu)建成功時，也會同步產(chǎn)出基礎(chǔ)的包內(nèi)容信息，再通過進(jìn)一步的分析后獲得包中每個文件/模塊的大小情況。當(dāng)代碼改動觸發(fā)重新打出新包后，文件/模塊通過一一對比的方式，找出哪些有新增，哪些被刪除，哪些內(nèi)容發(fā)生變動，以及變動產(chǎn)生的大小，并產(chǎn)出對比報告郵件。通過這樣的方式讓開發(fā)對代碼增量有一個直觀感受。
??那如何讓包增量分析工具能在日常開發(fā)中持續(xù)穩(wěn)定發(fā)揮作用呢，接下來介紹閑魚的需求增量卡口設(shè)計。

3.2 增量卡口設(shè)計

??在之前，閑魚的包大小差異通常都在拉出集成分支，打出版本release包時才發(fā)現(xiàn)，經(jīng)常會震驚于這個版本的包又比上一個版本要大幾M，然后再緊急去尋找是什么需求集成導(dǎo)致的巨大增量。但這時發(fā)現(xiàn)包大小的問題已經(jīng)非常滯后了，版本馬上就要發(fā)布，這個時候即使抓到了劇增的源頭，也很難在短時間內(nèi)進(jìn)行優(yōu)化。
??因此需要增加需求集成卡口，測試通過后在合入主分支之前，經(jīng)過包增量確認(rèn)再集成，而不是在集成后打出release包時?，F(xiàn)在的做法如下，開發(fā)只需要提交代碼，即可自動獲得包增量分析報告。

??其中包增量對比郵件內(nèi)容，會包含與主分支最新構(gòu)建、當(dāng)前分支前一次構(gòu)建，當(dāng)前分支最初一次構(gòu)建包的包大小和增量的對比結(jié)果。此外為了數(shù)據(jù)的準(zhǔn)確性，需要開發(fā)在拉出開發(fā)分支后先構(gòu)建一個基準(zhǔn)包，并在提測和集成前合并一把主干，這樣報告數(shù)據(jù)才會更準(zhǔn)確。

??最后是提測部分，開發(fā)同學(xué)發(fā)送提測郵件時需要標(biāo)注本次提測包增量及圖片壓縮情況，若需求增量大于100K，根據(jù)超出范圍情況，需要備注原因和老板確認(rèn)。bug修復(fù)期間不免也會有代碼改動，在測試完成后集成前，會再確認(rèn)一次包增量情況再集成。

4.效果與展望

??閑魚需求增量卡6.20正式上線至今半月，7個客戶端新需求都收到了嚴(yán)格的卡口洗禮。以iOS為例，這半個月主干分支包大小不增反降0.5M，在開發(fā)過程中，開發(fā)也開始有意識通過優(yōu)化老業(yè)務(wù)代碼和資源，為新需求增量挪出空間。
??需求增量卡口只是長效控制包大小的一個手段，加強開發(fā)在日常編碼中的瘦包意識，讓每一次需求都有跡可循，此外對于存量的資源、業(yè)務(wù)代碼清理等手段也在有序進(jìn)行，flutter產(chǎn)物更精細(xì)的分析方案和有效的瘦身方法也在持續(xù)探索中，期待小胖魚早日瘦身成功吧～

原文鏈接：https://developer.aliyun.com/article/766949?

版權(quán)聲明：本文中所有內(nèi)容均屬于阿里云開發(fā)者社區(qū)所有，任何媒體、網(wǎng)站或個人未經(jīng)阿里云開發(fā)者社區(qū)協(xié)議授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式復(fù)制發(fā)布/發(fā)表。申請授權(quán)請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發(fā)者社區(qū)協(xié)議授權(quán)的媒體、網(wǎng)站，在轉(zhuǎn)載使用時必須注明"稿件來源：阿里云開發(fā)者社區(qū)，原文作者姓名"，違者本社區(qū)將依法追究責(zé)任。 如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：developer2020@service.aliyun.com 進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的欲瘦其包，必先探清其底细的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。