Android应用继续瘦身,以及一些注意事项

自上次对应用瘦身过后,经历的若干功能的迭代,很快的,安装包大小又到了15MB,老大说要控制在10MB之内,于是便开始了新一轮的瘦身之旅。如果你还没读过我的前面一篇瘦身文章,可以先去看看:

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

已经看过上文的朋友,可以直接阅读本文,文章接下来将会为你带来更多瘦身方案,以及一些需要注意的问题。

WebP局限性

在我的上一篇文章提到,让大家谨慎使用WebP格式的图片,并且提及到Android Studio不支持预览WebP图片的问题,而最新的2.3版本已经支持预览WebP文件,同时还能够帮我们将JPG和PNG转换成为WebP图片,虽然IDE的升级让我们喜出望外,但你仍然要关心WebP的一下几个问题:

  • WebP的编码时间为PNG的5倍以上,解码速度与PNG差不多,甚至更快;
  • WebP编码时占用内存比PNG高25%,解码时比PNG低30%;
  • Android 4.0+开始支持WebP图片,但是带透明度的WebP图片是在4.2.1+之后才支持的,在4.2.1之前则无法显示;

针对以上一二点,你可能需要考虑一下自家用户实际机型分布情况,如果大部分都是中低端配置机型,使用了WebP后对体验可能会有所下降,对于高配设备,完全可以忽略。而针对第三点,则需要考虑用户的系统分布,相信绝大部分App的用户已经满足4.0+这个条件,但对于满足4.2.1+条件就很难说了,至少我们这款有几百万用户的产品仍有不少用户不满足此条件,因此也不敢随便提升最低兼容版本,但是你仍然可以进行一些WebP的处理,主要如下:

  • 对于不需要透明度的PNG图片,先转成JPG格式后,再使用IDE进行WebP转换。不要直接用PNG转换成WebP,否则转换后的WebP仍然带了透明度,在4.2.1之前的设备任然无法显示,先转换成JPG就是为了去除PNG的透明度;
  • 将PNG转换成JPG时,建议采用专业的图片处理工具,因为我在使用一些在线转换工具转换成为JPG时,发现有少量的图片转换成JPG后再转成WebP时在4.2.1之前依然无法正常显示,但经过专业的处理的图片处理工具转换后的图片则全部没有问题;
  • 在将JPG转换成WebP图片时,采用IDE默认75的有损压缩质量,超过75之后,压缩效果反而会变差;

虽然IDE给了我们WebP更方便的支持,但实际上受限于Android系统版本的问题,所以,我们只能对有限的图片做处理,对于项目中有大量留白的透明像素的图片,转换成JPG效果会失真,所以,也只能暂时忽略掉。最后,推荐一个腾讯出品的WebP在线工具——智图:https://zhitu.isux.us/ 。关于WebP的知识,我非常建议大家阅读以下两篇腾讯出品的文章,你会收获很多

shrinkResources误区

网上很多文章都说在build.gradle中开启shrinkResources true的设置,这样可以在打包过程中工具链会自动帮你移除相应一些无用的资源。

而实际上shrinkResource只能帮你压缩合并资源,并不能帮你移除资源文件,读者可以自行拷贝一些无用的资源文件放到工程中打包验证,你会发这些文件将会原封不动的打进你的安装包中。不过,从另一个角度去想,可能是因为我们拷贝资源到工程中时,IDE会帮我们在R.java文件中生成对应的资源ID信息,所以即使没有显式的在代码中引用资源,但是自动生成信息的R类却一直引用着。依靠配置shrinkResources true移除资源的目的无法达到,我们只能通过IDE的Remove Unused Resources功能筛选出工程中对应无用的资源

不过,建议大家使用它时选择Preview模式,不要直接使用Refactor模式

因为代码中引用方式不同,所以存在代码中使用了某个资源,但是依然被当成没有引用的情况,例如通过使用getIdentifier、Uri等方式。

resConfigs

Google在官方文档提到,可以通过限制语言资源来压缩包大小,但实际操作上,由于我们的应用原本就只支持中英文,所以实践之后收效甚微,这里简单提及一下。

SO压缩

按照动态加载的思想,我们对项目中很多音视频处理的SO文件进行了7zip极限压缩,等到用户升级安装应用时,才动态解压出SO文件进行加载调用(解压耗时在我们最差的机型上只用了2.8s)。如果你的项目中有也存在大量自己开发的SO文件,可以考虑用这种方案进行优化,成效会很明显。更有甚者,对于不常用的功能需要用到的SO文件,我们可以考虑从网络中下载完成后再动态加载进来,这将更进一步的缩减了你安装包的大小。

