京东App安卓端瘦身练习

后台

年京东App瘦身。当时，它涉及整个领域的。但由于业务快速迭代，引进新技术框架，管控力度不够，安装包体积回升。本文结合部分业内同仁的体会，提出了过程中积存的一些实践体会和管控方案。首先将安装包拆分成两半进行数据整理，将安装包的组件数据做成在线看板，依据数据找出影响安装包体积增长的主要因素，进行一系列的综合瘦身操作结合京东App的现状，其中也产生了很多。新的一套管控规范和管控平台终于实现了安装包体积缩减30%以上。

安装包的组成分析

瘦身第一步是对Application组件数据进行分析，为瘦身包目的的设定和任务分解提供数据支持，以实现可衡量的、基于Web的、一致的数据准则目的。如何分析Android使用程序的包组件？

Android开发者基本上使用AndroidStudio自带的APKAnalyzer工具。可以将Apk文件挈到AndroidStudio中查看。下图为将AndroidStudioJD使用挈进AndroidStudio时展示的包大小信息。您可以清楚地看到包裹的大小。比较大的卷主要是lib（存放动态库和Android插件）、r（存放图片、xml等资源）、assets目录、dex和resources.arsc（资源映射表），几类文件。

APKAnalyzer工具对于查看原始和特定的包大小数据非常方便，但对于需要完成的包细化项目，数据过于笼统，没有按模块细分，无法共享。将封装变薄的责任交给各自的研发团队。这不利于后续封装瘦身项目的具体实施。为了衡量每个模块对封装的影响，我们需要一个精美化的封装分析方案。

首先我们来看一下京东App的工程结构。下图展示了一个简化模型。京东APP整体摘用插件架构。在开发迭代的过程中，逐渐按照功能和业务类型划分为很多模块。每个模块都有一个独立的项目工程和存储库。进行日常的独立开发和保护，最后集成到使用项目中。功能模块基本都是以库依靠的形式引进到一个项目中，比如常用的网络库、图片库、埋点库等；业务类模块多以插件形式存在，如搜索、公司详情、购物车等；另外，在主项目中还有少量历史遗留逻辑没有模块化，在日常迭代中是非常小的一部分。基于京东App模块化现状，安装包的组件分析可以从包组件概览数据分析、插件数据分析、库数据分析三个方面进行。

展开全文

01

Apk评论数据分析

一个androidpackageproductapk文件本质上是一个zip文件，可以使用zipinfo命令输出压缩包中每个文件的详尽信息日志，用法：

zipinfo-l--t--hxxxx.apkxxxx.txt

输出日志文件将打开，如下图所示。

每个文件都有一行压缩信息，包括文件名、原始大小、压缩后大小等指标。

逐行分析以上日志信息，依据往混杂后的文件名路径和文件类型进行分类统计，得到APK的概况，包括不同类型文件的数量、总大小、单个文件大小等指标。.并创建文件大小索引。

02

插件数据分析

插件的性质也是apk。京东使用目前预装了50多个插件。使用打包时，每个插件都放在lib目录下，后缀为.so。插件分析可以直接基于包装产品。分析的时候只需要解压apk，依据文件名属性，将所有so文件中的plugin解压出来，用上面zipinfo一样的方法一一分析。

03

图书馆数据分析

大多数库模块作为aar/jar依靠项引进到项目工程中。目前京东App所有项目的依靠库超过300个，包括直接依靠和间接依靠。库数据的分析主要有两个方面：每个依靠对包大小的影响分析和保护开发者的分析。

01

分析依靠对包大小的影响

在构建Android项目时，gradle构建工具会自动缓存依靠库，编译项目的代码资源，最后发布apk。通过编写Gradle脚本任务，可以在构建过程中获取aar/jar依靠。但考虑到分析工具的独立性，尽量避免与打包过程的耦合，摘用自分析依靠的方式来实现。大致流程如下：

一种。要为使用程序的运行时依靠树创建日志文件，请在打包过程中运行gradle命令，使用：

./gradlew:app:dependencies--configurationxxxReleaseRuntimeClasspathdep.txt

