前言：为什么网络优化比别人慢？优化那些还不够？应该加强哪里？

1.Android应用为什么需要考虑网络优化，主要基于以下几个原因：

0. 流量：App的移动网络流量消耗对用户来说是比较敏感的；
1. 电量：网络请求对电量的消耗是比较大的，影响手机的待机时间；
2. 用户体验：网络请求是耗时操作，如果App请求等待时间长，会给用户网络卡, 应用反应慢的感觉。

网络请求优化的目的是尽可能地减少用户等待的时间、减少用户的流量使用、减少对手机电量的消耗，最终达到提升用户体验。

2.网络性能优化主要从如下几个方面着手：

0. 流量消耗
1. 网络速度
2. 获取数据优化
3. 接口设计
4. 弱网优化

一丶流量消耗优化

所谓流量优化，就是在保证数据正确的前提下，如何保证尽可能地少消耗用户流量。虽然现在的流量费用越来越便宜，但是减少流量本身并不是最重要的目的，而是提升用户体验带来的结果。

1.使用本地缓存，减少网络请求

分为几种情况：

• 基本数据：可以使用持久化技术，比如本地数据库，sharedPreference，本地文件，来记录之前请求下来的数据。而且具有一定的过期时效来保证数据的可用性。
• 图片：同样的，在本地缓存和此图片url映射的图片，可以避免图片的网络请求。目前很多优秀的图片加载框架，如Glide，Picasso，Fresco都具备这种能力。
• 文件：如一般的文件，webview里的js，css，html等，当然也要注意过期时效。

2.合理合并api接口，减少网络请求

这种方案可以使得多次网络请求合并为一次，减少网络连接来回往返的等待时长。

比如有一种场景：App 本地数据库缓存有N个表，当老用户卸载重装时，首次检查需要把远端的数据一次性download到本地来，保证两端的一致性。

由于之前必然为每个表设计了一个api，但是在这种场景下，如果还是继续使用这些api的话，就需要N次网络请求，结果不仅会造成N次网络I/O和磁盘写入I/O，还会使得服务端查找性能降低，用户等待时间较长，本地磁盘写入性能降低。

针对这种场景，完全可以设计一个bulk sync api把这些api整合为一个，这样一来客户端只需一次网络I/O即可获取所有数据，服务端查找性能也提升了一个数量级，本地磁盘I/O也可以把此次返回的数据当成一次事务一次性插入数据库中，大大减少了用户等待时间，同时也提升了网络和本地磁盘写入性能。

3.减少网络请求的数据量

当网络请求不可避免的情况下，此时就要考虑如何减少网络请求携带的数据量。

同样也分几种情况：

• 基本数据：使用数据压缩方式，比如protoBuff格式，okhttp开启gzip压缩，支持Http 2.0，使用其头部压缩，二进制格式替代Http 1.1 文本格式的特性。
• 图片：当不得不获取一张本地缓存没有的图片时，就不得不请求服务端获取。此时没有必要使用最高清的大尺寸的原始图片，完全可以针对客户端显示的图片尺寸和屏幕密度，向服务器请求较小的尺寸，和较低质量的图片，服务器通过图片处理，返回符合此参数的图片给客户端进行显示。
• 文件：普通文件可以进行zip打包下发，而如webview需要加载的css，js，html还可以事先使用webpack压缩，然后再zip打包下发。

二.丶速度优化

在进行网络流量优化的同时；由于网络请求次数；请求携带的数据量变少了；这其实也是在变相地提高网络速度。

另外，还有其他一些方式：

• 如okhttp中复用网络连接的方法，当网络请求等待队列中的host和之前的某个结束的请求连接host一致，此时可以直接让此请求复用此网络连接。
• 使用http 2.0的多路复用特性，我们都知道在http 2.0中，使用了stream的概念，使得多个网络请求可以并行发送，不再需要等待上一次请求响应回来再发送下一个请求，从而有效避免了网络请求的排队，提升了整体网络请求速度。
• 当有网络数据需要具备一定的实时性，可以使用长连接方式，比如websocket，http 2.0的方式进行推送，避免通过网络轮询的方式来达到，这样不仅实时性高，而且减少了网络请求次数，提升了用户体验。

三丶获取数据优化

• 连接复用：节省连接时间，如开启keep-alive。Android中HttpUrlConnection默认是开启的。
• 请求合并：可以将多个请求合并为一个进行请求。
• 减小请求数据，并压缩：对于post请求，Body可以做Gzip压缩，如日志。
• 精简数据格式：对于后台返回的数据，尽量使用Json来代替XML。
• 数据的增量更新

