京东金融Android瘦身探索与实践

京东技术

发布于 2023-08-22 07:46:53

53900

代码可运行

运行总次数：0

代码可运行

Tech 导读随着业务不断迭代更新，京东金融App(Android版本)的体积也在快速增加，2019年~2022年期间甚至一度超过了117M。2022年9月开始针对金融App进行了瘦身专项整治，最终实现从117M瘦身至74M。本文阐述了整个安装包瘦身过程中遇到的问题以及积累的经验，并详细介绍了具体的解决路径。

背景

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

随着业务不断迭代更新，京东金融App(Android版本)的体积也在快速增加，2019年~2022年期间一度超过了117M，期间也做了部分优化如图1红色部分所示，但在做优化的同时面临着新的增量代码，包体积一直持续上升。包体积直接或间接地影响着下载转化率、安装时间、磁盘空间等重要指标，所以投入精力发掘更深层次的安装包体积优化是十分必要的。根据谷歌商店的内部数据，APK体积每减少10M，平均可增加～1.5%的下载转化率，如图2所示：

图2.谷歌商店应用转化率增加幅度 / 10M [1]

因此2022年9月开始针对金融APP进行了瘦身专项整治，在不考虑增量的情况，无删减业务代码的情况下实现从117M瘦身至74M，在本次安装包瘦身过程中遇到了不少坑，同时也积累了些经验，在此分享给大家。

APK分析

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

接下来会简单分析下 Apk 内各组成部分，以及 Apk 作为 ZIP，其标准结构是什么样的，为包瘦身的目标设定及任务拆解提供数据支撑。

2.1 APK内容分析

图3.APK 结构

classes.dex APK 中可能包含一个或多个 classes.dex 文件，应用程序内的 Java/Kotlin 源码最终会以字节码的方式存在于 classes.dex 文件中。
resources.arsc aapt工具在编译资源会将一些资源或者资源索引打包成resources.arsc。
res/ 源码工程中 res 目录下除了 values 外的资源文件，这些文件路径同时会记录在 resources.arsc 中。
lib/ nativeLibraries，即源码工程 jni 目录下的 so 文件，二级目录为 NDK支持的 ABI。
assets/ 与 res/ 资源目录不同，assets/ 下的资源文件不会在 resources.arsc 中生成查询条目，且 assets/ 下的资源目录可完全自定义，在程序中通过 AssetManager 对象来获取。
META-INF/ 该文件夹下主要包含 CERT.SF 和 CERT.RSA 签名文件, 以及 MANIFEST.MF 清单文件。
AndroidManifest.xml 应用清单文件，用于描述应用基本信息，主要包括应用包名、应用id、应用组件、所需权限、设备兼容性等。

2.2 SDK大小分析

通过自研的能效提升平台Pandora[7]，可以直观地看到SDK的大小，如图4所示：

图4.SDK大小排序（包含版本号）

图5.SDK中包含的SO库列表及大小

根据SDK分析后结合业务，来判断哪些业务适合做插件化，进而直观的降低包体积。

2.3 ZIP结构分析

可以用zipinfo命令输出压缩包中每个文件的详细信息日志，用法：zipinfo -l --t --h test.apk > test.txt

输出的日志文件打开如图6所示，每个文件的压缩信息一行，包括文件名、原始大小、压缩后大小等指标：

图6.APK内文件信息大小

对以上日志信息进行逐行解析，根据解混淆后的文件名路径、文件类型进行归类统计，即可得出Apk的总览信息，包括各类型文件的数量、总大小、单一文件大小等指标，并建立文件大小索引。

瘦身实践

整体实施路径如图7所示，主要分为：

常规技术方案，通过Gradle插件（代码无侵入、自动化）在编译时期完成APP瘦身；
进阶技术方案，将部分业务线差别性的通过插件化或者SO动态下载的方式就行改造，业务改造的越多，收益越高；
业务优化方案，针对业务线的数据埋点，生成访问UV进行排名，将UV较低的业务线反馈架构委员会，评估是否可以进行下线或者通过进阶技术方案（2）进行改造，进而减小包体积。

图7.整体实施路径

3.1 常规技术方案

3-1-1 图片处理

经过上述的APP的剖析，得出占用体积第一大的还是图片，因此将APP所有含SDK内所有图片在编译打包过程中通过瘦身任务自动完成图片优化处理，整体优化方案如图8所示：

图8.图片优化方案

1.多 DPI 优化

Android 为了适配各种不同分辨率或者模式的设备，为开发者设计了同一资源多个配置的资源路径，app 通过 resource 获取图片资源时，自动根据设备配置加载适配的资源，但这些配置伴随着的问题就是高分辨率的设备包含低分辨率的无用图片或者低分辨率的设备包含高分辨率的无用图片。