生成的日志文件部分如下：b.解析日志文件以生成N生成树模型。日志中的每一行都会创建一个依靠节点，包括组ID、artifact_name和版本信息。log中-表达版本冲突取高版本，(*)表达application和common_library中重复依靠添加的依靠是common_library节点的根节点和子节点对应的直接依靠，和其他节点的间接依靠.

C。压平N-tree，下载aar/jar文件，逐一复制分析依靠。筛选过程中url轮询仓库。

为了加快解析速度，可以通过依靠groupId来区分依靠的来源。假如是内部jd依靠，则先查询内部私服，否则先访问常用的镜像仓库。另外可以加进LRU缓存机制，本地存在的依靠产品将不再请求仓库，进一步加快解析速度。一个潜在的问题是快照版本的依靠项对应于多个产品，并且在解析过程中使用的最后一个版本可能与构建使用程序时使用的版本不同。通常会指定release分支的依靠，使得快照版本无法使用，也就隐式避免了这个问题。

d.aar也是一个zip文件，你也可以使用zipinfo命令来分析组件的大小并创建内部jar的索引，包括图像、xml、属性和其他文件。

e.通过对aari内部各个文件进行综合数据分析时创建的文件大小索引，可以知道apk压缩包中aari内部的so、image、xml、asset等文件的最终大小。由于jar码文件最终会被编译、删除、打乱并成一个索引，所以无法正确追溯来源。计算代码段的大小是通过按比例变换原始大小来完成的。转化率是在一次实验中往除相对独立的依靠后包大小的差异。往掉非代码部分的大小后，可以计算出代码部分的转换比例，乘以N次取平均值，往掉不同的依靠。

02

分析模块治理器

上面提到的JD.com使用程序有300多个依靠项。由于业务调整、人员变动等原因，关系型数据治理没有统一的库。对于直接依靠的部分，在gitblame命令开始时下发app和common_library项目的build.gradle文件的变更日志，定期比较依靠和保护者的对应关系；间接依靠部分，对于上述N-tree节点的每一个间接依靠，找到其父节点，直到直接依靠该节点，那么直接依靠的开发者也是负责引进那个间接依靠的人，有情状其中多个直接依靠指的是同一个隐式依靠，即某个隐式依靠库称心MultipleImportObligation特性。通过以上分析方案，可以足够分析出安装包各部件的和对应的负责人，为减重提供数据指挥。分析解决方案全部实现为集成到公司内部CD系统中的python脚本。数据看板的影响如下。

京东使用的开发者团队比较浩大。完成安装包组件数据的在线编译后，所有开发者统一了看看准则和渠道。每个使用程序版本的增加和减少也可以回因于特定的模块级别和各自的开发人员，同时这个数据分析仪表板还提供了要害数据功能来衡量和掌握。依据数据分析，我们发现使用中的资源文件、ReactNative、插件的数量和体积都比较大，所以瘦身主要针对这些方面进行专项掌握。

有限掌握与掌握、技术选型、研发再利用等也突出了一些问题，因此在研究和测试过程中制定并实施了先进的掌握和掌握规范。

计划

借鉴行业精益措施，结合京东App自身特征，制定了精益方案。一是常规瘦身措施主要包括压缩资源、将内置ReactNative转为下载、将插件转为下载、编译升级R8等；二是更新使用内图片。专注治理，搭建镜像治理平台，最终将Android安装包体积缩减近30%+，包体积缩减趋势如下图所示。

01

措施

可下载插件

京东mPaaS平台支持安卓端下载安装插件。2022年初，我们与mPaaS团队和运维团队一起对其进行了优化，以提高其可用性和稳定性。解决下载器未知主机问题，增加+个插件下载安装。

