作者：猩程变 来源：掘金
瘦身原因
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文件进行加载
- 通过插件化插拔的方式进行下发
网友评论