优化APK大小

删除不必要的库文件

---

这些天边学安卓边写个小软件，常见的控件基本学完了，软件的大小也慢慢从几兆变成了40多兆。

虽然有个pdf在里面，但是他已经被我压缩到16兆，再怎么着也不会飙到40才对，难道是因为引入了第三方库？开始检查自己的Gradle：肯定不会是Glide跟JSoup，用他的时候软件体积还没这么大；AndroidPdfViewer、NDialog一一排查后也不是然后想起生成APK后会有个分析，不妨就用他分析试试看

看到这个结果的时候脑袋里就明白怎么一回事了，虽然不能明确地道出armeabi-v7a这些代表着什么，但是知道他代表不同的CPU构架。在Android系统上，每一个CPU架构对应一个ABI

ABI	描述
x86_64	64位的平板
x86	平板、模拟器用得比较多
arm64-v8a	ARM v8，64位支持，目前主流的版本
mips	极少用于手机可以忽略（谷歌最新的文档已经不支持了）
armeabi	ARM v5，相当老旧的一个版本，创建的二进制代码将可以在所有 ARM*设备上运行。所以armeabi通用性很强，但缺少对浮点数计算的硬件支持，速度慢
armeabi-v7a	ARM v7，2011年以后生产的大部分Android设备都使用它

如果项目只包含了 armeabi，那么在所有Android设备都可以运行；如果项目只包含了 armeabi-v7a，除armeabi架构的设备外都可以运行；

考虑到目前大部分手机都已经是arm64-v8了，

• 如果只适配armeabi，无疑兼容性最好，除了被淘汰的mips，其他设备都能够支持；

• 只适配armeabi-v7a，较为折中的一个方案，性能和兼容二者中比较平衡

• 只适配 arm64-v8，性能无疑最佳，但是只有较新的手机支持

知道问题在哪，这下就好解决了，在build.gradle中配置ndk

android {
    compileSdkVersion 29
    buildToolsVersion "30.0.2"

    defaultConfig {
        applicationId "com.jack.loveletter"
        minSdkVersion 21
        targetSdkVersion 29
        versionCode 3
        versionName '3.5'
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        ndk {
            abiFilters 'armeabi-v7a'
        }
    }
}

像上面那样配置，只将armeabi-v7这个包下的so库都打包到一个apk

而也有的软件干脆采用分包的方案，如LR，GooglePlay识别设备自动选择版本

splits {
    abi {
        enable true
        reset()
        include 'x86','armabi'
        exclude 'armeabi', 'armeabi-v7a', "arm64-v8a"
        universalApk true
    }
}

include就是包括，exclude就是不包括。包括的配置每一个项都会生成一个apk包。

去除掉无关的库文件，体积一下子小了下来：

而另外一个体积大户就是图片了，对于图片的优化，之前整理了一个文档，也有过工具推荐。