RN内置数据包传输下载优化之初，使用ReactNative开发的京东业务模块大多使用内置使用，峰值达到50+。与mPaaS团队一起优化，初测使用Brotli压缩本地内置包。经评估，解压时间是gzip的两倍，内存占用是几十到上百倍。最后舍弃了这个方案。内置包下载安装统一摘用转换方案，通过划分基础包和业务包减小JSBundle体积，设置预下载可选更新，预下载逼迫更新，增加某些RN服务运行其他非下载服务下载等策略，有效提升了一周内新版本更新覆盖率，提供了h5、统一自下而上升级等多种自下而上的体验，最终提升了稳定性和可用性。RN相关机会和有保证的体会。目前，嵌进式RN业务模块的数量已经超过个位数。

资源压缩

压缩图片，使用集成的TinyPNG压缩工具压缩10K以上的图片；受限于androidprojectminSdkVersion=16，并不是所有的png图片都能转成webp，只有没有透明通道的图片才能转成webp。假如后期对包体要求比较严厉，可以考虑远程掌握图片。

图标字体

使用瘦身脚本分析工具扫描安装包中的正方形和单色小图，并转换为图标字体。包中的800多张图像可以转换为图标字体。数量多需要长期治理。虽然好处不明显，但是对于分散在不同公司的小图标还是有用的。统一治理也促进了使用整体视觉风尚的统一。

R文件内联

使用ASM通过自定义Gradle插件对class文件进行字节码操作，将class文件中引用的R资源ID替换为对应的常量值，删除R文件以减小包体积。由于京东App摘用插件的方式进行业务开发，每个业务插件都引用公共资源，公共资源ID不轻易被白名单，所以结合京东App插件方案（aura）进行改良公共资源ID，实现插件工程中公共资源的收录。目前内联R文件是灰色的，以后会依次运行。数据包体积总量超过5.5MB。

开启R8编译适配Target31，更新AGP4.1版本，同时开启R8编译。需要注重的是，R8漠视了一些Proguard模糊规则。针对混杂规则的R8编译转变点，编写了一个映射文件检测脚本工具来编译生成Proguard和R8。比较映射混杂文件以确定是否已将正确的混杂规则添加到网络分析所涉及的类中。反射和工具确保使用程序在过渡到R8编译后的稳定性。R8编译在代码混杂和优化方面比Proguard有更好的效果。开启R8后，包大小减少了1.6MB，构建时间也减少了30%以上（3分钟）。

7zip压缩

7Zip兼容Zip格式，支持Zip提取算法。使用极限压缩模式7zip比Android打包的默认zip格式具有更高的压缩率。您可以使用7zip解压加固的apk文件并重新签名，将包大小减少约2.2%(2MB)。.为了验证其稳定性和可用性，计划同时治理内部和外部市场。灰度是通过京东内部灰度通道完成的。外部渠道直接将数据包投递到渠道，如小米、华为等度进行中。

这些常规瘦身方案优化完成后，使用安装包的体积还是比较大。之前对图片资源的优化主要是通过图片压缩、辨认率xhdpi图片集、图片转网页、资源名称混合来完成的。这些优化方法旨在精简和优化嵌进式图像。随着业务功能的不断迭代，精益化带来的好处越来越小。京东App的每一项业务开发都是以插件的形式进行的。分析这些业务插件包发现，这些业务模块内置图片资源的大小占对应插件包总大小的25%以上。为解决若干问题，提出了一种远程成像资源优化方案。

02

图片远程资源

图片资源直接转换为在线加载，可能会影响用户体验。

移除使用内嵌的图片资源，然后将图片上传到CDN获取图片在线链接，使用上传图片链接在线展示。图片，网上下载图片必须经过图片下载流程。鉴于用户的网络环境受多种因素的影响，往往会摘用默认的口袋卡占据图片展示区域，或者摘用全屏加载动画过渡等方式来优化用户体验。从用户体验优化的角度，提出2层网络加载+3层措施优化方案，提高网络图片加载的成功率，同时提升向用户展示图片的体验。和加载使用内置的图片资源是一样的。一般的解决方法如下：优化方案主要由图像治理的CMS平台和获取图像信息的客户端组成。业务和开发在CMS中配置各个模块的图片信息，客户端接收图片地址通过组件展示图片。

01

CMS图像治理

CMS支持的图片类型包括png、jgp、webp、dot9图片等，内置图片素材按业务模块排序；

