android产品研发(四)-->减小Apk大小

随着移动技术的深入发展,各种炫酷效果的更新,在我们追求UI与UE的同时一个不如忽视的问题逐渐暴露出来,那就是apk文件越来越大,可能有的童鞋会说现在都是wifi环境,apk文件增大几M不是什么大不了的问题,这其实也是有一定道理的,但是作为开发人员的我们这绝不是我们认为可以忽略这个问题的理由。优化Apk大小也是优化我们App体验的一个重要方面,虽然可能它不是那么的重要。

那么到底是那些原因让我们的Apk文件变得越来越大呢?

  • 多屏幕是适配问题,移动设备的多样化导致了一个app需要N钟不同尺寸的设置,从而增加了安装文件中资源文件的种类与大小;
  • 各种开发框架,开发工具的改进,虽然方便了我们开发者重复造轮子,但是这也间接的增加了安装文件的大小;
  • 在追求各种动画、UI效果的内在需求,显而易见的更加炫酷的UI、UE效果会客观上增减Apk文件的大小;
  • 开发人员沟通不足,冗余代码过多造成打出来的apk文件增大;
  • 为了满足性能、安全性的需求,增添.so库;

好吧,既然我们知道了为何我们的apk文件越来越大,我们就可以有针对性的提出解决办法,为了更好的说明问题,这里我简单的列一下apk文件的组成:

  • 源码文件即源代码文件等
  • 资源文件包括apk文件中的各种布局文件,资源文件,图片文件,原生文件等等
  • 本地代码文件这里主要指的是.so文件

那么在知道了apk文件的组成之后,如何减少apk文件的大小就很简单了

减小apk文件的大小,已经是一件很重要的事情。上面我们知道了apk文件的组成部分,就可以根据这些组成部分做一些优化安装文件的工作了。。下面是我总结的一些减小apk文件大小的方式:

源码文件方面的优化方式:

  • 掌握良好的编码习惯,复用代码,对于一些重复性的代码逻辑复用;
  • 使用Proguard对代码混淆,优化,压缩(它不仅仅是一个牛擦的混淆工具在代码优化方面也是很棒滴)。
    • 减少一些无用代码库的引用,经常的一个场景就是可能一些代码库已经不需要了,但是还是在代码中引用着,这样做的后果就是无用的代码库也会被编译到apk文件中;
    • 定期进行代码review,这是一个很重要的工作,可以是团队成员之间熟悉彼此代码同时也可以查找出一些自己看不出来的bug以及减小一些无用代码;
    • 做一些代码lint之类的工作,android studio已经提供了这样的功能,定期执行代码lint操作是一个比较不错的习惯;

资源文件方面的优化方式:

  • 对于一些不必要的设备尺寸,不必要全部设备(主要看产品需求)
  • 对资源文件,主要是图片资源进行压缩;
  • 一些UI效果可以使用代码渲染替代图片资源;
  • 资源文件的复用,比如两个页面的背景图片相同底色不同,就可以复用背景图片,设置不同的底色;

本地代码文件方面的优化方式:

  • 限制app支持的cpu架构的数目,在当前的Android 生态系统中,让你的app支持 armabi 和 x86 架构就够了;
  • 尽可能的重用so库文件;

最后重点讲一下图片的压缩工作,其实上面所讲的所有的减小apk大小的技巧中最重要的就是对图片的压缩工作。一般而言图片压缩对减小Apk大小所产生的效果占到你所有减小Apk努力的效果50%以上,因而要想减小Apk大小就考虑一下怎么减小图片的大小吧。

这里推荐一个比较不错的图片压缩网站:https://tinypng.com/ 支持对jpg与png图片资源的压缩。

我们可以具体的测试一下不同大小图片资源的压缩情况:

可以看到当图片资源大于100k之后压缩率都是65%左右,在10k+的图片资源上表现同样很牛擦,当图片资源小于10k的随着图片大小的减小,逐渐减少。

后来具体在我们的apk文件中都是用这种方式压缩一遍之后,apk文件的大小从11.86M减少到了10.52M,可见apk文件减小的效果还是很明显的。

总结

以上减少apk文件的方式相对来说,体验方面就需要有一定的取舍,设计就是在一个约束集里面找出最好的方案。显然apk文件的大小就是一个约束。不要害怕为了让多个方面变得更好而放松一个方面的约束。你需要将app各方面进行整体考虑,而不是仅仅几个方面的斟酌。

另外对产品研发技术,技巧,实践方面感兴趣的同学可以参考我的:

android产品研发(一)–>实用开发规范

android产品研发(二)–>启动页优化

android产品研发(三)–>基类Activity

本文以同步至github中:https://github.com/yipianfengye/androidProject,欢迎star和follow

时间: 2025-01-13 12:34:39

android产品研发(四)-->减小Apk大小的相关文章

android产品研发(七)-->Apk热修复

