性能优化之Apk瘦身

基本瘦身

1.工具（Lint检测代码）

箭头1：全面检测
检测维度：
大牛文章：
https://www.cnblogs.com/andy-songwei/p/7090934.html
http://www.javashuo.com/article/p-vtcbvgwr-nc.html
箭头2：按照具体检测类型lint

2.图片处理：

1.图片压缩
推荐批量压缩（使用插件：TinyPngPlugin）
1、Tools --> TinyPngPlugin
2.用WebP格式进行替换
3.混淆处理 minifyEnabled true
4.资源缩减 shrinkResources true

备注假如有一些资源文件不确定还用不用,也不敢删,或者不确定需求是否会变更,所以先留着,
可以使用shrinkResources来缩减资源

5.无用的 so文件，三方库，二方库，以及重复使用的第三方库的删除和精减

6.为了解决简单功能引入的复杂三方库，尽量只参考他们的实现，避免引入三方库

7.移除未使用的备用资源
defaultConfig { resConfigs(“en”,“zh”,“zh-rCN”) }资源文件同理

defaultConfig { resConfigs(“xxhdpi”,“xxxhdpi”) }

瘦身进阶

1.资源混淆resources.arsc资源混淆

参考AndResGuard

2.ReDex

dex文件是打包中的产物，redex是facebook开源的分包优化方案。可以参考：ReDex。

3.so动态加载

对于so缩减后,so文件占比还是比较大,可以考虑除了首次启动外的so文件做动态下发。也就是插件化的思想，按需加载，但是收益很大的同时，风险也很大，

有很多case需要考虑到，比如下载时机、网络环境、线程进程，加载失败是否有降级策略等等。

可以参考facebook开源的SoLoader。

4.插件化

按需加载，收益越大风险越大，风险同上。

5.原生改用H5或小程序等方案

6.图片网络化

把图片上传到服务器,通过动态下载的方式减少包体积,弊端就是首次加载的时候依赖网络环境,对加载速度,流量需要做一个平衡。图片可以预加载，但是流量消耗是无法避免了，如果比较在意流量指标，需要权衡了。

7.DebugItem

DebugItem 里面主要包含两种信息：

调试的信息。函数的参数变量和所有的局部变量。
排查问题的信息。所有的指令集行号和源文件行号的对应关系。
去除debug信息与行号信息，如果不是极致，不推荐。可以参考支付宝的这篇 支付宝 App 构建优化解析：Android 包大小极致压缩。

8.R Field内联

内联R Field可以解决R Field过多导致MultiDex 65536的问题，而这一步骤对代码瘦身能够起到明显的效果。
参考字节开源的shrink-r-plugin，还有滴滴开源的booster,美团方案

9.图片着色器

针对同图不同色的处理，可以使用tint，比如原本是一个黑色的返回icon，现在另一个页面要用白色了，就不需要两张图了，
而是使用tint来修改为白色即可。

10.减少ENUM的使用

每减少一个ENUM可以减少大约1.0到1.4 KB的大小。

包体积瘦身的思想：

包体积监控

包体积监控应该作为发布流程的一个环节，最好是做到平台化、流程化，否则很难持续，没几个版本包体积又涨上来了。

大致思想：当前版本与上一个版本的包大小做对比，超过200KB需要审批。临时审批需要给出后续优化方案等等。