网络请求操作是一个  App 的重要组成部分，程序大多数问题都是和网络请求有关。使用 OkHttp 框架后，可以通过 EventListener 来查看一次网络请求的详细情况。一次完整的网络请求会包含以下几个步骤。

也就是说，一次网络请求的操作是从 DNS 解析开始，然后建立连接并发送数据到服务端，随后读取从服务端返回的数据，最后将连接释放。一次网络请求也就结束了。下面就从 DNS 解析开始，看一下都有哪些方面可以做进一步的优化。

DNS 解析优化

1、安全方面

防劫持--考虑使用 HttpDns

注意：HttpDns 只是一个概念，并不是一个现有的开源库。它与传统的 DNS 解析的区别在于 HttpDns 会绕过运行商的 DNS 服务器，直接与 DNS 服务器的 80 端口进行交互，有效地防止域名劫持。

目前已经有第三方厂商提供了实现 httpDns SDK，比较普及的是阿里云和腾讯云的 HttpDns Service。但是这两者的使用具有一定的成本，开发者需要在它们的平台注册并获取开发者 key，并且部分服务是收费的。

对于普通开发者来说，可以考虑使用七牛提供的免费的 happy-dns。实现也比较简单，因为 OkHttp 已经预留了设置 DNS 的接口。如下所示

在接口 Dns 中只有一个 loopup() 方法需要实现，这个方法返回查找到的服务器地址集合，并且 OkHttp 已经实现了一个默认的 Dns 解析器，就是图中红框标注的 SYSTEM。它使用 Java.net 包中的 INetAddress 获取某域名的 IP 地址集合。

我们可以实现 Dns 接口，使用 Http 的请求方式实现自己的域名解析器。具体就是使用七牛提供的 happy-dns sdk 。首先需要添加依赖库

然后在实现的 Dns 类中使用如下方式实现

2、速度方面

关于 Dns 解析的速度方面，我么可以从以下几个方面进行突破。

a. IP 直连方式

这种方式经常在针对不同开发环境的时候使用。比如，针对 qa、staging 的测试环境下，可以直接配置 IP 白名单，跳过 Dns 的解析流程。同样需要实现 OkHttp 的 Dns 接口，如下

有些一线公司也在线上版本采用这种方式 ，但是这种方式开发成本较高。因为 IP 列表是维护在本地，因此需要建立一套 IP 地址的更新机制。另外 IP 直连方式摒弃了 Https 的安全机制，由于 HTTPS 要求证书绑定域名，客户端需要增加额外的代码改造。

b. DNS 解析超时

当我们在做网络请求时，如果网络设备切换路由，访问网络出现长时间无响应。很久之后会抛出 UnknownHostException，并且在 OkHttp 中设置的 connectTimeout 属性对 DNS 的解析不起作用。这种情况，可以在自定义 Dns 中做超时判断，如下所示

具体分析可以参考：Android笔记之解决OkHttp解析dns超时时间无法设置的问题

网络请求缓存优化

实际上有时在做网络请求数据可达优化的时候，经常不可避免的与本地持久化绑定在一起。比如当一次网络请求失败时，我们需要将这次请求保存在本地，并尝试重新发送。或者请求数据成功，需要将数据缓存在本地，当下一次请求数据展示 UI 之前，先将缓存中的数据展示到页面，只有当新的请求返回数据之后，再次刷新页面。

一般做法是创建一个数据库 Entity 类，并根据自家公司的业务逻辑设置公共参数。通常都会有 user_id、update_time 等，如下

上图中 key 表示缓存的标识，插入请求都是根据 key 操作的；value 字段用来保存网络请求的数据。当网络请求成功后，将数据以 JSON 字符串的格式缓存到数据库中。如下所示

图中1处构建 HttpDataCache 类并设置公共参数；图中2处将网络请求数据转换为 Gson 字符串格式；图中3处执行数据操作，将网络请求数据缓存到本地数据库中。

后续当我们再次执行相同 key 的网络请求时，可以先将本地数据库中的数据展示到页面，并进行异步请求操作刷新页面。

幂等性

HTTP 方法的幂等性：一次和多次请求某一个资源应该具有同样的副作用。例如，当点外卖时，服务端和扣款成功后发送给客服端一条扣款成功的消息。但是如果由于网络问题，客户端并没有成功接收到此消息，用户就有可能认为没有付款成功，甚至是尝试再次付款。幂等性就是为例解决这种问题。但是它是属于代码设计层面的技巧，并不是一个实体方法或者开源库。

实现幂等性需要客户端和服务端协同合作实现。比如，原始的付款方法如下

上述方法代表从账户 user_id 中扣除 amount 数量的金额。多次操作就会造成同一个 user_id 账户被扣款多次。可以通过以下方式将付款实现幂等。

create_pay_ticket 是获取一个服务器端生成的唯一处理号 ticket_id。它将用于标识后续的操作。idempotent_pay 和 pay 的区别在于关联了一个 ticket_id。一个 ticket_id 表示的操作至多只会被处理一次，这样付款的操作就符合幂等性了。

实际上，很多 HTTP 请求方法自身就符合幂等性。具体可以参考：理解 HTTP 的幂等性

总结

本次介绍了关于网络优化的几个方向：

1. DNS 解析优化，分安全性和速度提升两方面。

2. 对于请求返回的数据需要缓存到本地数据库中。“发送埋点”的请求失败就将其保存到本地数据库中，当 App 重启或者重新接收到连接网络时，重新尝试发送之前失败的请求。

3. 幂等性在网络架构设计中是一个比较重要的原则。