转载请标明出处:一片枫叶的专栏 去年一整年android社区中刮过了一阵热修复的风,各大厂商,逼格大牛纷纷开源了热修复框架,恩,产品过程中怎么可能没有bug呢?重新打包上线?成本太高用户体验也不好,咋办?上热修复呗. 好吧,既然要开始上热修复的功能,那么就得调研一下热修复的原理.下面我将分别讲述一下热修复的原理,各大热修复框架的比较,以及自身产品中热修复功能的实践. 热修复的原理 通过更改dex加载顺序实现热修复 最新github上开源了很多热补丁动态修复框架,大致有: HotFix      

android产品研发(六)-->Apk混淆

前面一篇文章中我们讲解了android里面的多渠道打包,对于大型的app来说,几百个上千个渠道包都是很正常的事,所以效率定制化是一件很重要的事.主要讲解了三种多渠道打包方式,并分析了其各自的利弊,在各自产品多渠道打包的时候,可以根据自身的产品需求选择相应的打包方式. 而本文主要讲解Apk的混淆,这里的混淆分为两种代码混淆和资源文件混淆.实际的产品研发中为了防止自己的劳动成果被别人窃取,混淆代码能有效防止apk文件被反编译,进而查看源代码.说来惭愧,作为互联网创业公司的我们也确实对竞品Apk反编译

android产品研发(十四)-->App升级与更新

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android app中的轮训操作,讲解的内容主要包括:我们在App中使用轮训操作的情景,作用以及实现方式等.一般而言我们使用轮训操作都是通过定时任务的形式请求服务器并更新用户界面,轮训操作都有一定的使用生命周期,即在一定的页面中启动轮操作,然后在特定的情况下关闭轮训操作,这点需要我们尤为注意,我们还介绍了使用Timer和Handler实现轮训操作的实例,更多关于App中轮训操作的信息,可参考我的:android产品研发(十三)–>App轮训

android产品研发(十)-->不使用静态变量保存数据

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了Android中的几种常见网络协议:xml,json,protobuf等,以及各自的优缺点,一般而言主要我们的App涉及到了网络传输都会有这方面的内容,具体可根据项目的需求确定各自的网络传输协议.这里可参考android产品研发(九)–>App网络传输协议 而本文讲解的其实并不是一个技术方面,而是一个android产品研发过程中的技巧:尽量不使用静态变量保存核心数据.这是为什么呢?这是因为android的进程并不是安全的,包括applicat

android产品研发(十七)-->Hybird开发

转载请标明出处:一片枫叶的专栏 上一篇文章中我们介绍了android开发中经常会涉及到但又常常被忽视掉的开发者模式.主要讲解了包括如何打开手机的开发者模式,开发者模式中各个菜单的意义和作用,如何清除手机App数据,以及清除手机App数据具体清除那些数据等知识点,具体关于android中开发者模式的知识,可参考我的:android产品研发(十六)–>开发者选项 本文将介绍android中hybird开发相关的知识点.hybird开发实际上是混合开发的意思,这里的混合是H5开发与Native开发混合

android产品研发(十三)-->App轮训操作

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android app实现长连接的几种方式,各自的优缺点以及具体的实现,一般而言使用第三方的推送服务已经可以满足了基本的业务需求,当然了若是对技术有追求的可以通过NIO或者是MINA实现自身的长连接服务,但是自己实现的长连接服务一来比较复杂耗时比较多,而且可能过程中有许多坑要填,一般而言推荐使用第三方的推送服务,稳定简单,具体管理长连接部分的模块可参考:android产品研发(十二)–>App长连接实现. 而本文将讲解app端的轮训请求服务,

android产品研发-->总结(持续更新中)

转载请标明出处:一片枫叶的专栏 最近的android产品研发系列主要讲解的是android产品研发过程中涉及到的技术,技巧,实践等.前面我们讲解了android源码系列的文章,源码系列的文章东西比较多比较复杂,并且一些东西还没有讲完,这里已经更新了30篇了,后续的东西一定会更新的.考虑一直讲源码系列可能看的比较累,这里就有了产品研发系列的文章.本个系列的文章主要是讲解android产品研发过程中一些需要注意的技术技巧与实践.其主要面对产品研发,对App稳定性,友好型,兼容性要求较高的App. 下

android产品研发(五)-->多渠道打包

国内的Android开发者还是很苦逼的,由于众所周知的原因,google play无法再国内打开,所以android系的应用市场,群雄争霸,而后果就是国内存在着有众多的应用市场,产品在不同的渠道可能有这不同的统计需求,为此android开发人员需要为每个应用市场发布一个安装包,这里就涉及到了android的多渠道打包. 本文主要讲解的就是几种主流的多渠道打包方式,以及其优劣势. 通过配置gradle脚本实现多渠道打包 这种打包方式是使用android Studio的编译工具gradle配合使用的

android产品研发(十六)-->开发者选项

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android中内存对象的序列化方式.由于android开发涉及到不同Activity的数据传递,对于基本数据类型数据的传递是没有问题的,但是一旦涉及到复杂数据类型,就需要将数据序列化以便传输,在文章中我们主要讲解了两种数据序列化的方式:实现Serializable接口和实现Parcelable接口,同时也比较了它们各自的优缺点和实现方式.具体关于内存对象序列化方面的知识可参考:android产品研发(十五)–>内存对象序列化 本文主要介绍A