背景

京東App在2019年做了一輪瘦身，當時做了全方位的瘦身，但隨著業務快速迭代和新技術框架引入以及管控力度不足，安裝包體積出現了反彈。結合之前治而未管和業內一些同行的瘦身經驗，本文介紹此次瘦身過程積累的一些實踐經驗以及管控方案。首先拆分安裝包梳理數據，將安裝包的成份數據做成線上化看板，根據數據找出安裝包體積增長主要因素，結合京東App現狀進行了一系列綜合性的瘦身動作，也沉淀了一套新的管控規范及管控平臺，最終實現了安裝包體積下降30%以上。

安裝包成份分析

瘦身未動，“數據”先行，包瘦身的第一步是要分析出App組成成份的大小數據，為包瘦身的目標設定及任務拆解提供數據支撐，達到可度量、線上化、統一數據標準的目的。如何進行安卓App的包成份分析？安卓開發者基本都會用到Android Studio自帶的Apk Analyzer工具，將Apk文件拖入Android Studio中即可查看，下圖是京東App拖入Android Studio中顯示的包大小數據，可以清晰的看出包體積里占比較大的主要是lib(存放動態庫及安卓插件)、r(存放圖片、xml等資源)、assets目錄、dex和resources.arsc(資源映射表)幾類文件。

apk Analyzer工具對于初步的、特定的包大小數據查看非常方便，但是對于需要進行的包瘦身項目來看，數據過于籠統，沒有按模塊維度進行劃分，無法將包瘦身責任劃分給對應的研發團隊，不便于后續包瘦身項目的具體實施。為了度量各模塊對包大小的影響，我們需要一套精細化的包大小分析方案。

首先來看一下京東App的工程結構，簡化模型如下圖所示。京東App整體采用了插件化的架構，開發迭代過程中逐漸按照功能、業務類型拆分成了很多模塊，各模塊有獨立的項目工程、倉庫，日常進行獨立的開發維護，最終集成在Application工程中。功能型的模塊基本上是以library依賴的形式引入到工程中的，比如常用的網絡庫、圖片庫、埋點庫等；業務型的模塊大多是以插件的形式存在，比如搜索、商詳、購物車等；此外主工程中還存在少部分未拆分成模塊的歷史遺留邏輯，在日常迭代中占比非常少。

基于京東App模塊化的現狀，安裝包的成份分析可以從三個方面進行：分析包成份的總覽數據、分析插件數據和分析library數據。

01

Apk總覽數據分析

安卓的包產物apk文件本質上是一個zip文件，可以用zipinfo命令輸出壓縮包中每個文件的詳細信息日志，用法：

Zipinfo -l --t --h  xxxx.apk > xxxx.txt

輸出的日志文件打開如下圖，每個文件的壓縮信息一行，包括文件名、原始大小、壓縮后大小等指標。

對以上日志信息進行逐行解析，根據解混淆后的文件名路徑、文件類型進行歸類統計，即可得出apk的總覽信息，包括各類型文件的數量、總大小、單一文件大小等指標，并建立文件大小索引。

02

插件數據分析

插件產物的本質也是apk，目前京東App的預裝插件有50+，App打包時各插件會以.so為后綴的形式放在lib目錄中。對插件的分析可以直接基于包產物進行，解析時只需要將apk解壓開來，按照文件名特征將插件從全部so文件中分離出來，逐一按照上述zipinfo相同方法進行解析即可。

03

library數據分析

各library模塊大多是以aar/jar依賴的形式引入到項目工程中，目前京東App的全部項目依賴庫有300+，包括直接依賴、間接依賴。對library數據的分析主要是在分析各依賴對包大小的影響和分析維護開發者兩個方面。

01

分析依賴對包大小影響

安卓工程在構建時，Gradle構建工具會自動將依賴庫同步緩存到本地，與工程中的代碼資源一起編譯merge最終輸出apk。通過編寫gradle腳本任務在構建過程中可以取到aar/jar依賴文件，但是考慮到分析工具的獨立性，盡量避免和打包流程耦合在一起，采用了自行解析依賴的方式來實現，整體流程如下：

a. 打包過程中執行gradle命令生成app運行時依賴樹日志文件，用法：

./gradlew:app:dependencies--configuration xxxReleaseRuntimeClasspath > dep.txt