CMS以用户为实体创建业务模块，上传图片到模块中获取图片的CDN链接，提供2x和3x两种辨认率设置，同时设置图片的有效版本领域。在客户端和高效平台Android或iOS上；

CMS提供压缩图像。图片上传后，依据每张图片有效的客户端版本领域生成不同版本领域和2x、3x辨认率的ZIP包。请求接口解析参数以ZIP包发送不同辨认率的链接；

CMS为ZIP包提供了预加载策略，分为使用启动时预加载、使用首页加载成功后x秒开始预加载、进进某个页面时预加载；

用户按照前面的步骤完成配置后，从CMS中导出由业务模块镜像名称和对应的CDN链接组成的配置信息，然后将配置信息文件集成到客户端中，提供全面的信息。安装包合规性体会。

02

预加载和缓存客户端图像

使用启动时，客户端组件请求CMS后台提供的查询接口，获取当前客户端版本对应的配置信息，与本地配置信息进行比对，将差异信息存储到本地；

同时，客户端组件解析后端发送的图片的ZIP包信息，依据ZIP包预加载策略下载对应的ZIP包，下载后解压到本地以模块名命名的文件夹中。已完成;

展示图片时，客户端组件首先依据模块ID+图片ID询问本地ZIP包解压目录下是否已经存在该图片。图片下载时，直接返回图片本地路径，客户端直接使用本地路径展示图片；假如图片没有下载或丢失，从内置的配置信息文件中获取图片的CDN链接，和之前一样加载图片的网络链接；假如网络链接仍然加载，默认展示底部地图。

本优化方案中，二层网络下载的第一层网络下载是指业务模块的ZIP包，一次下载，复用多个版本；二层网络加载是指图片ZIP包预加载时，包中包含的内嵌图片CDN链接pocket配置信息加载网络链接展示图片，pocket底层配置信息存储在form中图片名称+图片CDN链接键值对。解调的第一级是获取预加载了图片zip的本地缓存图片；第二层是在本地图片缓存失效时获取内嵌图片CDN链接加载；第三层是默认行图像。假如瘦身业务模块开启图片zip预加载功能，CMS会支持业务模块确定zip包预加载策略，业务模块会依据实际情状抉择不同的加载策略。进进页面就开始预加载ZIP包；

一些业务模块可以配置为在使用程序闲暇时预加载，当页面负载相对较低时。对于其他二级和页面，您可以将使用程序设置为在使用程序启动后x秒（随机时间）开始下载。通过设置这些预取规则，图片压缩包将在不同的时间段下载，减少图片加载时的网络流量高峰。

上述方案需要业务研发的积极配合，需要业务模块通过固定模块ID+图片ID先获取本地缓存来加载图片。为了降低访问成本，我们对CMS和客户端做了一些改良，提出如下优化方案：

图片CMS编辑点

,jfs和.png作为链接的开头

计算领域内的路径字符串的MD5值：MD5(/jfs/xxx/name)=MD5-Value，将MD5-Value值作为图片名称并往掉图片类型后缀（.png

etc.），其他图片也按照这一步进行重命名，最后打包成一个以模块名命名的图片压缩包。

设置该属性后，图片加载框架会优先考虑图片是否缓存成功。假如图片缓存成功，则通过本地路径展示图片。假如缓存，图像直接上传到网络。该方案要求客户端图片加载框架同时支持file协议和http协议。该方案同样适用于大广告等场景下的图片预加载。

通过埋点数据查看zip包预加载成功率。预加载图像ZIP包将在启动配置主页后x秒下载。iOS端的zip下载成功率在98.9%到99.1%之间，Android端的zip下载成功率为96.7%。~98.1%的波动和剩余的1%~3%的用户通过内置的袖珍CDN链接上传到网络。两者结合展示图像的成功率几乎是100%；客户端从本地缓存加载图片的效率高于从互联网加载图片省往了等待图片下载的过程，降低了展示默认图片的概率，接近本地嵌进的效果。在体验方面的图像加载。

掌握