一般情况下，针对国内应用市场，App 为了减少包大小，会选用市场占有率最高的一套 dpi（google 推荐 xxhdpi）兼容所有设备。而针对海外应用市场的 APP，大多会通过 AppBundle 打包上传至 Google Play，能够享受动态分发 dpi 这一功能，不同分辨率手机可以下载不同 dpi 的图片资源，因此需要提供多套 dpi 来满足所有设备。在项目中，图片有的只有一套 dpi，有的有多套 dpi，针对上述两种场景，分别在打包时合并资源、复制资源，减少了包大小。

2.转换为webp格式：

WebP是谷歌提供的一种支持有损压缩和无损压缩的图片文件格式，而且可以提供比JPEG或PNG更好的压缩。在Android 4.0(API level 14)中支持有损的WebP图像，在Android 4.3(API level 18)和更高版本中支持无损和透明的WebP图像

因此：采用插件在编译时期仅保留针对图片通过Google提供的shell程序进行格式转换，转换成功删除旧的图片，进而达到APK瘦身的效果

3.png压缩

Pngquant是一个好用的png压缩工具，可以进行有损图片压缩的命令行工具，因此在1和2处理结束后，可以使用Pngquant进行二次压缩，达到更优的图片瘦身。

3-1-2 R文件内联优化

DEX里是Java/Kotlin 源码编译后的字节码文件，对DEX的优化其实就是怎么优化字节码文件，DEX中包含大量的资源索引R文件，这里主要讲下如何通过资源ID内联后进行R文件删除，达到APK瘦身的目的：

R文件瘦身的可行性分析

日常开发阶段，在主工程中通过R.xx.xx的方式引用资源，经过编译后R类引用对应的常量会被编译进class中。

setContentView(2131427356);

这种变化叫做内联，内联是java的一种机制（如果一个常量被标记为static final，在java编译的过程中会将常量内联到代码中，减少一次变量的内存寻址）。非主工程中，R类资源ID以引用的方式编译进class中，不会产生内联。

setContentView(R.layout.activity_main);

产生这种现象的原因是AGP打包工具导致的。具体细节，大家可以去查阅一下android gradle plugin在R文件上的处理过程。结论：R类id内联后程序可运行，但并非所有的工程都会自动产生内联现象，需要通过技术手段在合适的时机将R类id内联到程序中，内联完成后，由于不再依赖R类文件，则可以将R类文件删除，在应用正常运行的同时，达到包瘦身目的，如图9所示，在编译完成后会产生大量的R文件：

图9.项目R文件生成示意

整体方案如图10所示：

图10.R文件优化流程

注意事项：在替换阶段一定要加入二次检查，防止替换完，运行时出现ResourceNotFind异常，如下所示：

try {
    int value = RManager.checkInt(type, name);
}catch (Exception e){
    String errorMsg = "resource is not found(I),className="+className+",fieldName="+owner+"."+name;
    throw new ResourceNotFoundException(errorMsg);
}
try {
    int[] value = RManager.checkIntArray(type, name);
}catch (Exception e){
    String errorMsg = "resource is not found(I[]),className="+className+",fieldName="+owner+"."+name;
    throw new ResourceNotFoundException(errorMsg);
}

3-1-3 AndResGuard进行资源混淆

1.资源加载过程分析

开发过程中通过aapt生成的R.java中的常量来使用资源，而在编译之后使用常量的地方都会被替换为常量的值，如下所示：

final View layout = inflater.inflate(2131165182, container, false);

也就是说通过Resource使用一个int数值来查找使用资源。那么Resource是怎么通过int数值找到具体的资源呢？解压apk可以看到里面有个resources.arsc文件，这个文件也是由aapt生成，文件中保存着资源id和资源key的映射关系，Resource就是按照这个映射关系找到资源的。

2.resources.arsc：

图11是resources.arsc的里存储的映射关系，resources.arsc可以理解为一个资源映射数据库，根据ID映射其中具体的路径和名称。

图11.resources.arsc解析

通过解压APK后，将资源文件名进行短链处理比如res/layout/hello.xml转换为r/l/a.xml后，然后更改resources.arsc对应的value值，达到整体的瘦身效果。

AndResGuard[5]是微信推出资源优化工具，它的基本思想类似于 ProGuard 中的混淆，可以实现以上方案。

3-1-4 7zip压缩

7zip命令解释：

-t:指定压缩类型，支持7z, xz, split, zip, gzip, bzip2, tar, ....

-m:指定压缩算法，默认是Deflate

具体流程如下：

第一步：使用7z命令将未签名包解压到指定目录：7za x ${未签名包} -o${7z解压目录}

第二步：首先通过7z命令对解压目录进行全部压缩：7za a -tzip -mx9 ${目标7z文件名} ${7z解压目录}

第三步：获取存储类型文件，通过Android SDK中的aapt命令获取压缩方式为Stored的文件列表：aapt l -v ${未签名包}