生成的日志文件部分如下：

b.解析日志文件生成N叉樹模型，每一行日志生成一個依賴節點，包含groupId、artifact_name、version信息，日志中的->表示版本沖突取高版本，(*)表示重復依賴，在application和common_library中添加的依賴為直接依賴，對應根節點和common_library節點的子節點，其它節點為間接依賴。

c.將N叉樹扁平化去重逐一解析依賴，下載aar/jar文件。解析過程中拼接url輪詢倉庫，為了加快解析速度，可以根據依賴的groupId區分依賴的來源，如果是jd內部的依賴，則優先請求內部的私服，否則優先訪問常用的鏡像倉庫。此外可以加入LRU緩存機制，本地存在的依賴產物不再請求倉庫，進一步加快解析速度。存在的一個潛在問題是快照版本的依賴會對應多個產物，解析時取的最新版本可能和app構建時用的不是同一個，通常發版分支上的依賴被規定不能用快照版本，所以這個問題也就間接規避了。

d. aar也是一種zip文件，同樣可以用zipinfo命令來解析組成成份大小，建立內部jar、so、圖片、xml、asset等文件的索引。

e.將aar內部的各文件根據名稱與總覽數據分析時建立的文件大小索引進行關聯，即可知道aar內部的so、圖片、xml、asset等文件最終在apk壓縮包里的大小。由于代碼文件jar最終經過編譯、刪減、混淆merge成了dex，無法精確的溯源，代碼部分的大小計算采用了原始大小按比例折算的方式進行。折算比例是實驗去掉比較獨立的依賴后打包看包大小的差值，去除非代碼部分的大小后，即可算出代碼部分的折算比例，重復N次去除不同的依賴取平均值。

02

分析模塊負責人

前述京東App有300+依賴，由于業務調整、人員變動等原因沒有一個統一的library維護關系數據。對于直接依賴部分，初期通過git blame 命令輸出app、common_library工程的build.gradle文件修改記錄日志，正則匹配出依賴和維護者的對應關系；對于間接依賴部分，將前述N叉樹的每一個間接依賴節點，向上尋找它的父節點直到直接依賴節點，則直接依賴的開發者也是此間接依賴引入的責任人，會存在多個直接依賴引用了同一個間接依賴的情形，即某個間接依賴庫對應多個引入責任人。

通過上述分析方案，已經可以完整的分析出安裝包的各成份大小及對應的負責人，為瘦身工作的實施提供了數據指引。分析方案全部是用python腳本的方式實現，已集成到公司內部的CD系統，數據看板效果如下。

京東App的開發者團隊規模較大，在安裝包成份數據線上化建設完成后，所有開發者統一了看數標準和渠道，每個App版本的增長與下降也可以歸因到具體模塊級別以及對應的開發者，同時這個數據分析看板也為瘦身的度量和管控提供了基礎數據能力。根據數據分析我們發現App內資源文件、ReactNative、插件的數量和體積都比較大，所以瘦身重點圍繞這幾方面進行專項治理，同時基于之前瘦身出現過反彈的教訓，分析發現在過往開發迭代中缺乏約束管控，技術選型和研發復用也暴露了部分問題，因此制定了精細化的管控規范并在研測流程中落地實施。

瘦身方案

借鑒業內的瘦身措施，結合京東App自身特性制定了瘦身方案，首先進行了常規化瘦身舉措主要包括壓縮資源、內置ReactNative轉為下載、插件轉下載、R8編譯升級等，其次對App內的圖片進行專項治理，構建了圖片管理平臺，最終使安卓安裝包體積下降了近30%+，包體積瘦身趨勢圖如下圖。

01

瘦身措施

• 插件轉下載

京東mPaaS平臺提供了安卓端插件轉下載安裝的能力，2022年初我們協同mPaaS團隊、運維團隊共同對其進行優化提升了其可用性和穩定性。將下載器的unknown host問題解決，加入了httpdns能力，支持切換域名能力等，運維團隊通過撥測解決某些cdn節點異常導致的文件md5不一致問題，最終在真實用戶網絡環境下平均單次下載網絡請求成功率在98%以上，由于在用戶進入頁面前存在多次觸發下載的機會，進入頁面而未加載成功場景的概率在十萬分之4以下，此概率已低于App的崩潰率，體驗上已完全可以保障，實踐過程中也未出現用戶體驗異常反饋。通過業務模塊的uv進行倒排序，最終甄選了10+插件進行了轉下載安裝。

