Android开发之APK瘦身之路

最新推荐文章于 2024-08-25 22:18:14 发布

Mr._W

最新推荐文章于 2024-08-25 22:18:14 发布

阅读量237

点赞数 1

分类专栏： Android

本文链接：https://blog.csdn.net/qq_27481249/article/details/103272340

版权

Android 专栏收录该内容

10 篇文章 2 订阅

订阅专栏

啥也不说了，直接进入主题吧

1. 结构分析

首先上传一张瘦身前通过Analyze app分析出来的图片（打开方式：Android Studio下 ——> Build——> Analyze app）：

APK包结构如下：

1. lib/：包含特定于处理器软件层的编译代码。该目录包含了每种平台的子目录，像armeabi，armeabi-v7a， arm64-v8a，x86，x86_64，和mips。大多数情况下我们可以只用一种armeabi-v7a，后面会讲到原因。

2. assets/：包含应用可以使用AssetManager对象检索的应用资源。

3. res/：包含未编译到的资源 resources.arsc,主要有图片资源文件。

4. META-INF/：包含CERT.SF和 CERT.RSA签名文件以及MANIFEST.MF 清单文件。

5. resources.arsc：包含已编译的资源。该文件包含res/values/ 文件夹所有配置中的XML内容。打包工具提取此XML内容，将其编译为二进制格式，并将内容归档。此内容包括语言字符串和样式，以及直接包含在resources.arsc文件中的内容路径，例如布局文件和图像。

6. classes.dex：包含以Dalvik / ART虚拟机可理解的DEX文件格式编译的类。

7. AndroidManifest.xml：包含核心Android清单文件。该文件列出应用程序的名称，版本，访问权限和引用的库文件。该文件使用Android的二进制XML格式。

2.具体操作

1. lib目录处理

1. 修改so配置：

参考资料
so文件的优化：通常我们在使用NDK开发的时候，我们经常会有如下这么一段代码:ndk

ndk {
            //设置支持的so库架构
            abiFilters "armeabi-v7a", "x86", "arm64-v8a", "x86_64", "armeabi"
        }

最后我的修改代码如下：

ndk     {
            //设置支持的so库架构
            abiFilters "armeabi-v7a"
        }

接下来说明这么做的依据：
看上面图分析，armeabi-v7主要不支持ARMv5(1998年诞生)和ARMv6(2001年诞生).目前这两款处理器的手机设备基本不在我公司的适配范围（市场占比太少）。
而许多基于 x86 的设备也可运行 armeabi-v7a 和 armeabi NDK 二进制文件。对于这些设备，主要 ABI 将是 x86，辅助 ABI 是 armeabi-v7a。
最后总结一点：如果适配版本高于4.1版本，可以直接像我上面这样写，当然，如果armeabi-v7a不是设备主要ABI，那么会在性能上造成一定的影响。

2. 重编译so用更小的库代替

相信很多开发者都有这种苦恼，很多第三方我们导入进来只用到其中很小一部分功能，大部分功能都是我们用不上的。这时候我们找到源代码，将我们需要的那部分代码提取出来，重新编译成新的so文件，再导入到我们项目中。

2. res,assets文件大小

1. 手动lint检查，手动删除无用资源

在Android Studio中打开“Analyze” 然后选择"Inspect Code..."，范围选择整个项目，然后点击"OK"。

2. 使用tinypng等图片压缩工具对图片进行压缩。

打开网址，将大图片导入到tinypng，替换之前的图片资源。

3. 大部分图片使用Webp格式代替。

可以给UI提要求，让他们将图片资源设置为Webp格式，这样的话图片资源会小很多。如果想了解更多关于webp,请点击这里webp，当然，如果对图片颜色通道要求不高，可以考虑转jpg,最好用webp,因为效果更佳。

4. 项目中少使用帧动画

一个帧动画几十张图片，再怎么压缩都还是占很大内存比重的。

5. gradle开启shrinkResources

移除无用资源文件，下面是我的配置：

buildTypes {
        release {
           ....
            signingConfig signingConfigs.release
        }
    }

3. chasses.dex

classes.dex中包含了所有的java代码，当你打包时，gradle会将所有模板力的.class文件转换成classes.dex文件，当然，如果方法数超过64K，将要新增其他文件进行存储。可以通过multidexing分多个文件，比如我这里的chasses2.dex。换句话说，就是减少代码量。我们可以通过以下方法来实现：

1. 尽量减少第三方库的引用，这个在上面我们已经做过优化了。

2. 避免使用枚举，这里特别去网上查了一下，具体可以参考下这篇文章Android 中的 Enum 到底占多少内存？该如何用？，得出的结论是，可能几十个枚举的内存占有量才相当一张图片这样子，优化效果也不会特别明显。当然，如果你是个追求极致的人，我不反对你用静态常量替代枚举。

3. 如果你的dex文件太大，检查是否引入了重复功能的第三方库（图片加载库，glide,picasso,fresco,image_loader，如果不是你一个人单独开发完成的很容易出现这种情况），尽量做到一个功能点一个库解决。