?

背景

京东App在2019年做了一轮瘦身，京东当时做了全方位的卓端瘦身，但随着业务快速迭代和新技术框架引入以及管控力度不足，瘦身实践WhatsApp%E3%80%90+86%2015855158769%E3%80%91football%20shirts%20for%20little%20brothers安装包体积出现了反弹。京东结合之前治而未管和业内一些同行的卓端瘦身经验，本文介绍此次瘦身过程积累的瘦身实践一些实践经验以及管控方案。首先拆分安装包梳理数据，京东将安装包的卓端成份数据做成线上化看板，根据数据找出安装包体积增长主要因素，瘦身实践结合京东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依赖的形式引入到工程中的，比如常用的网络库、图片库、埋点库等；业务型的WhatsApp%E3%80%90+86%2015855158769%E3%80%91football%20shirts%20for%20little%20brothers模块大多是以插件的形式存在，比如搜索、商详、购物车等；此外主工程中还存在少部分未拆分成模块的历史遗留逻辑，在日常迭代中占比非常少。

基于京东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图片管理

CMS支持图片类型包括png、jgp、webp、点9图等，由业务模块梳理出内置的图片素材；CMS以用户为单位，创建业务模块，在模块内上传图片获取图片CDN链接，提供2x、3x两个分辨率设置，同时可以设置图片在客户端生效的版本范围以及生效平台Android或iOS；CMS提供将图片打包成zip压缩包的功能，在用户上传完图片后，会根据各个图片生效的客户端版本区间，生成不同版本区间以及2x、3x两种分辨率的zip包，会根据客户端请求接口中的分辨率参数下发不同分辨率的zip包链接；CMS提供zip包的预加载策略，分为App启动时预加载、App首页加载成功后x秒开始预加载、进入某页面时预加载等；用户根据前面步骤配置完成后，将业务模块内的图片名和对应的CDN链接组成配置信息由CMS导出，然后将该配置信息文件内置到客户端，提供跟随安装包的兜底体验。

02

客户端图片预加载与缓存

客户端组件在App启动时请求CMS后台提供的查询接口，获取当前客户端版本对应的配置信息，与本地兜底配置信息进行比较，得到的差分信息进行本地持久化；客户端组件同时解析后台接口下发的图片zip包信息，根据zip包的预加载策略下载对应的图片zip包，下载完成后解压到以模块名命名的本地文件夹中；当展示图片时，客户端组件根据模块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类组件

总结

隨著業務和用戶需求的發展，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