前段时间领导要求将android apk体积下降下来,所以个人就去了解了下这方面的知识。
当一个apk体积过大时,过大的体积导致编译的耗时过长跟用户不愿意去下载,并且版本的更新也会因为体积过大,必须在wifi环境才舍得更新,这样对于新版本的推广是得不偿失的。所以就有了缩减apk的需求。
apk缩减是一件很有意思的事情,相应的方法也有很多:
1.尽量少的依赖第三方sdk
可以通过抽取第三方关键代码达到快速开发的需求。因为你在引入一个第三方sdk的时候,往往会带入很多不必要的功能,并且第三方往往还有内部的依赖,需求功能之外的冗余代码还是蛮多的,所以手动的抽取出关键代码,往往会比较合适,当然,依赖可能造成的其他问题就不在这里一一说明了。
这里做一个小小的示范,如何抽取出关键代码:
抽取代码目标:PullZoomView :是一种可伸缩的view
//直接依赖:
In your build.gradle:
dependencies {
compile 'com.github.frank-zhu:pullzoomview:1.0.0'
}
我们选择另一种做法,直接抽取关键代码,现在我们下载代码, 看他的代码中都有什么
//我们找到我们想要的控件了,那么现在就只需要抽取所需的代码就可以了
单纯的抽取代码,发现有非常多的错误,这个时候不需要考虑什么,只要把这里报错所需的代码全部拷贝过来就可以了。需要什么抽什么
直接抽取类还不够,我们会发现还有如下的styleable中的代码要抽取出来:
我们找到res包中需要的代码拿出来就可以了,如果你没有attrs.xml文件,just to create:
最后 导入就好了
就这样,便直接使用这个功能了,有时候你可能还需要复制一些布局文件,稍微注意一下引用的包名就可以了,这个想必难不倒各位的。
可能这种抽取代码对于一些小项目并没有什么帮助,但是对于一些大的依赖,比如 MPAndroid Chart还是挺有用的,我们并不需要那么多的表格展示,只要抽取我们想要的代码,就可以达到我们的目的了。
2.删除不需要的代码跟没有被引用的图片
项目的长期迭代,往往会有一些图片被替代,不被使用,所以可以通过android studio自带的分析工具lint,进行分析,删除:
进入Android Studio的菜单中选择Analyze->Inspecting Code即可
分析完毕后在Inspection选项卡中会有一份详细的报告,找到Android Lint项目
拉到下面Unused resource这一栏打开,即是未被使用的资源列表,用户可以参照来手动删除资源
还有种方法,但是我并没有去关注这方面会不会带来潜在的风险,需要大家自己去尝试:
3.压缩图片体积
即使向UI要求尽量减小图片的大小,但是UI也会因为自己的考量(图片质量)而不会真正的给出非常小的图片,那么这个时候需要我们手动的去压缩图片,对于这方面,可以通过专门的网站进行批量压缩,比如 TinyPng
图片质量肉眼看不出变化,但是大小减小了72% ,就是这么的神奇
4.混淆apk
混淆也是压缩apk体积的一种,他会将代码进行替换,这种替换往往会减小代码占据的体积,一般可以因此降低两到三兆的体积。混淆需要配置好第三方的proguard-rules.pro 否则会出现功能错误
//在app的build.gradle文件下
buildTypes {
debug {
minifyEnabled false
zipAlignEnabled false
shrinkResources false
signingConfig signingConfigs.debug
}
release {
//混淆
minifyEnabled false
//所以尽可能的减少第三方的使用 也是可以降低混淆的难度
//Zipalign优化
zipAlignEnabled true
// 移除无用的resource文件
shrinkResources false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
}
}
5.优化代码逻辑,减少Assets文件夹内容
这方面根据项目上面的业务来判断,比如公司项目由于用了weex,在assets文件夹里面放置了一些vue文件,某些界面直接用vue文件进行展示。由于想尽可能的压缩apk体积,所以将这一块的逻辑修改,不再直接加载assets文件夹里面的vue文件,而将所有的vue文件放置到服务器中,根据服务器判断是否需要下载这方面的文件到用户的sd卡中,再去加载这方面的文件。这样,再一次的减小了整个apk的体积。
6.丢弃 跟替换某些占据体积较大的依赖。
可以通过分析网站 ,分析整个apk中的大小分布
7.对于一些市场占有率不高的分辨率,请谨慎支持
即有选择性的提供xhdpi,xxhdpi的图片资源。建议优先提供xhdpi的图片,对于mdpi,ldpi与xxxhdpi根据需要提供有差异的部分即可
8.使用webp格式的图片资源
webp格式带来更低的体积,但是有点需要衡量的是,webp图片的解析需要jpg/png将近10倍的时间消耗,并且需要做好适配的问题。
9.用代码代替背景图片
对于一些背景图片,可以直接用selector.xml文件替代,既不会失真,体积又能进一步的减小。
10. .so包的优化
很多第三方会提供所有的.so包支持,但是我们其实并不需要那么多的架构支持,类似于x86和x86_64(都是模拟器)的so是不需要支持,在这方面也可以减少一部分体积开支:
defaultConfig {
ndk {
// 设置支持的SO库架构
abiFilters 'armeabi-v7a'// , 'arm64-v8a', 'armeabi-v7a', 'x86_64', 'x86', 'arm64-v8a'
}
}
11.动态加载技术(插件化)
现在大型互联网移动App很多都采用了动态加载的技术,因为他们的业务需求太大,通过动态加载技术可以将一部分业务模块独立出来,以插件的方式分割出去,这样子主apk的体积就大大减小。当用户安装主apk后,静默的在后台下载插件apk,当用户点击使用到相关的子模块项目时候,动态的加载插件apk。 动态加载技术无疑从根本上减少了apk的体积,但是引入这个技术是有代价的,增加了项目的维护难度和开发难度。所以该技术适用于大型的移动应用,当你的业务大到不分开模块难以高效率开发维护的时候,再考虑动态加载技术吧,否则如果小规模应用,还是老老实实考虑传统的android官方推荐的开发方式。
12.用属性动画 代替帧动画
帧动画是由一系列的图片制作而成的,如果需要适配的话,消耗的资源还是很大的。
13.大神专用:使用较低版本的android api ,以便丢弃support.v4包
参考这篇文章
14.移除枚举
一个枚举能让classes.dex文件增加1–1.4K。枚举的加入会快速增加应用体积。我们可以使用@IntDef注解和Proguard代替枚举,它能提供和枚举一样的类型安全转换。
15.移除国际化
判断项目是否真的需要国际化,毕竟不是所有的app都需要去支持外文的。
android {
defaultConfig {
resConfigs "zh"
}
}
16.利用微信资源压缩打包工具
微信同时利用7z深度压缩,大大减少了安装包体积,同时也增加了逼格,提升了反破解难度。
使用说明:微信资源压缩打包工具使用介绍 技术原理介绍:安装包立减1M–微信Android资源混淆打包工具
参考:
https://yq.aliyun.com/articles/57284?&utm_source=qq
http://blog.csdn.net/u011335851/article/details/52187739
http://www.jianshu.com/p/bd90dee57ad0
http://m.blog.csdn.net/article/details?id=50834617
http://blog.csdn.net/tim_yip/article/details/47022875