源码梳理

我在上一篇文章中提到,对源代码进行梳理建议,不少同学给我留言,基本都是认为源码精简对应用的瘦身作用非常有限。实际上,这并不能一概而论,得看具体的项目情况而言,这里就分享一下我在项目中实际操作好了。

  • 合并网络请求管理,移除原有的android-async-http、Volley,仅保留OkHttp;
  • 合并图片加载管理,移除原有的其他加载管理方案,仅保留Fresco;
  • 合并整理功能重复的一些自定义控件;
  • 移除历史悠久已经废弃的功能模块代码;
  • 裁剪Fresco,例如不需要加载gif,WebP等可以把相应的功能模块移除,不需要用OkHttp来管理Fresco的网络加载可以移除(实际上移除后发现反倒少了一些Fresco加载图片效果出问题的一些BUG,意料之外的收获);
  • 移除一个开源的JSON解析库com.fasterxml.jackson.core:jackson,这货整整8000多个方法,移除后包直接小了200多K;
  • 移除Google Zxing库;
  • 提取Android 4.2.2系统源码中的一个汉字转拼音的类,替换原有项目中的实现方案以及其带进来的一个200多k的附属文件;

当然有些功能比较复杂又加上年代久远,所以梳理还是需要小心谨慎,最好能对一个功能模块了解全面了再进行整理。在整理完源码之后,再清理一波无用的资源,又可以节省不少空间。最后,推荐大家一个计算项目编译后的方法数的Gradle插件

https://github.com/KeepSafe/dexcount-gradle-plugin/

使用它你可以看到每次改进后效果,也可以用它分析出包中含有较多方法的包是哪一个,是否有必要进行排查优化等等。在debug编译的时候注意要开启混淆,这样可以看到实际混淆优化后的效果,因为混淆优化后,会有不少没用的方法被优化移除,但对于引用的第三方类库以及一些混淆规则中keep住的类则原封不动。

插件化

插件化同样是一个不错的优化方案,同样利用动态加载的原理,不过这又属于另一话题了,此处就不铺开详述了。

AndResGuard

https://github.com/shwenzhang/AndResGuard/

来自微信的资源混淆优化方案,同样也是利用了7zip极限压缩,具体原理可以详细查看项目说明,一些需要注意问题均有详细说明。比较值得注意的有以下几点:

  • 项目对于资源文件的名字做了混淆优化,所以一些第三方SDK以及项目中使用getIdentifier、Uri等方式加载资源,需要将对应的资源加入到白名单中,否则会出现闪退;
  • 部分手机桌面快捷图标的实现有问题,务必将程序桌面icon加入白名单;
  • 通过修改zip摘要的方式生产渠道包,出渠道包时,解压重压缩会破坏7zip的效果,通过repackage命令可用7zip重压缩;

实际操作中,我们使用此方案后包只少了大约200K,而且还伴随着一些潜在风险,所以并没有引入使用,其他同学可以实践对比下,再评估是否要使用。

Redex

https://github.com/facebook/redex

Facebook出品的字节码优化方案,其原理是优化打包过程中Java字节码文件,和Proguard的原理一样。针对此方案的优略之处,大家可以看看Trinea的文章:Facebook App优化工具ReDex优化的6点及未优化的一大方面。在实际操作中,使用此方案后包同样也只少了大约200K,并且翻看了Github上的Issue还存在一些莫名其妙的闪退问题后,最终没有考虑引入此方案。

总结

好了,本篇关于Android应用瘦身的文章到这里就结束了,整个实践的过程有颇多的细节需要注意,避免瘦身后又给自己挖了一个大坑。尽量每做一个小模块的改动,就生成一个commit,这样发现问题后可以方便定位回滚。很多同学在我上篇文章中讨论,关于这样的瘦身是否有意义,对于我们的产品来说,经常有很多线下运营活动需要人们现场下载,这样的瘦身对线下活动提高转化率还是非常有用的。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,012评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,589评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,819评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,652评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,954评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,381评论 1 210
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,687评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,404评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,082评论 1 238
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,355评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,880评论 1 255
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,249评论 2 250
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,864评论 3 232
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,007评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,760评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,394评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,281评论 2 259

推荐阅读更多精彩内容