性能优化之三——包体积优化大战

FullStackDeveloper

已于 2023-02-11 12:50:42 修改

阅读量2.8k

点赞数

分类专栏：性能优化文章标签：包体积优化

于 2022-03-12 20:48:33 首次发布

本文链接：https://blog.csdn.net/FullStackDeveloper/article/details/123440530

版权

性能优化专栏收录该内容

9 篇文章 2 订阅

订阅专栏

在厂商东家的时候，每个版本要求包体积增长不能超过15%,当时的包体积大该是20来M，所以，每次增长的空间在3M左右，这个还好，基本每个版本都能满足
现东家，每期版本发布，超过30K要审批，超过100K要上会特殊申请。
所以，现在每一期做完都要分析包体积增长，这次做的项目分了三期。两期一共增长如下表。所以，如果不做优化，肯定无法发布。

在这里插入图片描述
正如大家知道，只要你的业务量大，体积增长是不可避免的。之前对包体积优化不太想总结研究，原因是市面上所有的战法都是常规战法，平时在开发中，已经去规避，没有太多进阶和极致且实操性的战法。这次去做优化的时候，还是把优化给梳理一遍，做个记录，也为下次使用的便利。

1.优化意义

(1).下载时省流量，
(2).用户好的体验：下载更快，安装更快。

2.分析工具

1.APK Analys

APK Analys是AS自带的APK分析工具，使用比较简单，直接把APK文件拖拽到AS中即可。当然，也可以按照如下路径处理：
Android Studio下 ——> Build——> Analyze app
在这里插入图片描述

2.重要参数诠释

1.APK SIZE:又称（raw size）apk未压缩后的大小,也是在磁盘的大小。
2.Download SIZE：从应用商场下载的大小，就是实际消耗流量的大小，一般以这个大小作为包体积大小衡量。由此来看，应用商店还是把我们包体积给压缩挺多的！
3.和基准包对比，可以精确那些增长量，但是，是基于解压后的Size对比！Raw Size的增量和Download Size增量一致！
4.版本号
5.版本码
6.对应drawable目录
对于以上的目录都可以查看对应的文件，比如AndroidManifest.xml、查看代码和资源实体。
在这里插入图片描述

3.编包流程

在这里插入图片描述
进阶的战法都是从编包梳理处理的，所以，把编包图放出阿里。

4.优化战法

1.常规战法

1.清理无用资源

1.Lint工具

1.what is this

Android Studio 提供一个名为Lint的静态代码扫描工具，可以发现并纠正代码结构中的质量问题，而无需实际执行该应用，也不必编写测试用例。
Lint 工具可检查您的 Android 项目源文件是否包含潜在错误，以及在正确性、安全性、性能、易用性、便利性和国际化方面是否需要优化改进。

2.how to deal with it
(1).在 Android 视图中，打开您的项目，然后选择要分析的项目、文件夹或文件。
(2).从菜单栏中，依次选择 Analyze > Inspect Code。
(3).在 Specify Inspection Scope 对话框中，查看设置

Specify Inspection Scope 对话框中显示的选项组合因您选择的是项目、文件夹还是文件而异。您可以通过选中其他某个单选按钮来更改要检查的内容。您可以在 Specify Inspection Scope 对话框中查看 Specify Inspection Scope 对话框中可能显示的所有字段的说明。

(4).点击 OK 以运行检查。图 4 显示了通过运行 Inspect Code 所生成的 lint 及其他 IDE 检查结果：
在这里插入图片描述

3.operate items
1.检测没有用的布局并且删除
2.把未使用到的资源删除
3.建议String.xml有一些没有用到的字符也删除掉

2.开启shrinkResources去除无用资源

在build.gradle 里面配置shrinkResources true，在打包的时候会自动清除掉无用的资源，但经过实验发现打出的包并不会，而是会把部分无用资源用更小的东西代替掉。注意，这里的“无用”是指调用图片的所有父级函数最终是废弃代码，而shrinkResources true 只能去除没有任何父函数调用的情况.

   android {
        buildTypes {
            release {
                shrinkResources true
            }
        }
    }

3.删除无用的语言资源

