Android 網(wǎng)絡(luò)優(yōu)化方案

轉(zhuǎn)自：掘金-究極逮蝦戶

https://juejin.cn/post/6896302142542315533

面試官：小蝦啊，我好想你啊，你都好久沒來找我面試了呀。

小蝦：emmmmmmm，這不是怕被你打擊嗎。

面試官：ok，看來是有備而來，那么我們今天聊聊網(wǎng)絡(luò)優(yōu)化咋做吧。

小蝦：我大意了，沒有閃。老頭子，你不講武德，我奉勸你耗子尾汁。

如何優(yōu)化一個網(wǎng)絡(luò)請求呢？

相信大家在面試的時候可能會被問到這個問題。今天我其實就是講述下我知道的一些簡單的優(yōu)化方式，可以幫助大家在面試的過程中得到點基礎(chǔ)分?jǐn)?shù)。

我們先從最簡單，大家比較容易了解到的講起。

DNS優(yōu)化

DNS則是典型的應(yīng)用層的協(xié)議了，至于說為什么第二層能查第三層的IP，因為DNS是Domain Name System縮寫，所以你認(rèn)為是服務(wù)是協(xié)1653議都可以。

一個Http請求在建立Tcp連接的過程中，肯定會產(chǎn)生一次DNS，那么我們是不是可以通過內(nèi)存緩存的方式，通過一個HashMap持有這個Host的IP，當(dāng)下次發(fā)起Tcp連接的時候，我們就可以用直接用內(nèi)存中的這個Ip，而不需要再去走一遍Dns服務(wù)了。

這個時候你肯定會問我，臥槽，你這個不是搞我嗎，這可怎么改呀？

如果你的網(wǎng)絡(luò)層用的是OkHttp的話，Okhttp在封裝的時候就已經(jīng)考慮到這個部分了，其內(nèi)部提供了Dns的接口，可以讓外部在構(gòu)造Client的時候傳入。