• RN內置包轉下載

在優化之初，京東大部分用React Native開發的業務模塊均采用內置App的方式，峰值數量達到50+個。聯合mPaaS團隊進行優化，最初評估采用Brotli壓縮本地內置包，經評估其解壓耗時是gzip的2倍，內存使用是幾十至幾百倍，最終放棄這個方案。統一采用了將內置包轉下載安裝的方案，通過拆分基礎包和業務包將JSBundle體積縮小，設置了預下載非強制更新、預下載強制更新以及增加某個RN業務打開則觸發其他未下載業務下載等策略有效提升了單周新版更新覆蓋率，提供h5降級、統一兜底降級等多重兜底體驗，最終提升了RN相關能力的穩定性和可用性，保障了用戶體驗，目前內置的RN業務模塊數已經降至個位數。

• 資源壓縮

針對圖片壓縮，借助集成TinyPNG壓縮工具對10K以上的圖片進行壓縮；受限于Android工程minSdkVersion=16，不能將所有的png圖片都轉成webp格式，只能將無透明通道的圖片轉成webp。后期對包大小更嚴格的要求，可以考慮將圖片遠程化。

• iconfont

借助瘦身腳本分析工具掃描安裝包中方正純色的小圖片轉成iconfont，包內掃描出800多張可轉成iconfont，數量較多需要長期治理，雖然收益不明顯但利于各個業務零散的小圖標進行統一管理，同時有利于App整體視覺風格的統一。

• R文件內聯

通過自定義Gradle插件利用ASM對class文件進行字節碼操作，將class文件中引用到R類資源id替換成對應的常量值并刪除R文件，達到減少包體積的目的。由于京東App采用插件化的方式開發業務，每個業務插件都會引用公共資源，不能簡單的將公共資源id添加到白名單中，所以結合京東App插件化方案（aura）的公共資源id固定的能力，實現插件化工程中的公共資源內聯。目前開啟R文件內聯已完成灰度，后續會陸續上線，包體積整體收益5.5MB以上。

• 開啟R8編譯

隨Target31適配升級AGP到4.1版本，同步開啟了R8編譯，需要注意R8會忽略部分Proguard混淆規則，針對R8編譯對混淆規則的變更點，編寫了mapping文件檢測腳本工具，對Proguard和R8編譯生成的mapping混淆文件進行對比，檢測網絡解析、反射相關的類是否添加了正確的混淆規則，利用工具保障了升級R8編譯后App的穩定性。R8編譯對代碼混淆優化效果要優于Proguard，開啟R8后，包體積減少1.6MB，構建耗時也降低30%（3min）以上。

• 7Zip壓縮

7Zip兼容Zip格式，支持Zip的Deflate算法，使用7zip極限壓縮模式比Android打包默認的zip壓縮率高，可以將加固好的apk文件進行7zip解壓縮后重新簽名，包體積降低約2.2%（2MB）。為了驗證其穩定性與可用性，計劃對內部和外部市場都分別進行灰度，通過京東內部灰度渠道已灰度完成，對外部的各個渠道將包直接投遞到渠道，如小米、華為等在灰度進行中。

在完成這些常規瘦身方案優化后，App安裝包大小依舊較大。先前圖片資源優化主要是通過圖片壓縮、使用一套分辨率xhdpi圖片、圖片轉webp、資源名混淆等方式進行，這些優化方式都是將內置的圖片進行瘦身優化，隨著業務功能的不斷迭代，瘦身收益將越來越少。京東App各個業務的開發方式是以插件化的形式進行，通過對這些業務插件包的分析，發現這些業務模塊中內置的圖片資源大小占各自插件包總大小的25%以上，針對內置圖片資源過多問題，提出一種圖片資源遠程化的優化方案。

02

圖片資源遠程化

