android APK瘦身全面总结——如何从32.6M到13.6M

版权声明:本文出自马云飞的博客,转载必须注明出处。 https://blog.csdn.net/sw950729/article/details/64919051

前言

之前我简单介绍了关于svg图片瘦身的问题,在公司,瘦身这个问题是我提出来的,所以这锅我背了。公司项目是32.6M,我给自己的要求就是低于20M。上周花了一个星期瘦身,至于为什么花了一周,主要是svg适配问题我被搞蒙蔽了。然后发现还要改大量代码,想想也就算了,又换了另一种瘦身方法。
很多人是因为这标题而来的,怎么可能,32.6M的居然可以变成13.6M。下面容我慢慢道来。

APK结构介绍

这里写图片描述

classes.dex

classes.dex是Java源码编译后生成的java字节码文件。但由于Android使用的dalvik虚拟机与标准的java虚拟机是不兼容的,dex文件与class文件相比,不论是文件结构还是opcode都不一样。目前常见的java反编译工具都不能处理dex文件。Android模拟器中提供了一个dex文件的反编译工具,dexdump。用法为首先启动Android模拟器,把要查看的dex文件用adb push上传的模拟器中,然后通过adb shell登录,找到要查看的dex文件,执行dexdump xxx.dex。另,有人介绍到Dedexer是目前在网上能找到的唯一一个反编译dex文件的开源工具,需要自己编译源代码。

clases2.dex

同上,上面的是对你的java文件的编译,这个是对你所导入的jar文件的编译。

resources.arsc

编译后的二进制资源文件

AndroidMainfest.xml

该文件是每个应用都必须定义和包含的,它描述了应用的名字、版本、权限、引用的库文件等等信息,如要把apk上传到Google Market上,也要对这个xml做一些配置。

assets

assets目录可以存放一些配置文件(比如webview本地资源、图片资源等等),这些文件的内容在程序运行过程中可以通过相关的API获得。

lib

lib目录下的子目录armeabi存放的是一些so文件。这个地方多讲几句,都是在开发过程中摸索出来的。eclipse在打包的时候会根据文件名的命名规则(lib**.so)去打包so文件,开头和结尾必须分别为“lib”和“.so”,否则是不会打包到apk文件中的。其他非eclipse开发环境没有测试过。如果你是用SDK和NDK开发的话,这部分很重要,甚至可以通过把一些不是so文件的文件通过改名打包到apk中,具体能干些什么那就看你想干什么了!

META-INF

META-INF目录下存放的是签名信息,用来保证apk包的完整性和系统的安全。

Res目录

这是我们存放xml drawable string color等等一些资源文件。

32.6M——13.6M

首先,我先声明下,不然我怕会被打,目前13.6M的还在测试中,因为机型问题,目前没法测试。现在稳定包的大小是在19.8M——20.4M。

混淆和去除无用资源

在gradle使用minifyEnabled进行Proguard混淆的配置,可大大减小APP大小
这里写图片描述

删除无用图片资源

我们公司项目到现在逸代了2年了。可想而知,代码的冗余太多了。版本更新会导致很多资源用不到,然后依旧存在包中。这事我是交给老大的做的,毕竟项目他最熟。于是乎删了差不多100多张图片。因为做了图片适配。所以删除的图片资源差不多是在400张的样子。这样。我们的app包从32.6M变成了26.8M。记得刚打包测试的时候,测试经理来个句。你们这包不对啊,怎么少了6、7M。然后就回了是正常的,说我这边搞完差不多会在20M左右。测试经理:什么?在瘦个20M。这么夸张。我:……..好了,不扯了,跑题了。

删除无用resource资源

这个和上面的肯定不一样的。我这边主要还是指xml。首先,我们需要点击Analyze——>Run Inspection by Name…
这里写图片描述
继续输入:unused resource
这里写图片描述
直接点ok,然后等待:
这里写图片描述
看来公司项目还能少个300k~。你们对比着你们的项目一个个的删就行了。

图片瘦身之熊猫大法

前面我也说了。用svg适配改的代码量太大了。于是乎我转用了熊猫瘦身,也就是tinypng。官方网站:https://tinypng.com。下面我从官网给大家介绍下tinypng:

TinyPNG有什么作用?

TinyPNG使用智能有损压缩技术来减小 PNG文件的文件大小。通过选择性地减少图像中的颜色数量,需要较少的字节来存储数据。效果几乎不可见,但它使文件大小有很大的差别!

为什么要使用TinyPNG?

