android app Lose Weight

关于App瘦身市面上已经有了很多方法实现，值得参考和借鉴，这里记录自己的记录一些瘦身的一些方法。

一、图片资源处理

• 图片只要xxhdpi

基于数据分析，绝大多数用户的设备分辨率都是2x、3x，在切图方面只选取xxhdpi一套图，通过在不同分辨率的机器上测试，UI效果以及内存开销都可以接受

• 切图技巧

大尺寸的切图，可考虑分切成多个小图片不需要alpha通道的图片，可以考虑使用jpg如果
minsdk为4.2.1+，可以考虑把png全部换成webp；低版本可以通过第三方webp解码lib使用

• 图片压缩

切图统一压缩，以防万一，在release打包的时候，再一次性压缩。压缩工具可以选取TinyPng、ImageMagick

• SVG/Vector Drawable

自Lollipop开始，Android已经支持VectorDrawable和AnimatedVectorDrawable，这个通过xml文本file完成原来切图png的功能，切图的工作基本就被托管了Lollipop以下，更新你的support library到23.2，VectorDrawableCompat已经可以兼容到api7了，AnimatedVectorDrawableCompat兼容到api11

二、Lint删除冗余资源

在 Android Studio中

Analyze -> Run Inspection by Name

Unused resources    Unused declaration      

可以在android gradle plugin 开启shrinkResources

三、微信资源压缩

有同学会有疑问，res混淆和APP瘦身有什么关系呢？这就需要大家对Android中资源的查找有
一定的了解，code通过R文件中的常量值访问资源，但是是如何映射到具体的资源文件上的呢？
这里就需要介绍resources.arsc，简单理解这是一个二进制文件，负责存储res资源的映射关
系。如果我们精简资源的路径，如把res/drawable-xxhdpi/hello.png转为 a/z/p.png，这样的话resources.arsc中存储的信息量就会变少，对应的体积就会缩小。目前这
种思路有开源的方案，可参考AndResGuard

四、jniLibs

根据业务面向的用户及设备，可考虑移除mips、x86平台的so64位的cpu会兼容32位，可以考
虑不保留armeabi-64

主流的arm架构有armv5、armv7、armv8，而它们是向后兼容的。在计算性能可接受的情况
下，只保留armeabi一个；armv7加了FPU，大大提升了浮点运算的效率，必要时也可放入
armeabi，在使用的时候手动去基于cpu abi手动load

应用市场升级安装，我们无法把控具体升级的机器cpu abi。但是如果APP内升级的话，我们可以通过ABIs Splits打出多个apk升级包，基于不同的abi分发不同的最新apk

如果so文件体积比较大的情况下，可不打入apk中，后面通过在线加载后再手动load。一个比较典型的场景就是集成自定义WebView的时候，内核so的体积很大，高达10MB+，这个时候WIFI在线load就是个不错的方案

优化native code。native code会直接影响so的大小，所以从根源上做努力很有必要，比如Do not use Exceptions and RTTI。具体参考Link

五、library

debug依赖的lib，统一在release时不打进APK，或者依赖的lib提供一套空实现大而全的
Library的引入有谨慎，guava这样的库就算了。如果你只用到一小部分功能，可以考虑自己做
个抽取，或者替换为一个更精小的lib时刻关注library的依赖关系，别一个小lib直接或间接
的依赖着一个超大的在重构过程中，记得check下是否有可以删除的lib

六、proguard

Proguard是编译时对java代码进行压缩，混淆，优化，预编译等操作的集成化工具。达到删除冗余，增加安全防护，减小大小的功效。

参考 Gradle 插件用户指南

---

感谢以下博主：

1.我是如何将apk砍掉6M的

2.安装包立减1M–微信Android资源混淆打包工具

3.android APP 瘦身