直接將圖片資源轉成在線加載可能會影響用戶體驗，將內置的圖片資源從App應用內剝離，然后將圖片上傳到CDN獲取到圖片的網絡鏈接，應用通過加載圖片鏈接進行在線加載的方式來展示圖片，在線加載圖片需要經過下載圖片的過程，考慮到用戶所處的網絡環境受多種因素的影響，常使用默認的兜底圖在圖片展示區域進行占位，或者使用全屏的加載中動畫進行過渡等方式來優化用戶體驗。從優化用戶體驗角度出發，提出一種2層網絡加載+3層降級措施的優化方案，可以提高網絡圖片的加載成功率，同時給用戶展示圖片的體驗如同加載應用內置圖片資源一樣，整體方案如下：

該優化方案主要由圖片管理CMS平臺和獲取圖片信息的客戶端組件組成，由業務研發在CMS配置各自模塊的圖片信息，客戶端通過組件獲取圖片地址展示圖片。

01

CMS圖片管理

1. CMS支持圖片類型包括png、jgp、webp、點9圖等，由業務模塊梳理出內置的圖片素材；
2. CMS以用戶為單位，創建業務模塊，在模塊內上傳圖片獲取圖片CDN鏈接，提供2x、3x兩個分辨率設置，同時可以設置圖片在客戶端生效的版本范圍以及生效平臺Android或iOS；
3. CMS提供將圖片打包成zip壓縮包的功能，在用戶上傳完圖片后，會根據各個圖片生效的客戶端版本區間，生成不同版本區間以及2x、3x兩種分辨率的zip包，會根據客戶端請求接口中的分辨率參數下發不同分辨率的zip包鏈接；
4. CMS提供zip包的預加載策略，分為App啟動時預加載、App首頁加載成功后x秒開始預加載、進入某頁面時預加載等；
5. 用戶根據前面步驟配置完成后，將業務模塊內的圖片名和對應的CDN鏈接組成配置信息由CMS導出，然后將該配置信息文件內置到客戶端，提供跟隨安裝包的兜底體驗。

02

客戶端圖片預加載與緩存

1. 客戶端組件在App啟動時請求CMS后臺提供的查詢接口，獲取當前客戶端版本對應的配置信息，與本地兜底配置信息進行比較，得到的差分信息進行本地持久化；
2. 客戶端組件同時解析后臺接口下發的圖片zip包信息，根據zip包的預加載策略下載對應的圖片zip包，下載完成后解壓到以模塊名命名的本地文件夾中；
3. 當展示圖片時，客戶端組件根據模塊ID+圖片ID優先查詢本地zip包解壓目錄中該圖片是否已存在，如果該圖片已下載，則直接返回該圖片的本地路徑path，客戶端直接使用該本地路徑path展示圖片；如果該圖片還未下載完成，或不存在，則從內置的配置信息文件中獲取該圖片的CDN鏈接，同之前一樣加載圖片的網絡鏈接；如果加載該網絡鏈接還是失敗，則展示默認的兜底圖。

該優化方案中，2層網絡加載的第一層網絡加載是指業務模塊的zip包，下載一次多版本復用；第二層網絡加載是指圖片zip包預加載未完成或失敗時，通過安裝包中內置的圖片CDN鏈接兜底配置信息加載圖片網絡鏈接來展示圖片，該兜底配置信息以圖片名+圖片CDN鏈接鍵值對的形式保存。

3層降級措施的第一層降級是獲取圖片zip包預加載的本地緩存圖片；第二層降級是當本地圖片緩存失效時，獲取內置的圖片CDN鏈接加載；第三層降級則是默認的兜底圖。瘦身業務模塊開啟圖片zip預加載功能時，CMS支持業務模塊設置zip包預加載策略，業務模塊根據實際情況選擇不同的加載策略，例如某些業務模塊頁面入口比較深，這些業務模塊就可以選擇用戶在進入頁面時觸發zip包的預加載；

某些業務模塊進入頁面入口比較淺就可以設置App啟動后空閑時預加載，其他二級、三級的頁面可以設置App啟動后x秒（隨機時間）才開始下載。通過設置這些預加載策略，將圖片zip包分散在不同時間段下載，降低圖片加載時的網絡流量峰值。

上述方案需要業務研發積極配合，需要業務模塊額外通過固定的模塊ID+圖片ID優先獲取本地緩存的方式加載圖片，使用過程較繁瑣，缺乏靈活性，為方便開發者更容易使用，提供更多選擇，降低接入成本，我們在CMS和客戶端作了些改進，又提出了下面的優化方案：

