作者:猩程变 来源:掘金
瘦身原因
Apk的大小对于用户是否选择下载应用起着至关重要的影响,也会是成为用户活跃度的原因之一
APK组成
我们都知道apk是由:
. asserts
. lib
. res
. dex
. META-INF
. androidManifest </pre>
这几个部分构成的。 通常来说我们可以AndroidStudio自带的Analyze APK工具进行APK的资源分析进行我们的瘦身工作,关于工具的使用请参考视频 我们的瘦身也是通过分析APK的组成部分后进行操作,注意,重点来了,下面说说我对瘦身方案的理解,拿出你的小本本记录起来吧~
代码瘦身
代码混淆
道在开发过程中往往为了开发方面,我们通常不会开启混淆措施,一旦到了线上后,我们不管为了APK安全还是瘦身,都建议开启混淆措施
开启混淆很简单,在build.gradle文件中配置minifyEnable true即可。
buildTypes {
release {
minifyEnabled true//true开启混淆配置,false关闭
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.duqian_android_keystore
}
}
混淆的具体措施,需要在proguard-rules.pro文件中进行操作。 常见的混淆配置如下:
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-verbose
-ignorewarnings
-dontshrink
-optimizationpasses 5 //指定代码的压缩级别
-dontusemixedcaseclassnames //包明不混合大小写
-dontusemixedcaseclassnames //包明不混合大小写
-dontskipnonpubliclibraryclasses //不去忽略非公共的库类
-dontoptimize //优化 不优化输入的类文件
-keepattributes *Annotation* //保护注解
-keep public class * extends android.app.Fragment // 保持哪些类不被混淆
-keep public class * extends android.support.v4.app.Fragment //如果有引用v4包可以添加下面这行
三方库处理
在开发过程中,我们因为业务需求,可能会引用很多第三方库,而这些库可能有着相同功能 比如Picasso和Glide,这两个库都是图片加载的功能,如果没有特殊要求的话,根据场景的选择任选其一即可。
- 当然,本着瘦身的原则,我们通常选择一个 包体积更小 的较好。
- 对于第三方库的管理,通常建议封装一个 统一管理三方库的基础库 ,这样有利于后期库的维护
- 如果我们需要某个库的某小部分功能,那么建议就是 仅引入所需部分功能代码 即可,加入我们使用了Picasso,但是我们只需要它支持webp功能,那么这时候我们就只引入webp功能就好了 原则就是 能小则小,不用最好
移除无用代码
通常是伴随着业务的不断迭代,业务代码只加不减,还有越来越多的代码不敢删除,这个时候我们就需要对每个页面用户的访问情况进行监测,通常我们可以通过使用埋点技术来对页面的生命周期进行埋点,比如对Activity的onCreate进行埋点,Fragment的构造进行埋点,可以通过类似的手段来分析用户操作行为,这样可以更好进行业务的优化。 随便提一句,使用AOP埋点超好
资源瘦身
冗余资源
1000行代码可能占用5KB的资源,但是100张图片可能就是上百Kb的资源
可见对资源的一个优化是多么的重要,那么就需要删除一些冗余资源,操作如下:
资源文件右键–>Refactor–>Remove Unused Resource
图片处理
关于图片这一块,我们提到的次数是真的超超超多了,本文不对图片处理进行解释,具体对图片的处理请参考Bitmap详解。 关于图片,我们可能进行会说到如何进行选择,还有对它进行的压缩处理。 图片有png、jpg和webp这三种格式,png无损,占用的资源是最大的
png>jpg>webp // 资源从大到小
如果没有特殊要求,只考虑占用资源的大小,相信大家应该知道怎么选了。
图片压缩就不过多的说了,推荐tinypng和TinyPngPlugin,
资源混淆
没什么好说的,大家看下AndResGuard,主要是将冗长的资源文件路径缩短,从而达到一个节省资源的目的。
SO瘦身
SO,简单的说就是Android上的一个动态链接库,关于SO的操作,请进行JNI相关资料进行查阅
我们都知道,在Android中有7类CPU架构,对应的ABI:
如果说将这些SO都加载进来,势必会造成APK的体积膨胀,因此需要通过一些手段来解决
SO移除
在build.gradle的defaultConfig配置中添加下面的代码
ndk {
abiFilters "armeabi-v7a" //目前流行的armeabi和armeabi-v7a
}
当然这样做,也有缺陷,可能部分用户因为无法加载so库,从而导致用户体验差
如果说我们需要完全的支持所有设备机型,那么付出的代价真的太大了,此时我们可能通过动态加载的方式来解决
动态加载SO
- 将所有的so文件都放到armeabi文件夹下,通过获取用户的CPU架构进行动态加载
- 可以将需要的so文件上传到服务器,然后先获取用户的CPU架构,再从服务器上下载对应的so文件进行加载
- 通过插件化插拔的方式进行下发
meabi文件夹下,通过获取用户的CPU架构进行动态加载
- 可以将需要的so文件上传到服务器,然后先获取用户的CPU架构,再从服务器上下载对应的so文件进行加载
- 通过插件化插拔的方式进行下发