Android 应用瘦身,从 18MB 到 12.5MB

标签: android 应用 瘦身 | 发表时间:2017-01-24 09:29 | 作者:d_clock
出处:http://www.diycode.cc/

Hello,大家好,我是Clock。这是我春节前的最后一篇技术分享文章了,在这里提前预祝大家鸡年万事如意,身体健康,新年升职加薪。

开篇语

前阵子老大交给了我一个任务,主要是帮我们开发的直播应用做 Android 端的安装包瘦身,花了大概一周的时间把安装包从 18MB 减小到了 12.5MB。原本完全可以优化到 10MB 之下,但由于其他原因的限制,所以目前阶段只到 12.5MB 为止。在此记录一下优化的思路和用到的工具,方便自己以后 Review ,有需要的童鞋也可供参考。

瘦身的目的

从目的导向来看,我们是不会无缘无故去做一件事情的,那我们对应用瘦身的目的是为了什么?答案是:提高下载转化率。什么是下载转化率?举个栗子:你的应用大小是 18MB ,有100个潜在用户想要去下载尝试使用,结果有20个用户嫌弃安装包太大直接扬长而去,有20个用户在等待下载的过程中取消下载,最终只有60个用户真正下载安装,那么应用的下载转化率就是 60/100 = 60% 。

简单的小结便是:安装包越小,用户下载等待的时间越短,对手机存储配置小的设备体验愈佳,应用的下载转化率也就越高。记得以前在腾讯大讲堂听微信大牛说过,微信第一个版本只有差不多 400KB ,瞬间膜拜。

安装包的组成

要对安装包做瘦身,首先需要了解安装包的组成结构,这里简单的梳理了一下组成各个部分及其作用:

其中,在安装包中占比较大的包括:dex文件、res文件夹、assets文件夹、lib文件夹以及resource.arsc文件。所以,接下来的瘦身优化就是让这些文件变小,以此达到瘦身的目的。

在 Android Studio 2.2.3 开始,就加入了浏览 APK 结构的功能,我们直接把安装包拖入 IDE ,就可以直接浏览其组成和对应大小,这样能够很方便的对比分析出每一步优化后的结果。

资源瘦身

了解完 APK 的组成,我们可以开始着手优化的工作了,因为资源文件在 APK 中的占比最高,所以优先从资源瘦身开始着手。

尽量只保存一份图片资源

开发目录下会有个 drawable 或者 mipmap 目录用于适配不同 dpi 的屏幕,下面是不同命名目录所适配的 dpi 范围

目前市面上绝大部分机型都处于 xxhdpi 的适配范围,所以可以考虑只保留 xxhdpi 目录下一份图片资源,具体保留哪个目录下的资源和保留几份资源还得依照应用自身的实际机型分布决定。

使用 Drawable XML、Color、.9 PNG 代替 PNG

  • 一些情况下,我们可以考虑使用 Drawable XML 来代替 PNG,如:渐变的背景图,用几行 XML 就可以描绘出来,何必使用几十到上百K的 PNG 文件;
  • 用 Color 代替 PNG,如:纯色的背景;
  • 从性能上看,比起使用图片资源需要先将其生成 Bitmap 再传到底层交由 GPU 渲染,用 Drawable XML 和 Color 则更加高效,它是直接将 Shape 信息传到底层由 GPU 进行渲染,CPU 和 内存的占用会更少;
  • 用 .9 PNG 代替 PNG,场景很多,不举例了;

使用 JPG 代替 PNG

用 JPG 代替 PNG,由于 JPG 没有 Alpha 通道,所以文件更小,适用于不需要透明度的图片可以考虑。

谨慎使用 WebP 代替 PNG

由于 WebP 效果好,且相同效果下, WebP 文件比 PNG 文件要小得多 ,所以,网上很多人说使用 WebP 代替 PNG,对此,我保持异议。理由如下:

  1. WebP 在 Android 端,最低只支持 4.0 ,要兼容 4.0 以下的环境需要额外引入兼容库,反而增大安装包体积;
  2. Android Studio 不支持预览 WebP 图片,引用 WebP 的布局文件也无法预览显示;
  3. 解压了 BAT 们的应用,以及同类竞品,基本没有发现在资源文件中用 WebP 的;

有损编码格式的音频文件代替无损格式的音频文件

从下面这篇官方文档

https://developer.android.com/guide/topics/media/media-formats.html

