Android---网络编程优化

网络请求操作是一个  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. 幂等性在网络架构设计中是一个比较重要的原则。

猜你喜欢

转载自blog.csdn.net/qq_44950283/article/details/134406440
今日推荐