• 圖片CMS變更點

CMS后臺對圖片zip打包做額外處理：取圖片CDN鏈接中固定路徑計算MD5值，并將該MD5值重命名圖片名稱，不保留圖片類型后綴。例如鏈接：https://xxx/jfs/xxx/name.png，對鏈接中jfs開頭和.png之間的路徑字符串進行MD5值計算：MD5(/jfs/xxx/name) =MD5-Value ，以該MD5-Value值作為圖片名稱，并且移除圖片類型后綴名（.png等）， 其他圖片同樣按照該步驟進行重命名，最后打包成以模塊名命名的圖片壓縮包。

• 客戶端變更點

提供一個工具類，以模塊名和圖片CDN鏈接作為入參，對圖片CDN鏈接進行相同的處理，獲取CDN鏈接中固定路徑字符串的MD5值，然后根據模塊名和MD5值查找該圖片本地緩存是否已存在，即圖片zip包預加載是否成功，如果圖片已成功緩存則將該圖片的緩存路徑（file://協議）返回給圖片加載框架，如果圖片緩存不存在，則原樣返回圖片CDN鏈接（http://協議）。同樣也可以結合圖片加載框架實現，新增以業務模塊名作為別名的圖片加載屬性，該別名屬性就是業務模塊圖片緩存本地的目錄，如果設置了該屬性，圖片加載框架就會優先判斷該圖片是否已緩存成功，若圖片已緩存成功，則通過本地路徑展示圖片，若緩存未成功，則直接在線加載圖片，該方案需要客戶端圖片加載框架同時支持file協議和http協議。該方案也可以應用于大促等場景的圖片預加載。

通過埋點數據查看zip包預加載成功率，圖片zip包預加載在配置首頁啟動后x秒下載，iOS端的zip包加載成功率在98.9%~99.1%波動，Android端的zip加載成功率在96.7%~98.1%波動，剩余1%~3%的用戶則通過內置的兜底cdn鏈接在線加載，倆者結合展示圖片的成功率接近100%；客戶端從本地緩存加載圖片的效率要高于從網絡在線加載圖片，省去了等待圖片下載的過程，降低了默認兜底圖的展示概率，在體驗上接近于本地內置圖片加載的效果。

管控

京東App在2019年專項瘦身后經過一段時間又反彈了50%，一方面因為業務快速迭代發展以及新引入了一些比較大的基礎庫，另一方面原因就是重點做了瘦身治理卻沒有深入做管控準入防止劣化。因此在新一輪瘦身優化過程中，我們一邊做瘦身治理，一邊在探索常態化的管控機制，最終沉淀了一套管控規范和管控平臺。

管控的目的不是為了限制需求迭代與增加代碼，目的是做好把控讓合理的代碼放進來，不合理的拒絕掉以及淘汰陳舊的代碼，提升開發者們的瘦身意識。管控對產研全鏈路提出了新的要求，對于以往粗放型的需求開發迭代方式會有所約束，產品側需要及時的配合研發側將ABTest的廢棄實驗代碼下線，研發側需要做好技術規劃和技術選型，盡可能的精簡代碼和復用代碼，加強技術團隊之間的協同，不放置過大或冗余的資源文件等。

管控的前提是基于App已經充分的組件化解耦，且App開發人員規模相對比較大，比如京東App當前安卓端是由業務插件和AAR依賴庫組成。App的組成成份整體上是由一個配置表來表示，配置表內描述所有組件的配置版本信息，一個組件是否允許集成到App內的前提是這個組件體積增長大小符合我們制定的規范，然后組件的最新版本才可以集成到配置表內。我們管控的核心機制就是控制配置表的更新集成權限，以此來約束每個組件的開發者，通過App架構師委員會（京東內由架構師形成的虛擬組織）制定的公共管控規范來評判每個組件體積增長是否合規，合規則準入更新配置表，否則走異常申請流程。

01

管控流程與方案

管控流程是伴隨著開發、測試、發布整個流程進行的，整體的流程如圖所示。開發者開發完成后，由開發者在京東內部的組件構建與發布平臺（mPaaS）發布形成新的組件版本，在構建完成后開發者在打包平臺（Bamboo）基于臨時配置表進行打包并提測，在此過程中會基于包計算出對應組件的體積變化數據，同時打包系統會以郵件形式將數據同步至開發者，盡可能前置的告知開發者是否存在不合規；