可以看到 Android 平台支持的音视频格式,下面列出有损和无损常用的格式(不要认为有损编码就是音质很差):

  • 无损格式:WAV,PCM,ALS,ALAC,TAK,FLAC,APE,WavPack(WV)
  • 有损格式:MP3,AAC,WMA,Ogg Vorbis

实际开发中需要使用音频文件尽量采用 MP3、Ogg 这种有损格式,尽量不要用 WAV、PCM 这种无损音频。

移除无用的资源

这里的移除无用资源文件主要分为两个部分: 不打包没有使用的资源和删除没有使用的资源

  • 不打包没有使用的资源,在项目的 build.gradle 中配置 shrinkResources true 即可。

  • 删除没有使用的资源,通过 Android Studio 选中项目右键 => Analyze => Run Inspection by Name => 输入 Unused Resuroces

即可看到所有未使用的资源文件,建议定期清理掉这些没用的文件,一方面可以减小工程的大小,另一方面太多的资源文件会导致打包后 resources.arsc 文件变得越来越大,公司有一项目 resources.arsc 文件已经达到 2-3 MB 的程度,有点惊人。

综合以上几点,就可以有效的精简我们安装包中的 res文件夹、assets文件夹、resource.arsc文件大小,从而达到瘦身目的。

工具

上一章节提到的是优化的思路,本章节整理在优化过程中使用到的工具。

以上是我优化过程中用到的觉得不错的工具,有更好的推荐,欢迎补充。

另外,在对图片做压缩的时候,不要贪图方便直接将整个资源目录下的图片一次性压缩一趟。很多时候,前面做这个项目的人可能已经对一些资源文件做过压缩处理,很容易导致二次压缩而引起一些图片失真。这里我建议是,去到应用的资源目录下将资源文件从大到小排序,定一个标准,如超过 20KB 的图片要做压缩处理,则将这些符合条件的图片 Copy 一份出来做压缩处理,处理后确保没出现失真的情况下再替换对应优化前的图片资源。 音频文件的处理,同理。

Native库瘦身

Native 库瘦身主要是减小对 CPU 架构的支持,配置起来很简单,在 build.gradle 使用 abiFilters 配置需要用到的 CPU 架构,并将不需要兼容的 so 文件从项目中移除即可。

根据我们用户的机型分布,最终只保留了对 armeabi-v7a 支持。注意,这里需要根据自家产品的实际情况来决定。由于之前对 CPU 的架构分布不是很熟悉,感谢微信的张绍文、沪江的徐宜生以及虎牙的郑晓滨几位老司机给我科普了一发。

综上所述,就可以有效的精简我们安装包中的 lib 文件夹大小,从而达到瘦身目的。也有一种做法是通过在 build.gradle 配置 include 来针对每个 CPU 架构生成单独的安装包,虽然看起来很不错,但是很多国内应用市场上架的时候并不支持这种每个 CPU 配置一个包的做法,所以此做法较为鸡肋,不太建议去做,如果应用只上 Google Play ,那确实要比配置 abiFilters 好得多。

代码瘦身

这里可以做的事情也是很多,主要如下:

  • 移除废弃功能的代码,反正有 VCS ,删了代码随时可以找回;
  • 移除重复的代码,如:已经有了的功能代码,团队成员不知道自己又写了一套,只能靠代码 Review 解决了;
  • 移除功能重叠的框架,如:项目中有几套网络访问框架 Volley、AsyncHttpClient、Retrofit 等,同样只能靠代码 Review 解决;
  • 移除无用的 dependencies 或者 jar 包;
  • 减小对 Support 兼容包的依赖,Support-V4 包非常大,项目引入无疑会增大 dex 文件的大小,Google 已经意识到这个问题,所以 Support-V7 一开始就做了拆分,并且开始对 Support-V4 做拆分,虽然目前成果还不明显,不过还是蛮值得期待的,特别是发现你少了 Support-V4 包后,可能就从2个 dex 变成1个 dex 了呢;
  • 插件化,一种懒加载思想的体现,先让用户能够安装宿主包,对于一些功能模块做插件化,在特定的时机再下载安装;

综上所述,就可以有效的精简我们安装包中的 dex 文件大小,从而达到瘦身目的。

结束语

整个优化过程我把项目从 18 MB 优化到了 12.5 MB,以上有些优化点受其他一些原因的影响,只能暂时作罢,可以考虑纳入下一次的优化排期。套路大概就是这么些,实践的时候请根据自身项目定夺,并优先优化性价比较高的部分(性价比=可优大小/所需时间)。

