Android 性能优化(七)：APK安装包体积优化

包体积优化重要性

移动 App 特别关注投放转化率指标，而 App 包体积是影响用户新增的重要因素，而 App 的包体积又是影响投放转化率的重要因素。

Google 2016 年公布的研究报告显示，包体积每上升 6MB 就会带来下载转化率降低 1%， 当包体积增大到 100MB 时就会有断崖式的下跌 。对于应用商店，普遍有一个流量自动下载的最大阈值，如 应用宝，下载的app超过100M，用流量下载时，会弹窗提示用户是否继续下载，这对下载转化率影响是比较大的。某淘对新业务超过 1M 要总裁审批，一般在平台组都卡掉了。

• 下载转化率：包体积越小，下载转化率越高；
• 性能影响：安装时间长、占用内存大；

Android Apk结构

lib（主要是so文件）

• 主要集中在三方SDK

依赖SDK不规范：高德地图3D->2D；图片加载库Glide、Fresco重复。

已不用的SDK及时下线：阿里短视频SDK下线获得2M优化空间； 

SDK及时升级：有些SDK会有优化so体积的版本升级，如阿里播放器升级，带来1M收益 ；

• flutter的dart代码

原生能够提供的功能，不用三方库；

已废弃的项目及时移除项目；

dart代码混淆； 

---

asserts：

• flutter资源

存在2X和3X图，仅保留一套即可 ；

图片压缩，在引入图片前进行压缩，或转换webp或SVG格式；

• weex离线包

仅保留核心weex的场景的离线包；

• 表情图片、Json动画

上传到服务器上动态请求下发；

---

res:

• drawable

规范资源图片的位置，仅保留一套图；

对png图片转成webp,webp也可再用tinypng压缩，如果UI不通过，让UI提供压缩图片 ；

使用代码实现View的背景设置；

大图、gif放上传服务器；

• layout

精简删除废弃的layout资源，目前有2327个layout文件；

• 基础数据Json文件

仅保留核心基础数据，其他可做动态下发；

• 废弃资源

定期使用Analyze检查并删除各自模块无用资源；

---

Dex:

三方库、工具库统一，引入新的三方库前，先确认项目中是否存在功能相同库；

无用或下线的功能及时删除；

可以被混淆的代码不要Keep掉，遵照《Android混淆开发规范》；

灰度功能关闭后及时删除相应逻辑及代码；

---

So 压缩

so压缩是减少so文件的单个体积。

gradle打包时会对工程中的so库进行压缩，最终生成apk包的体积会减小。

android:extractNativeLibs="true"

缺点：在apk安装时，系统会再次对压缩后的so文件解压，从而造成安装apk的时间变长。

minSdkVersion >= 23 默认 android:extractNativeLibs= false。

大so动态下发

针对有些so文件压缩后，体积仍然很大，比如占比超过10%的情况，可以选择动态下发。

主要有下面四个步骤：

1. 下载so库
2. 解压so库
3. 校验so库
4. 加载so库

另外，当动态下发的so没有下载、解压、校验、加载完成之前，如果用户进入到了相关的业务场景，需要做好对应的兜底机制。比如在某场景中，使用了 opencv 库来做图片的二维码识别，当so没下载下来时，要识别二维码就会被兜底到 zxing。

---

优化的成绩