简介
上一章我们介绍Dex的优化方案，本章主要介绍资源文件的优化方案。
阿里某淘Android体积优化方案(上)
1 无用资源移除。
- 使用Android Studio Lint Remove Unused Resource 工具扫描无用图片和xml资源。
- 打包后的apk可以使用ApkChecker进行扫描每个模块文件的大小、重复文件、以及可以优化的内容。开源ApkChecker
- 使用 gradle shrinkResources true属性，这里shrinkResources属性的作用并不大，因为在扫描无用资源过程中， 系统为了避免使用getIdentifier过程找不到资源，所以在清除资源的时候条件判断非常严格，会判断潜在的反射调用，经过测试，这个功能比较鸡肋，不能完全依赖于shrinkResources帮忙删除无用资源。
2 图片压缩
- 对于纯色图片使用VectorDrawable来实现。
- 网上大量的资料介绍webp格式的图片大小优于png，通过大量数据来看其实并不是，有些图片使用tinypng(png8)压缩后转为webp图片反而更大了，主要还是需要看图片的色彩丰富度，由于没办法通过规律判断具体那种格式的图片最优，我们采取的方案是先将所有的图片png压缩，再尝试png转webp，如果webp更小则采用。这里需要注意webp格式4.0+才支持，对于包含透明度的4.2+才支持。开源pngquant、 cwebp、McImage
3 适配资源
我们需要 根据 App 目前所支持的语言版本去选用合适的语言资源，例如使用了 AppCompat，如果不做任何配置的话，最终 APK 包中会包含 AppCompat 中所有已翻译语言字符串，无论应用的其余部分是否翻译为同一语言。对此，我们可以 通过 resConfig 来配置使用哪些语言，从而让构建工具移除指定语言之外的所有资源。同理，也可以使用 resConfigs 去配置你应用需要的图片资源文件类代码如下所示：
resConfigs "zh"
支持特定的分辨率。现在大部分手机都是1080p，对应的xxhdpi的资源，所以我们只支持xxhdpi一套资源即可。
开源工具booster-task-resource-deredundancy
4 AndResGuard资源优化和压缩
4.1 arsc文件优化
1 arsc文件它记录了资源文件id对应的名称与路径，可以看到图中res/drawable的字样，开启优化混淆成短路径 res/s/a，可以减少文件的大小。坑：因为混淆资源路径，所以使用getIdentifier的方法是获取不到资源的。这里需要配置白名单的方式不混淆路径。
2 zip文件压缩有deflate和stored两种方式，stored方式的文件是不会被压缩的，可以看到arsc文件以及png图片采用的是stored模式。如果文件采用deflate模式意味着AssetManager读取的时候需要解压。
- 对.png、.jpg强制压缩，但是的确普遍压缩率在3%-5%，收益不是特别高；
- 假若你的resources.arsc小于1M，可以对它进行压缩，这边可压缩50-70%。需要注意的是，如果你的resources.arsc是压缩的，程序需要运行时把它解压读到内存，影响启动速度并会增大运行内存；对于Android 9以上已经不支持arsc文件压缩，否则无法安装。
4.2 7zip压缩
7z压缩算法号称优化了字典，完全兼容zip，使用7zip的最大压缩模式比传统zip方式的确有所提升。对于生成的apk重用7zip进行压缩，APK 的 整体压缩率可以提升 3% 左右。
此外，抖音 Android 团队还开源了针对于海外市场 App Bundle APK 的 AabResGuard 资源混淆工具。
5 SO文件优化
5.1 支持特定架构
Android 目前一共 支持7种不同类型的 CPU 架构，比如常见的 armeabi、armeabi-v7a、X86 等等。对应架构的 CPU 它的执行效率是最高的，但是这样会导致 在 lib 目录下会多存放了各个平台架构的 So 文件，所以 App 的体积自然也就更大了。
因此，我们就需要对 lib 目录进行缩减，我们 在 build.gradle 中配置这个 abiFiliters 去设置 App 支持的 So 架构，其配置代码如下所示：
defaultConfig {
ndk {
abiFilters "armeabi"
}
}
5.2 SO动态加载
分析业务场景，部分非重要的业务场景可实现so动态下载。
初始正式版本我们直接对SO文件做上传下载，下载成功率在95%，错误主要集中在网络错误。新版本对so进行zip压缩再上传，下载体积减少一半，下载成功率从95.8%提示到98.0%。
下方是整体的设计图，配合打包平台实现so整体的管理，将业务的侵入降到最低。
5.3 SO压缩
鉴于动态下载成功率无法达到理想状态，对于某些重要场景希望成功率要求高，我们调研了Facebook APP，发现他们的app so异常的小。我们调研了他们的压缩算法，发现使用了非标准的zip算法。最终我们落地后压缩so方案的so加载失败率只有万分之一。
| 压缩前大小 | 压缩后大小 | 压缩比 | 压缩速度 | 解压速度 | |
|---|---|---|---|---|---|
| zip | 35999380 | 18769510 | 1.92 | - | - |
| zstd-level22 | 35999380 | 13885561 | 2.59 | 1.14MB/S | 113.67MB/S |
| zstd-level19 | 35999380 | 14180497 | 2.54 | 1.47MB/S | 119.62MB/S |
| xz-level9 | 35999380 | 11412072 | 3.15 | 1.70MB/S | 11.76MB/S |
| xz-level9-block2 | 35999380 | 11679984 | 3.08 | 1.70MB/S | 23.29MB/S |
| xz-level9-block4 | 35999380 | 12112080 | 2.97 | 1.79MB/S | 33.93MB/S |
调研后我们针对非核心的so在编译期做so压缩，运行时解压后加载。
SO加载
- So加载我们分析有两种模式、一种是通过打包全局插桩、将System.loadLibrary全部替换成自己的方法，解压后通过System.load方式加载文件，但是这种方式有个缺点就是对于so有依赖的情况下比较难处理。
- 对于解压后的避免使用System.load()的方法，我们使用nativeLibraryPath注入的方式，这种方案使用也较为普遍、在插件化及热修复的方案随处可见。
System.loadLibrary()流程
要想知道如何进行nativeLibraryPath注入，我们必须了解loadLibrary的整个流程。
在我们调用了System.loadLibrary()之后，实际上是进入了Runtime的loadLibrary0()方法中：
// System.java
@CallerSensitive
public static void loadLibrary(String libname) {
Runtime.getRuntime().loadLibrary0(VMStack.getCallingClassLoader(), libname);
}
// Runtime.java
synchronized void loadLibrary0(ClassLoader loader, String libname) {
if (libname.indexOf((int)File.separatorChar) != -1) {
throw new UnsatisfiedLinkError(
"Directory separator should not appear in library name: " + libname);
}
String libraryName = libname;
if (loader != null) {
String filename = loader.findLibrary(libraryName);
if (filename == null) {
// It's not necessarily true that the ClassLoader used
// System.mapLibraryName, but the default setup does, and it's
// misleading to say we didn't find "libMyLibrary.so" when we
// actually searched for "liblibMyLibrary.so.so".
throw new UnsatisfiedLinkError(loader + " couldn't find "" +
System.mapLibraryName(libraryName) + """);
}
String error = nativeLoad(filename, loader);
if (error != null) {
throw new UnsatisfiedLinkError(error);
}
return;
}
// ...
}
这里的VMStack.getCallingClassLoader()通常情况下是调用者的ClassLoader，即PathClassLoader，而findLibrary()方法的实现存在于BaseDexClassLoader中
// BaseDexClassLoader.java
@Override
public String findLibrary(String name) {
return pathList.findLibrary(name);
}
从而进入了DexPathList的实现
// DexPathList.java
public String findLibrary(String libraryName) {
String fileName = System.mapLibraryName(libraryName);
for (Element element : nativeLibraryPathElements) {
String path = element.findNativeLibrary(fileName);
if (path != null) {
return path;
}
}
return null;
}
因此想要我们解压的so也能是由System.loadLibrary()加载的话，则我们需要在nativeLibraryPathElements中加入我们解压完后的路径。
Redex
Redex中也介绍了多种优化方案，但是从功能上看和proguard的部分功能是重复的，经过数据对比，不开启proguard优化效果在5%左右，开启proguard优化模式后dex的优化效果在1%以下。
然后还需要解决redex工程化的问题、dex优化后crash堆栈对不上的问题，整体ROI不高。
建立监控
建立合理的流程规范MR合入，在开发期解决问题。
总结
整体优化下来，项目App最终整体从60M减少到35M，在快速发展中也遇到了大量的业务集成，算上其中的业务增量总共减少30M，在核心链路使用flutter的项目中拿到这个结果实属不易。
在没有建立合理的流程和机制过程前各种问题接踵而至，各种资源新增不规范，好不容易的缩包被新增业务抵消，在后续我们建立合理的规范，形成责任制管理，让开发形成主观意识，实行管控流程，包大小长期收获正向效果。
从我们做的实验来看，优化后转化率在4g情况提升2.5%。
