阅读 2215

APK瘦身方案大全,尽情享用

看官须知

本文内容不会过于深入,只是对一些常用方案的整理总结

瘦身原因

Apk的大小对于用户是否选择下载应用起着至关重要的影响,也会是成为用户活跃度的原因之一

APK组成

我们都知道apk是由:

    . asserts   
    . lib   
    . res 
    . dex 
    . META-INF    
    . androidManifest   
复制代码

这几个部分构成的。
通常来说我们可以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包可以添加下面这行  
复制代码
三方库处理

在开发过程中,我们因为业务需求,可能会引用很多第三方库,而这些库可能有着相同功能
比如PicassoGlide,这两个库都是图片加载的功能,如果没有特殊要求的话,根据场景的选择任选其一即可。

  • 当然,本着瘦身的原则,我们通常选择一个 包体积更小 的较好。
  • 对于第三方库的管理,通常建议封装一个 统一管理三方库的基础库 ,这样有利于后期库的维护
  • 如果我们需要某个库的某小部分功能,那么建议就是 仅引入所需部分功能代码 即可,加入我们使用了Picasso,但是我们只需要它支持webp功能,那么这时候我们就只引入webp功能就好了 原则就是 能小则小,不用最好
移除无用代码

通常是伴随着业务的不断迭代,业务代码只加不减,还有越来越多的代码不敢删除,这个时候我们就需要都每个页面用户的访问情况进行监测,通常我们可以通过使用埋点技术来对页面的生命周期进行埋点,比如对Activity的onCreate进行埋点,Fragment的构造进行埋点,可以通过类似的手段来分析用户操作行为,这样可以更好进行业务的优化。
随便提一句,使用AOP埋点超好

资源瘦身

冗余资源

1000行代码可能占用5KB的资源,但是100张图片可能就是上百Kb的资源

可见对资源的一个优化是多么的重要,那么就需要删除一些冗余资源,操作如下:

资源文件右键-->Refactor-->Remove Unused Resource

图片处理

关于图片这一块,我们提到的次数是真的超超超多了,本文不对图片处理进行解释,具体对图片的处理请参考Bitmap详解
关于图片,我们可能进行会说到如何进行选择,还有对它进行的压缩处理。
图片有png、jpg和webp这三种格式,png无损,占用的资源是最大的

    png>jpg>webp //  资源从大到小
复制代码

如果没有特殊要求,只考虑占用资源的大小,相信大家应该知道怎么选了。

图片压缩就不过多的说了,推荐tinypngTinyPngPlugin,

资源混淆

没什么好说的,大家看下AndResGuard,主要是将冗长的资源文件路径缩短,从而达到一个节省资源的目的。

SO瘦身

SO,简单的说就是Android上的一个动态链接库,关于SO的操作,请进行JNI相关资料进行查阅

我们都知道,在Android中有7类CPU架构,对应的ABI:

CPU架构 ABI
ARMv5 armeabi
ARMv7 armeabi-v7a
mips64 mips64
arm64-v8a arm64-v8a
x86_64 x86_64
x86 x86
MIPS mips

如果说将这些SO都加载进来,势必会造成APK的体积膨胀,因此需要通过一些手段来解决

SO移除

在build.gradle的defaultConfig配置中添加下面的代码

            ndk {
                abiFilters "armeabi-v7a" //目前流行的armeabi和armeabi-v7a
            }
复制代码

当然这样做,也有缺陷,可能部分用户因为无法加载so库,从而导致用户体验差

如果说我们需要完全的支持所有设备机型,那么付出的代价真的太大了,此时我们可能通过动态加载的方式来解决

动态加载SO
  • 将所有的so文件都放到armeabi文件夹下,通过获取用户的CPU架构进行动态加载

  • 可以将需要的so文件上传到服务器,然后先获取用户的CPU架构,再从服务器上下载对应的so文件进行加载

  • 通过插件化插拔的方式就行下发

关于瘦身,零零洒洒的的总结这些了,希望对你有所帮助~~~

关注下面的标签,发现更多相似文章
评论