四丶接口设计

1.API设计

App与Server之间的API设计要考虑网络请求的频次, 资源的状态等. 以便App可以以较少的请求来完成业务需求和界面的展示。

• 例如, 注册登录. 正常会有两个API, 注册和登录, 但是设计API时我们应该给注册接口包含一个隐式的登录. 来避免App在注册后还得请求一次登录接口(有可能失败, 从而导致业务流程失败)
• 再例如, 上文提到的获取repo详情, 实际上请求了4个接口, 请求了repo的信息, forks列表, contributors列表, readme, 这是因为github提供的接口是尽量单一职责的. 然而在我们的实际开发中, 我们的Server除了提供这些单一职责的小接口外, 最好还能组合一个满足客户端业务需求的repo详情接口出来。

2.Gzip压缩

使用Gzip来压缩request和response, 减少传输数据量, 从而减少流量消耗。

考虑使用Protocol Buffer代替JSON

从前我们传输数据使用XML, 后来使用JSON代替了XML, 很大程度上也是为了可读性和减少数据量(当然还有映射成POJO的方便程度)。

Protocol Buffer是google推出的一种数据交换格式。

如果我们的接口每次传输的数据量很大的话, 可以考虑下protobuf, 会比JSON数据量小很多。当然相比来说, JSON也有其优势, 可读性更高。

3.图片的Size

上�.NETwork Monitor中看到的22s到27s之间的有多次请求, 且数据量还很大. 就是在获取图片资源。图片相对于接口请求来说, 数据量要大得多. 故而也是我们需要优化的一个点。

我们可以在获取图片时告知服务器需要的图片的宽高, 以便服务器给出合适的图片, 避免浪费。现在很多公司的图片资源都是使用第三方的云存储服务的(七牛, 阿里云存储之类的)

以七牛为例, 可以在请求图片的url中添加诸如质量, 格式, width, height等path来获取合适的图片资源:

 

五丶弱网优化

---

1.弱网标准

百度其中就有使用的是一个循序渐进的过程，通过三个阶段来建立一个弱网标准。

• 第一阶段，线下测试：
• 获取预期的阈值，在测试App网络切换、DNS故障时，抓取这些数据
• 第二阶段，线上进行验证：
• 通过线下获取到的阈值，在线上可以获取到弱网的比例，找到会出现弱网的场景，进行诊断优化。（比如网络体验最好的微信，也只是在信令的传输上优化到极致）
• 第三阶段，线上反复试验：
• 通过反复试验来调整阈值，使得优化更接近业务层。
• 腾讯的做法也大同小异，都是根据2.2的指标进行数据收集，整理一套达到弱网时的数据标准。但是我们该如何去探测这些数据呢？这需要我们实现一套完整的网络探测架构。

2.弱网检测

网络探测是弱网检测的基础，目标是能够即时、正确的检测出网络质量，我们把网络探测分成两个部分，主动网络探测和被动网络采集。

3.主动网络探测

主动检测，就是在触发了某些特定条件后，主动的进行网络检测，并按照一定的条件检查出是否为弱网状态。架构图如下所示：

 

4.弱网优化

利用工具模拟弱网, 在弱网情况下体验我们的App. 一般来说, 网络延迟在60ms内, 是OK的, 超过200ms就比较糟糕了. 我们需要做的是在比较糟糕的网络环境下还能给用户较好的体验。

弱网优化, 本质上是在弱网的情况下能让用户流畅的使用我们的App. 我们要做的就是结合上述的优化项:

• 压缩/减少数据传输量
• 利用缓存减少网络传输
• 针对弱网(移动网络), 不自动加载图片
• 界面先反馈, 请求延迟提交 例如, 用户点赞操作, 可以直接给出界面的点赞成功的反馈, 使用JobScheduler在网络情况较好的时候打包请求

五丶结尾

网络优化，是App优化中相当重要的一项优化. 除了客户端, 接口的优化外, 很多一部分优化还依赖于服务器端, 包括服务器端的代码开发, 部署方式等。看到这里想必大家心里应该都知道，应该学习哪块；哪里学习不够；和别人的区别在哪吧。

自己也是从事Android开发5年有余了；整理了一些Android开发技术核心笔记和面经题纲，如有需要的同学请私信我回复“核心笔记”或“面试”领取！