关于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代码进行压缩,混淆,优化,预编译等操作的集成化工具。达到删除冗余,增加安全防护,减小大小的功效。
感谢以下博主: