網路優化篇-如何大幅度提高端上性能

前言

       今天要跟你們聊得是，如何大幅度提高端上網絡的性能。端上網絡性能怎麼樣，主要由兩個指標來衡量，響應時間和成功率。響應時間指的是 從發起請求到接收到響應的時間。而成功率指的是，成功請求數(非異常)/總請求數。

       相信你們的app中都有統計這些數據，那麼，你端上的響應時間夠短麼，請求成功率夠高麼。

爲何響應慢

       咱們來想一下，端上的接口響應時間爲何慢呢？首先，咱們先看一下，一次http請求要經歷什麼樣的過程。

1. DNS解析出IP
2. 三次握手創建鏈接
3. 數據序列化、傳輸
4. 後端處理、返回
5. 反序列化

       上面是一個比較粗糙的過程，你們簡單看下就行。那麼，咱們來簡單分析一下。

       DNS解析快麼？在網絡優化篇-從DNS開始 這篇文章中，已經分析過DNS解析了，事實證實，DNS解析是漫長的，尤爲在端上，有時長達幾百ms。

       三次握手快麼？快，也不快。你想一想，即便是在有鏈接池優化的前提下，整個應用的生命週期內仍是要通過無數次三次握手，那麼，最好的方式是什麼呢？一次鏈接，處處使用。

       序列化、反序列化、包壓縮暫時不在咱們今天的考慮範圍內。

成功率爲何低

       端上的網絡請求不免遇到超時，鏈接失敗，IO異常，DNS解析異常等等多種錯誤狀況。當你在遇到這些狀況時，沒有補救措施，固然成功率低了。

引入長連接

       在知道了種種緣由以後，咱們引入了長連接。將網絡請求經過長連接發送到後端gateway，後端gateway進行轉發便可。以OkHttp爲例，咱們能夠很輕鬆的使用攔截器，將網絡請求攔截下來，而後經過長連接發送出去。須要注意的是，這個攔截器要加在ConnectInterceptor以前。

這是一個轉換器接口的例子，功能是將Http協議的Request轉換爲長鏈協議的Request，將長鏈協議的Response轉化爲Http協議的Response。

public interface CoreConvert<U, D> {

  CoreHttpRequest convertToU(U request);

  D convertToD(U request, CoreHttpResponse response);
}
複製代碼

       作了這些就夠了麼？不夠，遠遠不夠，咱們還須要作兩件事。1. 互備 2. 動態調整。

長連接和Http互相兜底

       誰都沒法保證長連接必定可靠，也沒法保證http短連接可靠。所以，咱們還須要作的是，當一種鏈路出現問題的時候，切換到另外一種鏈路重試一下。這樣，能夠減小失敗率，經過這種方式，咱們端上的成功率從92%提高到了99%+，提高很是明顯

動態調整

       那麼，這裏指的動態調整是什麼呢？雖然咱們引入了長連接，理論上長連接要比http短連接快不少，可是，事實卻不必定是這個樣子。所謂的動態調整，指的是咱們不斷的經過相應時間去分析出長連接和短連接的質量，而後選擇讓api請求走短連接仍是長連接。經過這樣不斷的調整，可以幫助咱們在鏈路選擇上，自動調度到比較好的鏈路中，提高網絡質量。

最後

整篇下來，可能理論偏多，可是這一套理論已經在咱們目前的端上驗證了很長時間，事實證實，是可行的。而且改形成本不高，對業務無感知，零侵入。

以爲寫的還行的朋友能夠關注如下個人微信公衆號，這裏用於交流一些Android基礎架構、疑難雜症、面試等等問題。