包体积优化-实践

最新公司业务线一个App尝试切换到androidx后，与上期版本相比包大小突然从19.9增加了9M的地址，对照着官方推荐做了一些优化，中间也碰到一些问题，所幸最终将体积减了下来

image.png

webp 不稳定？

注意:由于支持无损和透明的WebP图像只能在Android 4.3和更高版本中使用，所以您的项目必须声明一个minSdkVersion 18或更高版本，以使用Android Studio创建无损或透明的WebP图像。

幸好我们这个app支持的比较新，低版本按例子可以用Xposed Hook，平均能减少76%左右，但发现不可思议一件不可思议的事，尽然有些突然比原图大，目前没看到什么合理解释

image.png

尝试了线上压缩，效果还行

image.png

McImage

看了下源码，顺带学习了下Android Gradle DSL及编译过程，它的功能是在mergeResource 步骤中遍历图片(包括JAR包)压缩然后与原图比较，比原图大就使用原图，有了上面的Webp压缩放大的情况，个人感觉或许会压缩不完全，源码很好读，建议看看

resConfigs "hdpi", "xhdpi", "xxhdpi", "xxxhdpi" 不能用了

这句话的作用是去除不匹配的图片资源，但是新版本该用splits打包，这个应该只在googleplay生效，我自己根据McImage 改了下 不匹配 这几个分辨率删除

关于SO

这个是我们这次优化的重头戏，因为我们部分功能使用了Flutter 包没有引入androidx 前我们包大小20MB，通过常规治理，包括删除无效资源，图片压缩，剔除语言包等减少4M左右，其中flutter生产 so 占 6MB左右，4+6 =10M ，如果刨除这些大约能优化10M～50%

开始前我们将字节 flutter 包体积优化反复读了好几遍，最终实施的时候，和组员一讨论，如果完全将flutter so 动态下载会带来一个风险，一旦so下载失败意味着所有Flutter 模块无法使用，最终只是将flutter做成动态更新 有时间补上

andResGuard ReDex

这里我尝试了下andResGuad，如果仅仅混淆资源大约节省1M左右，使用sevenZip压缩后，能恐怖的达到3.2MB

andResGuad 怎么直接与相关编译task绑定

之前我也是对Gradle 不是怎么了解，直到看相关源码，结合之前的一些练习，是可以实现的，看了下Issue 发现已经有人实现了，我改了下,把下面代码贴到 app下的build.gradle

project.afterEvaluate {
    tasks.matching {
        (it.name.startsWith("assemble"))
    }.each { task ->
        def variant = task.name.replaceAll("assemble","")
        task.finalizedBy("resguard"+variant)
    }
}

白名单 所有使用getIdentifier访问的资源都需要加入白名单。
请使用Umeng_social_sdk的同学特别留意将资源加入白名单，否则会出现Crash。可以在white_list.md查看更多sdk的白名单配置，也欢迎大家PR自己的白名单

另外 不支持androidx.constraintlayout.widget.Group #353

当在使用7zip压缩的APK时，调用AssetManager#list(String path)返回结果的首个元素为空字符串. #162

IconFont