APK 瘦身这也算是老生长谈的东西了，但是想做好很难，属于知道但是基本达不到的东西，我们最多缓解一下罢了
想瘦身，首先我们总得知道哪里胖吧，于是 google 提供了 Anazyle APK工具，可以分析 APK 文件，看各个部分占据的大小，这样我们好有的放矢
APK 瘦身实践参考如下：
Anazyle APK 工具
Anazyle APK工具是 studio 自带的，使用起来很简单
首先我们需要打一个 apk 包，这里注意用于安装的apk(平时 run 打出来的包) 包不行，要专门打一个用于分析的 apk 包，那么这个包怎么打呢，使用 studio 中build工具栏中Build APK 命令
Snip20170907_6.png
这样我们就得到了一个可以用来分析的 apk 了，还是studio 中build工具栏，其中的 Anazyle APK 命令，然后使用系统默认选中的 apk 包
Snip20170907_7.png
然手点击 ok 就开始进行 apk 包分析了
Snip20170907_8.png
这里是我公司里的项目 apk 分析结果，可以 lib 的大小占了 apk 包的一半。
Snip20170907_9.png
分析结果图中，左边的大小，非打 apk 包时代码的绝对大小，右边的打 apk 包之后，占据 apk 包的比例和代码的大小。
里面的文件夹都是可以点开的，点开 res 目录后，图片都是按大小依次排列的，分方便我们查询哪些图片需要压缩，或是替换成 webp 格式，一般大于30K 的图片都是需要处理的。另外右上角的 copmare with 可以对比2个 apk 包中大小差异
瘦身思路
看上面，一般占据 APK 包最多的就是图片和第三方 SDK ，jar，so 了，总结一下来源就是静态 png 图片，开源 SDK，第三方集成功能
1. png 图片
我们最能解决的就是 png 了，处理思路如下：
* 减少 png 图片数量
* 压缩 png
* png 转 webp 再压缩
* SVG 矢量图
在减少 png 图片数量这块，我们可以只做 xhdpi(720),xxhdpi(1080) 的适配，其他的没必要，这样图片的数量就少很多了，甚至极端的我们只对 xxhdpi(1080) 适配，不过这样会加大系统压缩图片的操作，会曾加页面显示的耗时
另一个就是启动页的配图了，启动页配图一般都是做 720 大图，都是 M 起步的，我们能用 layer-list 拼的就拼一张图出来，也能节省很多空间，我在 APP 优化 - app 启动优化 里面有过讨论
关于压缩 png 这块，AS 打包时会对 png 进行压缩的，所以我们对 png 压缩之后，打出来的包没有我们预想的瘦身值多，比如我们 压缩 png 减少了 1.8M 的体积，但是打包之后只少了 400K，所以单靠 压缩 png 是行不通的
webp 这块，android 4.0 系统就可以支持了，但是 IOS 好像有些问题，需要沟通。据说 BAT 都没有在静态图片资源里用 webp ，webp 压缩会对图像造成较多损失，一般多用在后台提供的图片上
png 转 webp 可以看：
SVG 这块的话，android 5.0 能完美支持，4.X 做兼容也可以上，一般在项目中不是很复杂的图可以自己用 shape 画，用 .9，也可以用 SVG ，在能保证图片宽高比例的全体下， SVG 可以设置的很小，比如宽高 = 2dp，这样占用的内存非常小，自身体积也是才几 K
SVG ，4.X 的兼容可以看：
2. 开源 SDK
这个一般没啥可以优化的，只有一点，你要是很 NB ,你依赖的开源 SDK 又非常打， 你可以 copy 代码，把比不用的删除，网上只有及其个别的使用案例，请不要轻易尝试，只是做一个思路
3. 第三方集成功能
这个也没啥可以腾挪的地方，比如地图，so，jar 我们导入 ARM CPU 的包，对于其他 CPU 不做考虑，这样也能节省很多
再有就是利用插件化，在需要的时候把 so 包下发到用户设备，比如音乐 app 的隔阂不同风格的解码 so ，这块也是应用案例很少，范围很窄，没有普遍性
这块可以参考：
4. 减少重复依赖
比如你有 3个module 都依赖了 EventBus， 那你就有3份 EventBus 代码，不过 AS 较新的版本会自动去掉重复依赖，这块涉及到模块化，组件化，想告诉大家从这方面也能有些效果
去除无用资源
删除没有使用的资源，通过 Android Studio 选中项目右键 => Analyze => Run Inspection by Name => 输入 Unused Resuroces
打包时不添加没有使用的资源，在项目的 build.gradle 中配置 shrinkResources true 即可
官方相关文档：
网友评论