第四步：更新存储类型文件，通过7z命令将存储类型文件更新到第二步操作中生成的7zip安装包：7za a -tzip -mx0 ${目标7z文件名} ${存储类型文件目录}

3-1-5 配置CPU架构

根据不同的CPU架构，构建不同的类型的安装包，目前主流设备都是64位机器，因此安卓市场上主要投放的是依据arm64-v8a编译构建的安装包。

ndk {
    abiFilters arm64-v8a
}

3-1-6 arsc 压缩

resources.arsc 的压缩体积收益很高，但对其进行压缩会影响启动速度和内存指标。原因是：系统在加载 arsc 文件时，若 arsc 文件未压缩，可使用 mmap 进行内存映射；若 arsc 文件被压缩了，则需要将其解压缩后读取到RAM 缓冲区，会增加内存使用，也会拖慢启动速度。

官方出于同样的考虑，从 targetSdkVersion>=30后不能用这种方式，开始强制要求resources.arsc ，否则会直接安装失败，因此本文不在展开阐述。

3-1-7 国际化语言处理

京东金融App目前仅在国内市场运营，但是接入的大量SDK中加入了几十种语言一样，导致整个体积变大，经过评估可以通过配置 resConfigs 去除无用的语言资源。

defaultConfig {
    resConfigs "zh","en"
}

3-1-8 shrinkResources

shrinkResources：编译过程中用来检测并删除无用资源文件，也就是没有引用的资源。

minifyEnabled：用来开启删除无用代码，比如没有引用到的代码，所以如果需要知道资源是否被引用就要配合minifyEnabled使用，只有两者都为true时才会起到真正的删除无效代码和无引用资源的目的。

其作用是将未被引用的资源文件替换为一个体积很小的格式文件（仍存在占位体积，同时保留了该资源条目，所以 resources.arsc 体积并不会减少），可通过 res/raw/keep.xml 文件配置 shrinkMode 和白名单。

buildTypes {
   release {
      // 不显示Log
      buildConfigField "boolean", "LOG_DEBUG", "false"
      //混淆
      minifyEnabled true
      // 移除无用的resource文件
      shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig sign.release
   }
}

3-1-9 编码约束

尽量少用枚举类型，因为枚举在编译成字节码后，会增加大量体积，如图12所示（22行代码编译后字节码是86行）

图12.枚举类型编译后的字节码对比

删除不必要的LOG日志输出

3.2 进阶技术方案

SO库动态下载和插件化技术，本质上都属于动态下载的一个范畴，两个方案可以在业务中长期持续使用，在具体使用过程中如何选择，如图13所示：

图13.业务如何选择进阶方案

3-2-1 SO库动态加载

APP中有部分业务不适合做插件化改造，经过拆解发现其中的SO库占比很大，因此可以考虑采用动态下载的方式进行改造，进而实现减小体积。

SO库加载的两种方式：

第一种方式直接把SO库下载并放到指定目录就可以

第二种方式是通过环境变量设置的目录中进行加载SO库，因此需要追加指定的目录到环境变量中，就可以正常加载SO库

System.load("{安全路径}/libxxx.so") 
System.load("xxx")

1、如何设置APP中SO库的环境变量位置（借鉴Tinker）：

final Field pathListField = ShareReflectUtil.findField(classLoader, "pathList");
final Object dexPathList = pathListField.get(classLoader);

final Field nativeLibraryDirectories = ShareReflectUtil.findField(dexPathList, "nativeLibraryDirectories");

List<File> origLibDirs = (List<File>) nativeLibraryDirectories.get(dexPathList);
if (origLibDirs == null) {
    origLibDirs = new ArrayList<>(2);
}
final Iterator<File> libDirIt = origLibDirs.iterator();
while (libDirIt.hasNext()) {
    final File libDir = libDirIt.next();
    if (folder.equals(libDir)) {
        libDirIt.remove();
        break;
    }
}
origLibDirs.add(0, folder);

final Field systemNativeLibraryDirectories = ShareReflectUtil.findField(dexPathList, "systemNativeLibraryDirectories");
List<File> origSystemLibDirs = (List<File>) systemNativeLibraryDirectories.get(dexPathList);
if (origSystemLibDirs == null) {
    origSystemLibDirs = new ArrayList<>(2);
}

final List<File> newLibDirs = new ArrayList<>(origLibDirs.size() + origSystemLibDirs.size() + 1);
newLibDirs.addAll(origLibDirs);
newLibDirs.addAll(origSystemLibDirs);

final Method makeElements = ShareReflectUtil.findMethod(dexPathList, "makePathElements", List.class);

final Object[] elements = (Object[]) makeElements.invoke(dexPathList, newLibDirs);

final Field nativeLibraryPathElements = ShareReflectUtil.findField(dexPathList, "nativeLibraryPathElements");
nativeLibraryPathElements.set(dexPathList, elements);