Android 網絡優化方案

（給安卓開發精選加星標）

轉自：掘金-究極逮蝦戶

https://juejin.cn/post/6896302142542315533

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

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

面試官：ok，看來是有備而來，那麼我們今天聊聊網絡優化咋做吧。

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

如何優化一個網絡請求呢？

相信大家在面試的時候可能會被問到這個問題。今天我其實就是講述下我知道的一些簡單的優化方式，可以幫助大家在面試的過程中得到點基礎分數。

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

DNS優化

DNS則是典型的應用層的協議了，至於說為什麼第二層能查第三層的IP，因為DNS是Domain Name System縮寫，所以你認為是服務是協1653議都可以。

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

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

如果你的網絡層用的是OkHttp的話，Okhttp在封裝的時候就已經考慮到這個部分了，其內部提供了Dns的接口，可以讓外部在構造Client的時候傳入。

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，就是這個服務是收錢的。

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

CacheControl

Http請求在1.1階段就引入了CacheControl了，通過CacheControl可以讓後端直接控制請求內容的緩存策略。所以還有比緩存更簡單粗暴的網絡優化方式嗎？
在http中，控制緩存開關的欄位有兩個：Pragma 和 Cache-Control。
通過圖片簡單的介紹下一些緩存參數。

如果說一句不負責任的話，這個只要後端大佬開啟CacheControl就好了呀，原生網絡庫本來就支持的。當然後端大佬一般都不是特別願意，其實各位安卓也可以通過添加OkHttp攔截器的方式給網絡請求添加一個統一的CacheControl，當然如果你有定製化的需求肯定還是要自己開發的，我這裡只負責科普下這個面試可以回答的地方，細節大家可以參考下這個倉庫。

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請求。

Http 1.0 - 1.1 - 1.X - 2.0

以下所有內容均來自網絡 HTTP1.0、HTTP1.1 和 HTTP2.0 的區別

當然我們還可以讓後端升級接口協議版本，這個可以明顯提升你請求響應性能。

長連接，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格式，所以其不僅僅是網絡層上的優化，同時由於流能直接轉化成實體類，同時也減少了可序列化的時間。
protocol buffers 是一種語言無關、平臺無關、可擴展的序列化結構數據的方法，它可用於（數據）通信協議、數據存儲等。
Protocol Buffers 是一種靈活，高效，自動化機制的結構數據序列化方法－可類比 XML，但是比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更為簡單。
你可以定義數據的結構，然後使用特殊生成的原始碼輕鬆的在各種數據流中使用各種語言進行編寫和讀取結構數據。你甚至可以更新數據結構，而不破壞由舊數據結構編譯的已部署程序。
但是正常的網絡框架基本都使用了Retrofit+Okhttp，而且大家都已經使用的很習慣了，所以我大膽的猜測，字節其實應該用OkHttp橋接了cronet。所以這樣基本就能無縫橋接當前已有的網絡庫了。

由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帶給大家的應該還是無盡的等待了。

還能幹嗎？

其實優化方面我的大概的姿勢點就這麼多了，但是我們可以考慮從監控方面的角度去再重新審視這個話題哦。客戶端請求從發起到網關實際接收到，其實中間有很複雜的鏈路，簡單的說，OKhttp內也走過了這麼多個攔截器了。但是當一個線上用戶反饋這個界面怎麼刷出來的這麼慢的情況下，我們以後端網關開始作為請求的開始節點，就會出現難以定位真實問題的情況。

基於OkHttp的網絡監控

我們是不是可以考慮把整個api發起到結束進行監控，從而可以方便線上去監控一個Api真實的發起到結束的狀況呢？我們先簡單的把一個請求的節點拆分下。我要盜圖了。
參考數據深入理解OkHttp3：（七）事件（Events）
基於OKHttp提供的EventListener，我們就可以對於一個請求發起到最後的各個節點進行監控，之後上報日誌數據，這樣在後續的撕逼過程中，其實就可以做到有理有據，有話可說，你真的慢了。

總結

這篇文章基本就存粹是為了各位應付面試用的，也算是我對於Android網絡優化的一些簡單的總結吧。其實中間能展開的內容也還是有的，就是需要各位自己去摸一摸了。

- EOF -


看完本文有收穫？請分享給更多人
 推薦關注「安卓開發精選」，提升安卓開發技術
點讚和在看就是最大的支持❤️