京东App经过年的专项瘦身，一段时间后恢复了50%。一方面是由于业务的快速迭代发展，引进了一些比较大的核心库。访问可防止腐烂。因此，在新一轮瘦身优化中，我们将在探索规范化掌握机制的同时，应对瘦身掌握，最终建立一套掌握规范和掌握平台。

管控的目的不是限制需求迭代和增加代码，而是掌握和赋能合理的代码录进、不合理的拒绝、废弃代码的淘汰，提高开发者的减重意识。指挥掌握正在对整个产研环节提出新的需求，以往大规模迭代的需求开发方式存在局限性。产品方要及时配合研发方，移除ABTest废弃的实验代码。在研发方面，要做好技术规划和技术选型，代码尽可能顺畅和可复用，加强技术团队的协作，不要放置过大或冗余的资源文件等。管控的假设是基于使用完全组件化解耦，使用开发者规模比较大。比如目前京东App的Android端由企业插件和AAR依靠库组成。使用的组成整体由配置表表达，表中描述了所有组件的配置版本信息。将组件集成到使用中的前提是组件的体积增长符合我们的规范，然后只有最新版本的组件才能集成到配置表中。我们的核心治理和掌握机制是治理配置表更新和集成授权，以限制每个组件的开发人员，并通过使用架构委员会（一个虚拟组织）创建的公共掌握规范来评估每个组件。由JD.com的架构师创建）。组件的体量增长是否符合规则，依据规则访问更新配置表，否则走反常申请流程。

01

检查流程和计划

命令和掌握过程与整个开发、测试和发布过程一起进行。大致流程如图所示。开发者完成开发后，开发者在京东内部组件构建发布平台（mPaaS）上发布新组件的一个版本。

构建完成后，开发者依据暂时配置表对打包平台（Bamboo）进行打包测试。在此过程中，依据封装计算相应组件的体积转变数据，封装系统通过邮件同步给开发者，并尽可能提前告知开发者不合规情状；

测试通过后，开发者请求将组件版本信息集成到配置表中。假如匹配规则，则更新配置表并结束该过程。假如不匹配，开发人员可以优化代码，然后请求集成或请求使用程序架构师委员会进行不普通的批准流程。大多数常见的商业因素都没有违反规则，但也有例外。反常处理往往会引发更多争议。研发开发的安装包的音量掌握，要承担产品和公司的压力。反常处理过程必须客看、透明、灵巧。反常处理流程如图所示。

假如一个组件违反并运行一个使用程序，它可以被审查并批准用于第三方库、国家要求的隐私修复以及Android系统升级和定制。其他特殊情状也可以依据需要由使用程序架构师委员会批准和审查。在一些常见的情状下，当组件体量增长超过限制，无法实现短期优化时，可以请求在未来n个版本后设置细化，或者组件A与组件B、C协商。扶助分享变薄。最终的瘦身方案是由使用的架构决定的。n版本后，平台自动计算分步进度数据，并通知发起的相关工作人员；n版之后，假如既定的计划目的没有达到，会召开专门的线下讨论，重新制定计划或者做一些广告惩罚。确定组件是否合规取决于掌握器的规格。掌握规范由使用程序架构师委员会讨论和制定。最初，我们设置的掌握规范比较粗：每个组件的当前版本与之前的版本相比应该小于或等于nKB（最初n设置为100），随着瘦身的进行到后期，更多发现缺陷。大型模块通常可以让多个开发人员轻松协作并且经常打破规则。小模块往往参与者较少，迭代转变也比较困难。很少，所以规范根本不适用于它。

基于这种情状，我们改良了规范：将组件分为A1类和A2类，A1类组件=nMB，A2类组件

总结

随着业务和用户需求的发展，使用量不断上升，该领域的所有主要使用都在下降。我们借鉴了行业内一些优异的瘦身方案，结合京东使用的实际场景，进行了多措并举的综合瘦身方案，提出了管控并重的理念，推出了一套管控规范，并整合到研发测试过程体系中。随着新技术的迭代发展，新的方案和措施层出不穷，我们也继续监测。欢迎读者互动，提出意见。

【参考】

作者：App瘦身组

来源：微信公众号：京东零售科技