前言
之前我简单介绍了关于 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. 希望我的方法能帮助到你们. 欢迎讨论~~~
最后
如果你看到了这里, 觉得文章写得不错就给个赞呗? 如果你觉得那里值得改进的, 请给我留言. 一定会认真查询, 修正不足. 谢谢.
来源: http://www.jianshu.com/p/f17e9de17e0b