前言

套餐虽然优惠，流量还是很贵，对用户而言网络流量就是钱呐！用户习惯打开系统自带 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大小优化

项目实战

以上资料，有需要的可在私信我回复学习，加入我们，如果在学习或工作中遇到了问题，群里会有一些大神帮忙解答，有时你闷头想一天，不如别人的三言两语就醍醐灌顶，加油，与君共勉。