class HttpDns : Dns {

    private val cacheHost = hashMapOf<String, InetAddress>()

    override fun lookup(hostname: String): MutableList<InetAddress> {
        if (cacheHost.containsKey(hostname)) {
            cacheHost[hostname]?.apply {
                return mutableListOf(this)
            }
        }
        return try {
            InetAddress.getAllByName(hostname)?.first()?.apply {
                cacheHost[hostname] = this
            }
            mutableListOf(*InetAddress.getAllByName(hostname))
        } catch (e: NullPointerException) {
            val unknownHostException =
                UnknownHostException("Broken system behaviour for dns lookup of $hostname")
            unknownHostException.initCause(e)
            throw unknownHostException
        }
    }
}

这里可以稍微给大家展开下，LocalDns是不可以被信任的，经常会有运营商会搞一些奇奇怪怪的Dns拦截，导致大家收到的请求是运营商所缓存的(目的是为了省流量)，所以阿里腾讯等都有自己对外输出的HttpDns的服务。这个服务可以帮助大家找到真实准确的Host的Ip，就是这个服务是收钱的。

CDN 缓存静态资源

缓存常见的图片、JS、CSS 等静态资源。

不用域名，用 IP 直连

省去 DNS 解析过程，DNS 全名 Domain Name System，解析意指根据域名得到其对应的 IP 地址。首次域名解析一般需要几百毫秒，可通过直接面向 IP 而非域名请求，节省掉这部分时间，同时可以预防域名劫持等带来的风险。当然为了安全和扩展考虑，这个 IP 可能是一个动态更新的 IP 列表，并在 IP 不可用情况下通过域名访问。

连接池复用

keep-alive HTTP 协议里有个 keep-alive，HTTP1.1默认开启，一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接，而是放入连接池中，若这时有另一个请求要发出，请求的域名和端口是一样的，就直接拿出连接池中的连接进行发送和接收数据，少了建立连接的耗时。

数据压缩

目前比较成熟的方案是 GZIP 压缩，正常情况下压缩率均值能打包 30-50之间，可以极大的提升传输速度和节省流量，必要时可以使用 Protocol Buffer 替换 JSON 。

弱网优化

在弱网时要是制定合适的超时时间，控制网络并发，合并打包请求，调优TCP参数，使用TCP优化算法。
对服务端的TCP协议参数进行调优，以及开启各种优化算法，使得适合业务特性和移动端网络环境，包括RTO初始值，混合慢启动，TLP，F-RTO等。
针对弱网的这些细致优化暂未成为标准，开源网络库 mars 有实现可以借鉴，若有需要可以使用。

CacheControl

Http请求在1.1阶段就引入了CacheControl了，通过CacheControl可以让后端直接控制请求内容的缓存策略。所以还有比缓存更简单粗暴的网络优化方式吗？

在http中，控制缓存开关的字段有两个：Pragma 和 Cache-Control。

通过图片简单的介绍下一些缓存参数。

如果说一句不负责任的话，这个只要后端大佬开启CacheControl就好了呀，原生网络库本来就支持的。当然后端大佬一般都不是特别愿意，其实各位安卓也可以通过添加OkHttp拦截器的方式给网络请求添加一个统一的CacheControl，当然如果你有定制化的需求肯定还是要自己开发的，细节大家可以参考下这个仓库。https://github.com/yale8848/RetrofitCache

HTTP协议规格说明定义ETag为“被请求变量的实体值”。另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式：ETag:"50b1c1d4f775c61:df3"客户端的查询更新格式是这样的：If-None-Match : W / "50b1c1d4f775c61:df3"如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。测试Etag主要在断点下载时比较有用。

而我们只要使用了CacheControl,就可以用到ETag, 如果当数据内容没有发生变更的情况下，就不会传输数据，这样也可以给大家略微优化下你们的Api请求。

网络分级请求

将网络分成移动网络、宽带网络、强网络、弱网络，不同的网络环境对请求进行不同的处理，例如在移动网络下需要进行下载任务时，停止或提示用户，在弱网络下对图片的请求的区分等。
对下载和上传文件采用断点续传功能，不浪费用户之前耗费的时间和流量。

网络状态可以由TelephonyManager.getNetworkType()方法获取到。

