目前现状
目前APK体积随着Flutter引入,以及业务增长,包体积逐渐从年初的30M左右增长到现在的>60M。
-
以下列举了各个版本的体积状况
-
对APK解压,包中大致资源如下:
- 可以看到40.8%的体积占比在lib中,这是项目中所有.so库集合,约为23.4M。
- res资源文件占比也达到了15.5%,约为9.6M。
- assets为项目中主动加入的一些lottie.json,是动画的描述文件,占比约10%,约为6.2M。
存在问题
对上述的APK解压缩文件进行分析,可以看到,.so库与res资源是APK增长的主要原因。
虽然assets也贡献了10%的体积占比,但是由于涉及到业务动画逻辑,暂时没有优化的空间。
优化目标
- 首先我们对lib库进行分析:
- 在Android 系统上,每一个CPU架构对应一个ABI:armeabi,armeabi-v7a,x86,mips,arm64- v8a,mips64,x86_64。
- 默认情况下,为了使APP有更好的兼容性,我们使用 Android Studio 或者命令打包时,会默认支持所有的架构。
- 可以看到我们app引入了v8和v7两种架构来进行机型兼容
arm64-v8a
: 目前主流版本armeabi-v7a
: 一些老旧的手机x86
/x86_64
:x86
架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具,实现对 arm .so 的兼容,再考虑x86
1% 以下的市场占有率,x86 相关的两个 .so 也是可以忽略的
目前手机市场上,x86 / x86_64/armeabi/mips / mips6
的架构,基本可以不不考虑了,它们的占有量应很少很少了,arm64-v8a
作为最新一代架构,应该是目前的主流,armeabi-v7a
只存在少部分老旧手机
- 然后我们发现res文件中也存在一些图片资源较大的情况,可以通过webP格式进行少量优化。
具体体积瘦身目标:
- lib库减少10M左右。
- res文件资源减少1~2M。
- flutter aar包压缩,减少3M左右。(待调研)
总体瘦身约12~15M。
解决思路
一:lib优化
方案一:只适配 armwabi-v7a
筛掉了一部分老旧设备,在性能和兼容二者中比较平衡,但是Google市场上架,目前必须支持arm64-v8。
方案二: 只适配 arm64-v8
优点: 性能最佳,目前各大厂的策略也是如此。
缺点: 只能运行在arm64-v8上,要放弃部分老旧设备用户
综上所以初步打算google市场适配armwabi-v7a,rm64-v8,其他市场只适配 armwabi-v7a。
二:res优化
通过检查图片资源,将还未转化的PNG格式转化为WEBP。
删除已经废弃的资源文件
三:代码检查
检查无用的第三方库,
优化引用方式,进行debug和release引用的区分。
四:flutter包体积压缩
通过自动打包方式适配不同平台,flutter engine的so依赖问题。
优化效果
通过比对,最后优化效果约为13.2M,体积大小在50M左右。