布景

京东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以及co妹妹on_library中削减的依赖为直接依赖，对于应根节点以及co妹妹on_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、co妹妹on_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+插件妨碍了转下载装置。

在优化之初，京东大部份用React Native开拓的营业模块均接管内置App的方式，峰值数目抵达50+个。散漫mPaaS团队妨碍优化，最后评估接管Brotli缩短当地内置包，经评估其解压耗时是gzip的2倍，内存运用是多少十至多少百倍，最终坚持这个妄想。不同接管了将内置包转下载装置的妄想，经由拆分根基包以及营业包将JSBundle体积削减，配置了预下载非欺压更新、预下载欺压更新以及削减某个RN营业掀开则触发其余未下载营业下载等策略实用提升了单周新版更新拆穿困绕率，提供h5降级、不同兜底降级等多重兜底体验，最终提升了RN相关能耐的晃动性以及可用性，保障了用户体验，当初内置的RN营业模块数已经降至个位数。

针对于图片缩短，借助集成TinyPNG缩短工具对于10K以上的图片妨碍缩短；受限于Android工程minSdkVersion=16，不能将所有的png图片都转成webp格式，只能将无透明通道的图片转成webp。前期对于包巨细更严厉的要求，可能思考将图片短途化。

借助瘦身剧本合成工具扫描装置包中方正纯色的小图片转成iconfont，包内扫描出800多张可转成iconfont，数目较多需要临时规画，尽管收益不清晰但利于各个营业零星的小图标妨碍不同规画，同时有利于App部份视觉气焰的不同。

经由自界说Gradle插件运用ASM对于class文件妨碍字节码操作，将class文件中援用到R类资源id交流成对于应的常量值并删除了R文件，抵达削减包体积的目的。由于京东App接管插件化的方式开拓营业，每一个营业插件都市援用公共资源，不能重大的将公共资源id削减到白名单中，以是散漫京东App插件化妄想（aura）的公共资源id牢靠的能耐，实现插件化工程中的公共资源内联。当初开启R文件内联已经实现灰度，后续会陆续上线，包体积部份收益5.5MB以上。

随Target31适配降级AGP到4.1版本，同步开启了R8编译，需要留意R8会漠视部份Proguard混合纪律，针对于R8编译对于混合纪律的变更点，编写了mapping文件检测剧本工具，对于Proguard以及R8编译天生的mapping混合文件妨碍比力，检测收集剖析、反射相关的类是否削减了精确的混合纪律，运用工具保障了降级R8编译后App的晃动性。R8编译对于代码混合优化下场要优于Proguard，开启R8后，包体积削减1.6MB，构建耗时也飞腾30%（3min）以上。

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图片规画

02

客户端图片预加载与缓存

该优化妄想中，2层收集加载的第一层收集加载是指营业模块的zip包，下载一次多版本复用；第二层收集加载是指图片zip包预加载未实现或者失败时，经由装置包中内置的图片CDN链接兜底配置装备部署信息加载图片收集链接来揭示图片，该兜底配置装备部署信息以图片名+图片CDN链接键值对于的方式保存。

3层降级措施的第一层降级是取患上图片zip包预加载确当地缓存图片；第二层降级是铛铛舆图片缓存失效时，取患上内置的图片CDN链接加载；第三层降级则是默认的兜底图。瘦身营业模块开启图片zip预加载功能时，CMS反对于营业模块配置zip包预加载策略，营业模块凭证实际情景抉择差距的加载策略，好比某些营业模块页面进口比力深，这些营业模块就能抉择用户在进入页面时触发zip包的预加载；

某些营业模块进入页面进口比力浅就能配置App启动后空隙时预加载，其余二级、三级的页面可能配置App启动后x秒（随机光阴）才开始下载。经由配置这些预加载策略，将图片zip包散漫在差距光阴段下载，飞腾图片加载时的收集流量峰值。

上述妄想需要营业研发自动配合，需要营业模块格外经由牢靠的模块ID+图片ID优先获适当地缓存的方式加载图片，运用历程较啰嗦，缺少锐敏性，为利便开拓者更易运用，提供更多抉择，飞腾接入老本，咱们在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的实际场景妨碍了多项措施相散漫的综合性瘦身妄想，提出了既要规画又要管控的思绪，积淀了一套管控尺度，并将其落地到研发测试流程零星内。随着新技术的迭代更新，新的瘦身妄想与措施会不断泛起，咱们会不断坚持跟踪，招待读者们交流拍砖。

【参考质料】

一、5年磨一剑｜优酷Android包瘦身规画思绪全解：https://developer.aliyun.com/article/953463

二、抖音包巨细优化-资源优化：https://juejin.cn/post/6844904106696376334

三、Google缩减运用巨细：https://developer.android.google.cn/studio/build/shrink-code#shrink-resources

四、Android App包瘦身优化实际：https://tech.meituan.com/2017/04/07/android-shrink-overall-solution.html

五、baiduApp Android包体积优化实际：https://mp.weixin.qq.com/s?__biz=MzUxMzk2ODI1NQ==&mid=2247485123&idx=1&sn=09e7fb181f8d1e8d0736931c42be0707&chksm=f94c57d3ce3bdec52c78db8b86e1fdac1f4564ccff94382aec1e5fb060b543ab134de7ac9c3d&scene=21#wechat_redirect

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

七、京东插件化工程R文件瘦身技妙筹划：https://mp.weixin.qq.com/s/JgNugWIyor23J-nrKMC6dg

八、京东抵家Android瘦身探究：https://mp.weixin.qq.com/s/qqa931j9Jw2ojCX18E1--g

作者:App瘦身团队

缘故:https://mp.weixin.qq.com/s/sSpbbq-v04CAB5ifKmC20g