相关 [android 应用 瘦身] 推荐:

Android 应用瘦身,从 18MB 到 12.5MB

- - DiyCode - 致力于构建开发工程师高端交流分享社区社区
Hello,大家好,我是Clock. 这是我春节前的最后一篇技术分享文章了,在这里提前预祝大家鸡年万事如意,身体健康,新年升职加薪. 前阵子老大交给了我一个任务,主要是帮我们开发的直播应用做 Android 端的安装包瘦身,花了大概一周的时间把安装包从 18MB 减小到了 12.5MB. 原本完全可以优化到 10MB 之下,但由于其他原因的限制,所以目前阶段只到 12.5MB 为止.

GetEd2k (Android应用)

- 某牢 - eMule Fans 电骡爱好者
GetEd2k是一个Android应用程序,作者是anacletus. 此应用可以帮助你把网页中的电驴(eDonkey) 链接添加到你个人电脑的电驴客户端里,不过前提是你的客户端开启了用于远程控制的Web interface(Web服务器,网页接口,Web界面),当然,eMule(电骡), MLDonkey 和 aMule 都支持该功能,所以这三种主流电驴客户端的用户都可以使用GetEd2k.

Android 应用程序

- - CSDN博客推荐文章
Android 应用程序由四个模块构造而成:Activity、Intent 、Content Provider 、Service. 下面简单介绍一下如下模块的含义:. 1、Activity  "活动". 一个Activity就是单独的屏幕,每一个活动都被实现为一个独立的类,并且从活动基类中继承而来,活动类将会显示由视图控件组成的用户接口并对事件作出响应.

android应用框架

- - CSDN博客移动开发推荐文章
原文地址:http://developer.android.com/guide/components/fundamentals.html. android应用程序一旦装进设备,每个程序会在它自己安全的沙盒里运行. 1.android操作系统是一个多用户linux系统,每一个应用程序是一个用户. 2.默认情况下,系统会为每个app分配唯一的linux用户id(这个id只会被系统使用,并且只会被这个app知道),系统为每个app的所有文件都设置了权限,只有被分配了这个app用户ID的程序可以访问它.

Android系统其实不需要极度精简,您未必知道的瘦身之法

- - 一抹新绿
安卓系统其实不需要极度精简,至少我不推荐这种行为,只是一味的精简并不会给系统带来什么好处反而只有害处,因为许多系统应用跟设置里的选项有关联,应当尽量保证系统的完整性. 后台为什么会无缘无故多出很多进程呢. 如果你真的理解安卓进程管理机制和软件架构的话,就会发现各种Receiver,各种CHANGED事件其实才是主因,一切都是软件进程事件触发自行后台启动造成的.

Android 应用界面设计

- - 互联网的那点事...
与 iOS 相比,Android 系统界面存在各种不协调,应用界面本身缺乏统一的规范. 虽然 Android 的开放性为应用的自主发挥带来了最大的可能性,但如果系统本身能够提供标准的范例,也未必是一件坏事,毕竟许多应用并不一定需要独创的界面. 从 Android 4.0 开始,系统界面在一致性上有了许多改善,那么 Android 应用的界面应该如何设计.

Android应用开发资源

- - InfoQ cn
Android应用设计和开发人员现在可以参考由Android用户体验(UX)团队官方发布的 Android设计指南. 该指南提供了开发者应该遵循的基本原则,并列出了很多细节指导,涉及 设备与显示、 主题、 触控交互、 度量与栅格、 排版、 色彩、 图标设计,以及如何 编写用户交互界面的提示语.

Android应用性能 分析

- - CSDN博客推荐文章
  其实主要是内存方面,内存管理是个永恒的话题. 1.从工具DDMS中,在Sysinfo的tab栏里面有一个Memory usage的选项,通过USB连接Android设备以后很容易抓到图. 在图中可以看到系统随时可以用的内存是Free和Buffers两项,因为我抓图的系统只有128M的内存,所以看上去这部分可用内存已经很少了.

Android应用性能测试

- - CSDN博客推荐文章
java虚拟机有内存使用上限的限制. adb shell进入手机,这此参数被纪录在/system/build.prop中,如果想直接查看可以使用adb shell getprop. 单个应用程序最大内存限制,超过这个值会产生OOM. 单个java虚拟机最大的内存限制,超过这个值会产生OOM. android程序内存一般限制在16M,当然也有24M的,而android程序内存被分为2部分:.