先说下前言,为什么要这样处理。随着项目的越来越多丰富功能,打包出来的apk体积日益变大,不说打包耗时、编译耗时,发布到应用市场,用户下载流量多、而且手机空间那么有限。用户不满意,咱们就要进行改变呗,没有体验,就没有用户。
我先贴一张图,演示项目的apk(没有调整前):
请记住现在的44MB。
从何下手?
物理上来说,我们会先想到资源文件,也就是图片之类。正常项目里,我们为了适配尺寸屏幕,会创建drawable-xxxhdpi、drawable-xhdpi、drawable-xhdpi等几个目录,放置对应图片。
还有所谓的资产文件 assets,经常放一些例如 json文件 txt font字体文件 等。
最后一个点,项目里经常需要用到各种不同的第三方,有jar aar 在线maven等。
那么,我们是否可以再这里下手?
具体操作:
1:图片,我们放进去前,可以进行二次压缩处理,达到一定减小体积情况,我常用的网站是:
其实不考虑全面情况,只保留drawable-xxxhdpi、drawable-xhdpi这两个也差不多了,毕竟高分辨率向下不会差到哪里去,看个人
2:assets 非必要的话,不要放入,可以存在云端,例如 阿里云的oss 腾讯云等等,在项目启动时候做检验,不存在就做静默下载保存即可
3: 不可避免的jar、aar、maven,先说一点题外话。手机 其实有区分 32位 64位系统的。
32位: armeabi 、armeabi-v7a、x86
64位: arm64-v8a、x86-64
市场上主流基本都是32位手机,所谓高端旗舰机型才会是64位,64位基本向下兼容32位。
言归正传,说了那么多,其实就是想说,一般来说每一个第三方,提供的时候,内部是做了 64、32位手机架构的支持的,所以 会有armeabi 、armeabi-v7a、x86、 arm64-v8a、x86-64等 5个架构的支持,也就是我们常见的 so包。看到这里,我相信大家已经知道接下来要说什么了。没错,设置应用只支持 主流架构就好了。可以预见性的看见,只保留某个架构,其他的不需要,体积肉眼可见的缩小。这里,我只是设置了armeabi-v7a ,大家可以按需设置,如图:
4:配置混淆 ,过滤无用资源
minifyEnabled true // 允许Proguard优化apk大小, 混淆代码
//Zipalign优化 zipAlignEnabled true // 移除无用的resource文件 shrinkResources true
好了,编译打包,发现会明显快了一些,毕竟不需要那么多架构。我直接上图吧
改造前:
改造后:
44mb到19mb的明显对比,很明显吧。
最后,前面说的第一点 ,我的演示项目已经压缩过了,所以就不贴流程了。
第二点 毕竟云链接隐私,大家自行编写自己的下载逻辑即可。
其实我们还可以在多渠道打包时候二次设置abifilter,针对每个品牌市场架构单独调整
也许写的不是那么厉害,也不是那么全,只是自己实现的一点经历