class HttpDns : Dns {
    private val cacheHost = hashMapOf()
    override fun lookup(hostname: String): MutableList {        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是不可以被信任的，經(jīng)常會有運營商會搞一些奇奇怪怪的Dns攔截，導(dǎo)致大家收到的請求是運營商所緩存的(目的是為了省流量)，所以阿里騰訊等都有自己對外輸出的HttpDns的服務(wù)。這個服務(wù)可以幫助大家找到真實準(zhǔn)確的Host的Ip，就是這個服務(wù)是收錢的。

如果你是個IOS開發(fā)人員，那么你一定要注意SNI(Server Name Indication)，一個IP對應(yīng)多個多個Https證書的問題。

CacheControl

Http請求在1.1階段就引入了CacheControl了，通過CacheControl可以讓后端直接控制請求內(nèi)容的緩存策略。所以還有比緩存更簡單粗暴的網(wǎng)絡(luò)優(yōu)化方式嗎？

在http中，控制緩存開關(guān)的字段有兩個：Pragma?和?Cache-Control。

通過圖片簡單的介紹下一些緩存參數(shù)。

HTTP協(xié)議規(guī)格說明定義ETag為“被請求變量的實體值”。另一種說法是，ETag是一個可以與Web資源關(guān)聯(lián)的記號（token）。典型的Web資源可以一個Web頁，但也可能是JSON或XML文檔。服務(wù)器單獨負(fù)責(zé)判斷記號是什么及其含義，并在HTTP響應(yīng)頭中將其傳送到客戶端，以下是服務(wù)器端返回的格式：ETag:"50b1c1d4f775c61:df3"客戶端的查詢更新格式是這樣的：If-None-Match : W / "50b1c1d4f775c61:df3"如果ETag沒改變，則返回狀態(tài)304然后不返回，這也和Last-Modified一樣。測試Etag主要在斷點下載時比較有用。

而我們只要使用了CacheControl,就可以用到ETag, 如果當(dāng)數(shù)據(jù)內(nèi)容沒有發(fā)生變更的情況下，就不會傳輸數(shù)據(jù)，這樣也可以給大家略微優(yōu)化下你們的Api請求。

Http 1.0 - 1.1 - 1.X - 2.0

1. 長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP1.1中默認(rèn)開啟Connection：keep-alive，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點。
2. header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/span>
3. 新的二進制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本協(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認(rèn)0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進制格式，實現(xiàn)方便且健壯。
4. 多路復(fù)用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應(yīng)一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請求里面。

HTTP2.0的多路復(fù)用和HTTP1.X中的長連接復(fù)用有什么區(qū)別？

HTTP/1.* 一次請求-響應(yīng)，建立一個連接，用完關(guān)閉；每一個請求都要建立一個連接；

HTTP/1.1 Pipeling解決方式為，若干個請求排隊串行化單線程處理，后面的請求等待前面請求的返回才能獲得執(zhí)行機會，一旦有某請求超時等，后續(xù)請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；

HTTP/2多個請求可同時在一個連接上并行執(zhí)行。某個請求任務(wù)耗時嚴(yán)重，不會影響到其它連接的正常執(zhí)行；

好了，下面要開始真的進入牛逼的東西了，前文你肯定以為我是個大水逼，復(fù)制黏貼。

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

不知道各位有沒有聽說過一個都市怪談，字節(jié)的網(wǎng)絡(luò)庫優(yōu)化有多厲害多厲害，網(wǎng)絡(luò)底層采用的是Webview底層的Chromium的網(wǎng)絡(luò)庫，在弱網(wǎng)情況下對于api的優(yōu)化啥的，巴拉巴拉.....

Cronet是Chromium網(wǎng)絡(luò)引擎對不同操作系統(tǒng)做的封裝，實現(xiàn)了移動端應(yīng)用層、表示層、會話層協(xié)議，支持HTTP1/2、SPDY、QUIC、WebSocket、FTP、DNS、TLS等協(xié)議標(biāo)準(zhǔn)。支持Android、IOS、Chrome OS、Fuchsia，部分支持Linux、MacOS、Windows桌面操作系統(tǒng)。實現(xiàn)了Brotli數(shù)據(jù)壓縮、預(yù)連接、DNS緩存、session復(fù)用等策略優(yōu)化以及TCP fast open等系統(tǒng)優(yōu)化。本文內(nèi)容基于Chromium 75版本。

protocol buffers 是一種語言無關(guān)、平臺無關(guān)、可擴展的序列化結(jié)構(gòu)數(shù)據(jù)的方法，它可用于（數(shù)據(jù)）通信協(xié)議、數(shù)據(jù)存儲等。

Protocol Buffers 是一種靈活，高效，自動化機制的結(jié)構(gòu)數(shù)據(jù)序列化方法－可類比 XML，但是比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更為簡單。

你可以定義數(shù)據(jù)的結(jié)構(gòu)，然后使用特殊生成的源代碼輕松的在各種數(shù)據(jù)流中使用各種語言進行編寫和讀取結(jié)構(gòu)數(shù)據(jù)。你甚至可以更新數(shù)據(jù)結(jié)構(gòu)，而不破壞由舊數(shù)據(jù)結(jié)構(gòu)編譯的已部署程序。

但是正常的網(wǎng)絡(luò)框架基本都使用了Retrofit+Okhttp，而且大家都已經(jīng)使用的很習(xí)慣了，所以我大膽的猜測，字節(jié)其實應(yīng)該用OkHttp橋接了cronet。所以這樣基本就能無縫橋接當(dāng)前已有的網(wǎng)絡(luò)庫了。

由GRRC升級QUIC

QUIC（Quick UDP Internet Connection）是谷歌制定的一種基于UDP的低時延的互聯(lián)網(wǎng)傳輸層協(xié)議。在2016年11月國際互聯(lián)網(wǎng)工程任務(wù)組(IETF)召開了第一次QUIC工作組會議，受到了業(yè)界的廣泛關(guān)注。這也意味著QUIC開始了它的標(biāo)準(zhǔn)化過程，成為新一代傳輸層協(xié)議

所以各位如果想從協(xié)議層去做對應(yīng)的優(yōu)化，那么可能OkHttp帶給大家的應(yīng)該還是無盡的等待了。

還能干嗎？

其實優(yōu)化方面我的大概的姿勢點就這么多了，但是我們可以考慮從監(jiān)控方面的角度去再重新審視這個話題哦。客戶端請求從發(fā)起到網(wǎng)關(guān)實際接收到，其實中間有很復(fù)雜的鏈路，簡單的說，OKhttp內(nèi)也走過了這么多個攔截器了。但是當(dāng)一個線上用戶反饋這個界面怎么刷出來的這么慢的情況下，我們以后端網(wǎng)關(guān)開始作為請求的開始節(jié)點，就會出現(xiàn)難以定位真實問題的情況。

基于OkHttp的網(wǎng)絡(luò)監(jiān)控

我們是不是可以考慮把整個api發(fā)起到結(jié)束進行監(jiān)控，從而可以方便線上去監(jiān)控一個Api真實的發(fā)起到結(jié)束的狀況呢？我們先簡單的把一個請求的節(jié)點拆分下。我要盜圖了。

參考數(shù)據(jù)深入理解OkHttp3：（七）事件（Events）

總結(jié)

這篇文章基本就存粹是為了各位應(yīng)付面試用的，也算是我對于Android網(wǎng)絡(luò)優(yōu)化的一些簡單的總結(jié)吧。其實中間能展開的內(nèi)容也還是有的，就是需要各位自己去摸一摸了。