PNG是有用的,因为它是唯一广泛支持的格式,可以存储部分透明的图像。格式使用压缩,但是文件仍然可能很大。使用TinyPNG缩小您的应用程序和网站的图像。它将使用更少的带宽和更快的加载。

它是如何工作的?

当您上传PNG(便携式网络图形)文件时,图像中的相似颜色会合并。这种技术被称为“量化”。通过减少颜色数量,24位PNG文件可以转换为更小的8位索引彩色图像。所有不必要的元数据也会被删除。结果:更好的PNG文件100%支持透明度。有你的蛋糕,吃它了!

它支持到处吗?

TinyPNG生成的文件在所有现代浏览器(包括移动设备)上完美显示。仍然需要支持Internet Explorer 6?它通常忽略PNG透明度并显示实心背景颜色。使用TinyPNG的背景变得透明了。二进制透明度没有任何解决方法!

你为什么创建Tinypng?

我们经常使用PNG图像,但对加载时间感到失望。我们创建TinyPNG在我们的使命,使我们自己的网站更快,更有趣的使用最好的压缩。在2014年,我们添加了JPEG图像的智能压缩,并在2016年,我们添加了对动画PNG的支持。

使用方法

这里写图片描述
我们看到官网的介绍,在这边上传你的jpg或者png 一次最多20张,每张最大5MB。接下来我们随便来个测试:
这里写图片描述
从1.4M变成570k。缩了60%。可想而知,熊猫的强大。想要一次上传全部,这tm就尴尬了。一年25美元。你们可以让你们的UI给你们图片的时候就用Tinypng压缩在发过来。不过有的公司就给你个设计稿。那就得自己亲自下手咯~

熊猫大法VS SVG大法

我对比了熊猫和svg的压缩,前者app’大小是在20.4M,后者是在19.8M。下面上图给你们对比下:
这里写图片描述

19.8M——13.6M

前面我也说了,这个目前还在测试机型。所以稳定性还没保证。先说说是如何做的把。我们公司项目用到了百度地图SDK。所有用到了so库。
这里写图片描述
当然我这边只是部分。下面我是搜到了一些关于这些so库的介绍:

mips、armeabi、armeabi-v7a和x86到底是什么

mips:MIPS是世界上很流行的一种RISC处理器。MIPS的意思是“无内部互锁流水级的微处理器”(Microprocessor without interlocked
piped stages),

其机制是尽量利用软件办法避免流水线中的数据相关问题。

armeabi:默认选项,将创建以基于
ARM* v5TE 的设备为目标的库。 具有这种目标的浮点运算使用软件浮点运算。 使用此 ABI (二进制接口)

创建的二进制代码将可以在所有 ARM* 设备上运行。所以armeabi通用性很强。但是速度慢

armeabi-v7a:创建支持基于
ARM* v7 的设备的库,并将使用硬件 FPU 指令。armeabi-v7a是针对有浮点运算或高级扩展功能的arm v7 cpu。

x86:支持基于硬件的浮点运算的
IA-32 指令集。x86是可以兼容armeabi平台运行的,无论是armeabi-v7a还是armeabi,同时带来的也是性能上的损耗,

另外需要指出的是,打包出的x86的so,总会比armeabi平台的体积更小。

小结

如果项目只包含了 armeabi,那么在所有Android设备都可以运行;
如果项目只包含了 armeabi-v7a,除armeabi架构的设备外都可以运行;

如果项目只包含了 x86,那么armeabi架构和armeabi-v7a的Android设备是无法运行的; 如果同时包含了 armeabi, armeabi-v7a和x86,

所有设备都可以运行,程序在运行的时候去加载不同平台对应的so,这是较为完美的一种解决方案,同时也会导致包变大。

所以,这个还是需要根据用户的机型来判断,目测我这边还在测试中,如果没问题。大小基本就在13.6M左右了。

总结

我们需要对APP瘦身的时候需要了解他的结构,就像我第一次做瘦身的时候,虽然解决了,不过对各种问题都是属于一脸蒙蔽的情况。所以,我们需要要了解apk包下每个文件都是干嘛的,做了什么,是否有用。只要你用心去做,就一定可以解决。就像我当初给自己的目标是小于20M一样。虽然现在和20M差不多。不过如果那边测试可以通过。那便是13.6M而不是20M。希望我的方法能帮助到你们。欢迎讨论~~~

阅读更多

扫码向博主提问

我就是马云飞

博客专家

非学,无以致疑;非问,无以广识
  • 擅长领域:
  • Android
去开通我的Chat快问
换一批

没有更多推荐了,返回首页