Android三个流量优化方案 (建议收藏)

1,170

前言

套餐虽然优惠,流量还是很贵,对用户而言网络流量就是钱呐!用户习惯打开系统自带 APP 流量统计功能,从 APP 的角度,总不希望用户一眼看出自家的 APP 是流量大户,所以有必要花时间知道 APP 的流量怎么流失的。但是系统的流量统计功能只是很粗略的对每个 APP 消耗的流量总量(分时)进行统计,但是程序员需要对 APP 的流量进行更精细、多维度的分析,从而有针对性地优化 APP 数据流量,所以有了以下几种方案。
该文不仅仅包括流量优化,文末还列举了Android程序各类性能优化,请慢慢阅读

一、数据缓存

OkHttp 缓存

如果我们仔细跟一下自己项目中的接口,就会发现很多对实时性没有那么高要求的接口,使用缓存不仅可以节约流量,而且能大幅提升数据访问速度。

我们常用的网络库,比如 OkHttp 和 Volley,都有比较好的缓存实践。

而且没做缓存对用户体验也不好,一般的 App 会在打开后显示一个无数据的界面,和展示上一次的数据相比,这个用户体验其实是比较差的。
1. 无网拦截器
下面我们重点看下 OkHttp 的缓存实践,首先定义一个无网拦截器。

然后是给 OkHttpClient 添加拦截器。

添加了无网络拦截器后,当无网络的情况下打开我们的 App 时,也能获取到上一次的数据,也能使用 App,这样就能提升用户体验。

2. OkHttp 缓存处理流程
OkHttp 的缓存拦截器对于请求的处理流程如下。

过期时间与增量更新

1. 过期时间

在服务端返回的数据中加上一个过期时间,这样我们每次请求的时候判断一下有没有过期,如果没有过期就不需要去重新请求。

2. 增量更新

数据增量更新的具体思路,就是在数据中加上一个版本的概念,每次接收数据都进行版本对比,只接收有变化的数据。

这样传输的数据量就会减少很多,比如省市区和配置等数据比较少更新,如果每次都要请求省市区的数据,这就是在浪费流量。

我们只需要更新发生变化的数据,因为和服务器相关比较密切,在这里就不给大家举例了。

二、数据压缩

1. Gzip

对于 Post 请求,Body 是用 Gzip 压缩的,也就是请求的时候带上 Gzip 请求头,服务端返回的时候也加上 Gzip 压缩,这样数据流就是被压缩过的。

2. 压缩请求头

请求头也占用一定的体积,在请求头不变的情况下,我们可以只传递一次,以后都只需要传递上一次请求头的 MD5 值,服务端做一个缓存,在需要请求头中的某些信息时,就可以直接从之前的缓存中取。

3. 合并网络请求

每一个网络请求都会有冗余信息,比如请求头,而合并网络请求就可以减少冗余信息的传递;

三、图片压缩

1. 缩略图

图片压缩的第一个手段,就是在列表中优先使用缩略图,因为展示原图会加大内存消耗和流量消耗,而且在列表中直接展示原图没有意义。

下面是原图和缩略图的对比大小,缩略图尺寸为原图的 50%,大小为原图的 10%。

2. WebP
图片压缩的第二个手段,就是使用 Webp 格式,下面是同一张图片在 PNG 格式和 WebP 格式下的对比,WebP 格式的大小为 PNG 格式的 51%。

3. Luban

比如我们在上传图片的时候,做一个压缩比如在本地是一个 2M 的图片,完整地上传上去意义不大,只会增加我们的流量消耗,最好是压缩后再上传。

而在图片压缩上做得比较好的就是鲁班,下面我们来看下鲁班的使用方法。

首先添加依赖。

dependencies {
  // 图片压缩
  implementation 'top.zibin:Luban:1.1.8'
}

然后添加对图片进行压缩。

下面这张图片的原始大小为 1.6M,压缩后变成了 213KB,体积为原始大小的 13%。

以上就是本文所有内容了,有需要了解更多Android性能优化的,请往下看。(文末有惊喜)

ANR问题解析

crash监控方案

启动速度与执行效率优化项目实战

内存优化

耗电优化

网络传输与数据存储优化

apk大小优化

项目实战

以上资料,有需要的可在我的QQ技术交流群里可以自助拿走,如果在学习或工作中遇到了问题,群里会有一些大神帮忙解答,有时你闷头想一天,不如别人的三言两语就醍醐灌顶,群793544421,也可点击这里,加入我们圈子,共同进步。