大部分应用其实并不需要支持几十种语言的国际化支持。比如我们只是保存中文支持。

    android {
        defaultConfig {
            resConfigs "zh"
        }
    }

4.清理第三方库中冗余代码

对于第三方库，可能我们只是用到库中的一个功能，那么我们就可以导入源码，并且删除无关的代码，来减小体积。

2.图片资源优化

图片资源相对来说是比较占空间的，也是重点优化对象。
分为减、压、换四大杀手锏！

（减）1.只使用一套适配图

其实现在基本上都是使用一套二倍图进行适配。保留xhdpi文件夹。如果还是有二倍、三倍图，去掉一个文件夹，收获很大。

（减）2.着色方案

项目中或多或少都会使用selector文件。而这种图片往往只是颜色不同，通过着色方案我们能大大减轻这种工作量，降低这种文件。

借助于android support库可实现一个全版本号兼容的着色方案。參考代码：DrawableLess.java

BitmapDrawable优化：
原始图：
在这里插入图片描述

//着色处理
ImageView imageView = (ImageView) findViewById(R.id.image_1);
final Drawable originalBitmapDrawable = getResources().getDrawable(R.drawable.icon).mutate();
imageView.setImageDrawable(tintDrawable(originalBitmapDrawable, ColorStateList.valueOf(Color.MAGENTA)));

着色效果：

在这里插入图片描述

（换）3.webp万能替换

webp是谷歌官方推荐的图片格式，空间占用优化不少。
WebP格式，谷歌（google）开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。据谷歌官方的介绍：
WebP 无损压缩的图片可以比同样大小的 PNG 小 26%；
WebP 有损压缩的图片可以比同样大小的 JPEG 小 25-34%；
WebP 支持无损的透明图层通道，代价只需增加 22% 的字节存储空间；
WebP 有损透明图像可以比同样大小的 PNG 图像小3倍。

（换）4.svg动态图

矢量图是由点与线组成,和位图不一样,它再放大也能保持清晰度，而且使用矢量图比位图设计方案能节约30～40%的空间，现在谷歌一直在强调扁平化方式，矢量图可很好的契合该设计理念。
占用存储空间小
无极拉伸不会出现锯齿，可以照顾不同尺寸的机型
Android Studio自带很多资源
webp支持动态图，所以，动态图可以使用svg或者webp动态。

（换）5.shape图

特别是在扁平化盛行的当下，很多纯色的渐变的圆角的图片都可以用shape实现，代码灵活可控，省去了大量的背景图片。

//扩大圆点画图方案
<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="oval">
    <solid android:color="@color/color" />
    <size
        android:width="20dp"
        android:height="20dp" />
    <stroke
        android:width="14dp"
        android:color="@android:color/transparent" />
</shape>

3.lib库优化

只支持主流架构，比如arm,对于mips和x86架构可以考虑不支持。

4.assets/raw资源

1.对于默认必须有配置文件，使用7zip压缩，使用时解压。
2.对于非默认的动态配置下发，然后解压。

5.gradle配置

1.代码混淆

在gradle使用minifyEnabled进行Proguard混淆的配置.

  android {
        buildTypes {
            release {
                minifyEnabled true
            }
        }
    }

代码混淆减包体积原理：
1）可以删除注释和不用的代码。
2）将java文件名改成短名
3）将方法名改成短名

2.进阶战法

1.字节码优化

1.facebook-Redex

redex是facebook发布的一款android字节码的优化工具。
Facebook 通过线上及线下测试，启动速度提升 20% 以上，Dex 大小减小 25%，对于内存较小的机型启动速度的优化效果尤其明显。

redex的接入成本比较高，这个成本包括对现有打包流程和热修复流程的影响，上线后的稳定性，以及问题排查的难易程度。接入成本对比优化结果看，接入是低性价比的，所以目前是放弃直接接入到项目中使用的。
redex虽然接入到成熟的app中有很多坑，但依然是一个很好的开源项目。通过调研redex，发现其中单个的优化项可以再去发掘应用，比如Interdex优化项，就可以在项目打包编译的过程中，修改dex分包逻辑，把app冷启动时需要加载的类，放到主dex中。