Http 1.0 - 1.1 - 1.X - 2.0

以下所有内容均来自网络 HTTP1.0、HTTP1.1 和 HTTP2.0 的区别。https://www.cnblogs.com/heluan/p/8620312.html

当然我们还可以让后端升级接口协议版本，这个可以明显提升你请求响应性能。

长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection：keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

GRPC( A high-performance, open-source universal RPC framework)

不知道各位有没有听说过一个都市怪谈，字节的网络库优化有多厉害多厉害，网络底层采用的是Webview底层的Chromium的网络库，在弱网情况下对于api的优化啥的，巴拉巴拉.....

Cronet是Chromium网络引擎对不同操作系统做的封装，实现了移动端应用层、表示层、会话层协议，支持HTTP1/2、SPDY、QUIC、WebSocket、FTP、DNS、TLS等协议标准。支持Android、IOS、Chrome OS、Fuchsia，部分支持Linux、MacOS、Windows桌面操作系统。实现了Brotli数据压缩、预连接、DNS缓存、session复用等策略优化以及TCP fast open等系统优化。本文内容基于Chromium 75版本。

字节用的就是Chrome的cronet网络库(顺便展开下，cronet同时支持ios，android，前端)。而由于grpc协议的问题，所以传输内容直接使用的protobuf格式，所以其不仅仅是网络层上的优化，同时由于流能直接转化成实体类，同时也减少了可序列化的时间。https://github.com/grpc/grpc-java

protocol buffers 是一种语言无关、平台无关、可扩展的序列化结构数据的方法，它可用于（数据）通信协议、数据存储等。是一种灵活，高效，自动化机制的结构数据序列化方法－可类比 XML，但是比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更为简单。你可以定义数据的结构，然后使用特殊生成的源代码轻松的在各种数据流中使用各种语言进行编写和读取结构数据。你甚至可以更新数据结构，而不破坏由旧数据结构编译的已部署程序。

由GRRC升级QUIC

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。在2016年11月国际互联网工程任务组(IETF)召开了第一次QUIC工作组会议，受到了业界的广泛关注。这也意味着QUIC开始了它的标准化过程，成为新一代传输层协议

其实整个QUIC协议(Http3.0协议)本来就是谷歌写的，所以谷歌的Cronet本身就支持这也是正常的。我其实之前就特地去查过OKHttp支持的协议内容，当前还是只停留在2.0阶段，主要就还是因为当前的Connection写的太好了，而且需要把Tcp直接更换成Udp，所以迟迟没有更新3.0协议的支持。所以各位如果想从协议层去做对应的优化，那么可能OkHttp带给大家的应该还是无尽的等待了。

减小返回数据大小

(1) 压缩一般 API 数据使用 Gzip 压缩

(2) 精简数据格式如 JSON 代替 XML，WebP 代替其他图片格式

(3) 对于不同的设备不同网络返回不同的内容如不同分辨率图片大小

(4) 增量更新需要数据更新时，可考虑增量更新。如常见的服务端进行 bsdiff，客户端进行 bspatch。

(5) 大文件下载支持断点续传，并缓存 Http Resonse 的 ETag 标识，下次请求时带上，从而确定是否数据改变过，未改变则直接返回 304。

网络安全

采用 Https 双向认证
参数加密校验，防窃听/篡改或冒充
加密秘钥保护，采用 so 方式进行秘钥提取

基于OkHttp的网络监控

我们是不是可以考虑把整个api发起到结束进行监控，从而可以方便线上去监控一个Api真实的发起到结束的状况呢？我们先简单的把一个请求的节点拆分下。我要盗图了。

参考数据深入理解OkHttp3：（七）事件（Events）

https://www.pianshen.com/article/8120939/

基于OKHttp提供的EventListener，我们就可以对于一个请求发起到最后的各个节点进行监控，之后上报日志数据，这样在后续的撕逼过程中，其实就可以做到有理有据，有话可说，你真的慢了。

参考：

https://mp.weixin.qq.com/s/VHdhbAgg-kO_t-6BP3Z7Sw

https://blog.csdn.net/walid1992/article/details/89366956

https://www.zhihu.com/question/29466887

Android网络优化基础操作攻略（DNS解析，连接复用，Response Cache，数据压缩，弱网，网络安全，监控）

DNS