測試通過后開發者申請集成組件版本信息至配置表，若合規則更新配置表且流程結束，若不合規開發者可以進行代碼優化后在申請集成，或者申請異常審批流程至App架構師委員會。常規的業務迭代大部分不會出現違規，但也會存在部分異常的情況，異常的處理往往會產生較多的爭議，研發的安裝包體積管控需要頂住產品和業務的壓力，異常處理的流程需要客觀、透明、靈活，異常處理流程如圖所示。

某個組件違規了發起申請，對于三方庫、國家要求的隱私整改、安卓系統升級適配等情況，可以審核準許通過，其他一些特殊情況也可以通過，由App架構師委員會來酌情把控。對于一些正常情況下產生了組件體積增長超限違規，短期無法優化瘦回可以申請設置未來n個版本后瘦回，或者A組件協商B、C組件來協助分擔瘦回，最終瘦身方案由App架構師委員會判斷合理性，后續在n個版本內由平臺自動計算瘦身的階段性進展數據告知瘦身發起的相關人員；在n個版本后若未達成瘦身既定計劃的目標則進行線下專項討論，重新制定計劃或做一些公示性處罰。

判斷一個組件合規與否依賴于管控規范，管控規范由App架構師委員會共同討論制定，最初我們設定的管控規范比較粗糙：每個組件當前版本相對于上個版本應小于等于n KB（起初n設置為100），隨著瘦身進展到后期發現其存在比較多的弊端，對于體積大的模塊其往往是多個開發者協作經常容易出現違規，對于體積小的模塊往往參與人少迭代變化也不頻繁，所以規范根本對其不起作用。

基于這個情況我們改進了規范：將組件分為A1和A2兩類，A1類組件>=n MB，A2類組件<n MB,對于A1類組件限定其年增幅應小于等于x%，對于A2類組件限定其單個版本增量應<=yKB。A1類模塊一般迭代頻率高且開發人員多，限定年增幅度每個版本的回旋調整余地更大；對于A2類模塊迭代頻率一般不高，設定單個版本增量更小也可以對應的約束其增長；對于一些三方庫、公共庫設置白名單處理；從全局來看管控規范基本兼具一定的公平性和合理性。結合App實際情況，通過合理的設定n、x及y值，可以將增幅控制在計劃范圍內。

總結

隨著業務和用戶需求的發展，App的體積會保持向上增長的趨勢，業內各個體積較大的App都在進行著瘦身。我們借鑒了業內一些優秀的瘦身方案，結合京東App的實際場景進行了多項措施相結合的綜合性瘦身方案，提出了既要治理又要管控的思路，沉淀了一套管控規范，并將其落地到研發測試流程系統內。隨著新技術的迭代更新，新的瘦身方案與措施會不斷涌現，我們會持續保持跟蹤，歡迎讀者們交流拍磚。

【參考資料】

1、5年磨一劍｜優酷Android包瘦身治理思路全解：https://developer.aliyun.com/article/953463

2、抖音包大小優化-資源優化：https://juejin.cn/post/6844904106696376334

3、Google縮減應用大小：https://developer.android.google.cn/studio/build/shrink-code#shrink-resources

4、Android App包瘦身優化實踐：https://tech.meituan.com/2017/04/07/android-shrink-overall-solution.html

5、百度App Android包體積優化實踐：https://mp.weixin.qq.com/s?__biz=MzUxMzk2ODI1NQ==&mid=2247485123&idx=1&sn=09e7fb181f8d1e8d0736931c42be0707&chksm=f94c57d3ce3bdec52c78db8b86e1fdac1f4564ccff94382aec1e5fb060b543ab134de7ac9c3d&scene=21#wechat_redirect

6、R8：https://r8.googlesource.com/r8

7、京東插件化工程R文件瘦身技術方案：https://mp.weixin.qq.com/s/JgNugWIyor23J-nrKMC6dg

8、京東到家Android瘦身探索：https://mp.weixin.qq.com/s/qqa931j9Jw2ojCX18E1–g

作者:App瘦身團隊

來源:微信公眾號:京東零售技術

出處:https://mp.weixin.qq.com/s/sSpbbq-v04CAB5ifKmC20g