[[414087]]

前言小計

在移動互聯(lián)網(wǎng)的快速發(fā)展環(huán)境下，手機用戶日益對網(wǎng)絡(luò)的使用或體驗有著更深度的訴求，因此應用中的網(wǎng)絡(luò)體驗已經(jīng)顯得由此重要;

網(wǎng)絡(luò)影響：

1.最直觀的就是用戶交互體驗;

2.流量的流失;

3.電量的消耗;

上篇文章介紹了網(wǎng)絡(luò)請求過程中dns，本文主要針對Android上網(wǎng)絡(luò)優(yōu)化

一、網(wǎng)絡(luò)數(shù)據(jù)緩存優(yōu)化

提供一種將數(shù)據(jù)存儲到本地的思想，實現(xiàn)減少服務(wù)器的請求負荷、加快請求速度、無網(wǎng)也能顯示內(nèi)容;

(1)對于常訪問的數(shù)據(jù)或首頁數(shù)據(jù)，盡量緩存在本地，加載時優(yōu)先加載本地數(shù)據(jù)，然后在請求網(wǎng)絡(luò)數(shù)據(jù)，更新頁面并更新緩存;

(2)在網(wǎng)絡(luò)丟失或者網(wǎng)絡(luò)差需要保存數(shù)據(jù)時， 網(wǎng)數(shù)據(jù)保存在本地，并且把發(fā)出的請求添加到隊列中，當網(wǎng)絡(luò)恢復的時候再及時發(fā)出;

(3) 強制緩存：在緩存數(shù)據(jù)未失效的情況下，可以直接使用緩存數(shù)據(jù)，由兩個字段Expires和Cache-Control用于標明失效規(guī)則;

(4)對比緩存：表示需要和服務(wù)端進行相關(guān)信息的對比，由服務(wù)器決定是使用緩存還是最新內(nèi)容，如果服務(wù)器判定使用緩存，返回響應嗎304，判定使用最新內(nèi)容，則返回響應碼200和最新數(shù)據(jù);

(5)okhttp上的緩存設(shè)置

進行數(shù)據(jù)緩存，我們可以在返回上加上過期時間，避免重新獲取。這種做法節(jié)約了流量，且大幅提高數(shù)據(jù)訪問的速度，增強了用戶體驗。在OKHTTP與Volley等一些網(wǎng)絡(luò)框架中都有很好的實踐;

下面進行OKHTTP，在無網(wǎng)絡(luò)的情況下使用cache進行緩存

public class NoNetInterceptor implements Interceptor { 
    @Override 
    public Response intercept(Chain chain) throws IOException { 
        Request request = chain.request(); 
        Request.Builder builder = request.newBuilder(); 
        if(!Utils.isNetworkConnected(PerformanceApp.getApplication())){ 
            builder.cacheControl(CacheControl.FORCE_CACHE); 
        } 
        return chain.proceed(builder.build()); 
    } 
} 
 static { 
        OkHttpClient.Builder client = new OkHttpClient.Builder(); 
        HttpLoggingInterceptor logging = new HttpLoggingInterceptor(); 
        logging.setLevel(HttpLoggingInterceptor.Level.BODY); 
        Cache cache = new Cache(PerformanceApp.getApplication().getCacheDir(),10*1024*1024); 
        client. 
                cache(cache). 
                eventListenerFactory(OkHttpEventListener.FACTORY). 
                dns(OkHttpDNS.getIns(PerformanceApp.getApplication())). 
                addInterceptor(new NoNetInterceptor()). 
                addInterceptor(logging); 
        final Retrofit RETROFIT = new Retrofit.Builder() 
                .baseUrl(HTTP_SPORTSNBA_QQ_COM) 
                .addConverterFactory(FastJsonConverterFactory.create()) 
                .client(client.build()) 
                .build(); 
        API_SERVICE = RETROFIT.create(APIService.class); 
    } 

二、dns優(yōu)化和httpdns

1、dns解析流程

• 在App內(nèi)用域名發(fā)送請求都要經(jīng)過DNS解析出ip，然后再根據(jù)ip去拿對應的資源，這個過程中，如果LocalDNS中存在這個域名對應的ip，就會直接返回這個ip，類似于App內(nèi)做緩存;
• 如果不存在，才會去權(quán)威DNS查詢改訪問哪個ip，然后查詢到的ip會在LocalDNS中做緩存。也就是說，如果我們要訪問新浪http://api.weibo.cn，如果LocalDNS里面有該域名對應的ip，就直接返回了ip了。

2、問題分析

• 一個新用戶使用來訪問api.weibo.cn，由于localDNS緩存的存在，不會去查詢新浪的權(quán)威DNS，這樣返回的ip是聯(lián)通這個運營商的ip，從而會使得用戶出現(xiàn)訪問變慢等狀況;
• 緩存還會導致一點就是，當權(quán)威DNS將域名與ip的映射發(fā)生改變之后，由于LocalDNS緩存沒有及時改變，用戶就會訪問到錯誤的服務(wù)器，或者直接訪問不到資源;
• 很多三四級運營商會把運營解析指向他們的緩存服務(wù)器上，并把網(wǎng)頁里面的廣告替換成他們自己的，或者內(nèi)嵌他們自己的廣告(之前做的APP出現(xiàn)過這樣的情況，投訴之后會好上一段時間，但是過段時間又會出現(xiàn)廣告);
• 竟然DNS解析存在問題，那有沒有一種調(diào)度精準、成本低廉、配置方便的基于域名的流量調(diào)度系統(tǒng)呢?
• HttpDNS基于Http協(xié)議和域名解析的流量調(diào)度解決方案，可以在很大程度上防止上面的問題出現(xiàn);

3、HttpDNS 概念

• 客戶端直接訪問HttpDNS接口，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP;
• 客戶端向獲取到的IP后就向直接往此IP發(fā)送業(yè)務(wù)協(xié)議請求。以Http請求為例，通過在header中指定host字段，向HttpDNS返回的IP發(fā)送標準的Http請求即可;
• 采用HttpDNS來解析域名，就繞過了三四級運營商解析域名會出現(xiàn)的問題，在HttpDNS返回了正確的ip之后，我們是直接采用ip去進行http請求，只需要關(guān)注通信內(nèi)容的安全即可;

4、HTTPDNS 工作模式

• 在客戶端的 SDK 里動態(tài)請求服務(wù)端，獲取 HTTPDNS 服務(wù)器的 IP 列表，緩存到本地。隨著不斷地解析域名，SDK 也會在本地緩存 DNS 域名解析的結(jié)果;
• 當手機應用要訪問一個地址的時候，首先看是否有本地的緩存，如果有就直接返回。這個緩存和本地 DNS 的緩存不一樣的是，這個是手機應用自己做的，而非整個運營商統(tǒng)一做的。如何更新、何時更新，手機應用的客戶端可以和服務(wù)器協(xié)調(diào)來做這件事情;
• 如果本地沒有，就需要請求 HTTPDNS 的服務(wù)器，在本地 HTTPDNS 服務(wù)器的IP 列表中，選擇一個發(fā)出 HTTP 的請求，會返回一個要訪問的網(wǎng)站的 IP 列表;

請求的方式是這樣的。

http://106.2.xxx.xxx/d?dn=c.m.163.com 
{"dns":[{"host":"c.m.163.com","ips":["223.252.199.12"],"ttl":300,"http2":0}],"client":{"ip":"106.2.81.50","line":269692944}} 

手機客戶端自然知道手機在哪個運營商、哪個地址。由于是直接的 HTTP 通信，HTTPDNS 服務(wù)器能夠準確知道這些信息，因而可以做精準的全局負載均衡;

5、HttpDNS緩存設(shè)計

• HTTPDNS 的緩存設(shè)計策略也是咱們做應用架構(gòu)中常用的緩存設(shè)計模式，也即分為客戶端、緩存、數(shù)據(jù)源三層，分別對應 SDK 客戶端、本地緩存、HTTPDNS 服務(wù)器;
• App內(nèi)維護一個Serve IP List。把每次App從HttpDNS取到的ip存儲進入該數(shù)組，并設(shè)置權(quán)重，理論上來說從HttpDns解析下來的ip權(quán)重是最大的。這個List可以在App啟動的時候，進行更新，同時取出本地緩存的Serve IP List的權(quán)重最大的ip進行數(shù)據(jù)的初始化操作(如果第一次啟動，沒有該List的話，就使用LocalDNS進行解析);
• Serve IP List里面的權(quán)重設(shè)置機制，很明顯的一點就是從DNS解析出來的ip具有最大的權(quán)重，每次從List里面取ip應該要取權(quán)重最大的ip。列表中的ip也是需要可以動態(tài)更新配置的，根據(jù)連接或者服務(wù)的成功失敗來進行動態(tài)調(diào)整，這樣即使DNS解析失敗，用戶在一段時間后也會取到合適的ip進行訪問;
• 對ip進行數(shù)據(jù)統(tǒng)計。在所有app內(nèi)統(tǒng)計每個ip進行請求所需平均時間、最長時間、最短時間、請求成功次數(shù)、失敗次數(shù)，需要注意的是，要區(qū)分網(wǎng)絡(luò)環(huán)境進行統(tǒng)計，Wifi、4G、3G，對在不同的網(wǎng)絡(luò)環(huán)境下數(shù)據(jù)優(yōu)秀的ip進行存儲，下發(fā)到App里面使用起來。這樣每次啟動App時可以對收集起來的ip根據(jù)不同的網(wǎng)絡(luò)環(huán)境進行測速，選擇最好的ip進行請求。需要注意的是，在網(wǎng)絡(luò)環(huán)境切換的時候，必須要重新進行速度測試。做到這一步，可以節(jié)約DNS解析時間，以及劫持的問題;
• SDK 中的緩存會嚴格按照緩存過期時間，如果緩存沒有命中，或者已經(jīng)過期，而且客戶端不允許使用過期的記錄，則會發(fā)起一次解析，保障記錄是更新的;

6、HTTPDNS調(diào)度設(shè)計

• 在客戶端，可以知道手機是哪個國家、哪個運營商、哪個省，甚至哪個市，HTTPDNS服務(wù)端可以根據(jù)這些信息，選擇最佳的服務(wù)節(jié)點返回;
• 如果有多個節(jié)點，還會考慮錯誤率、請求時間、服務(wù)器壓力、網(wǎng)絡(luò)狀況等，進行綜合選擇，而非僅僅考慮地理位置。當有一個節(jié)點宕機或者性能下降的時候，可以盡快進行切換;
• 要做到這一點，需要客戶端使用 HTTPDNS 返回的 IP 訪問業(yè)務(wù)應用。客戶端的 SDK 會收集網(wǎng)絡(luò)請求數(shù)據(jù)，如錯誤率、請求時間等網(wǎng)絡(luò)請求質(zhì)量數(shù)據(jù)，并發(fā)送到統(tǒng)計后臺，進行分析、聚合，以此查看不同的 IP 的服務(wù)質(zhì)量;
• 在服務(wù)端，應用可以通過調(diào)用 HTTPDNS 的管理接口，配置不同服務(wù)質(zhì)量的優(yōu)先級、權(quán)重。HTTPDNS 會根據(jù)這些策略綜合地理位置和線路狀況算出一個排序，優(yōu)先訪問當前那些優(yōu)質(zhì)的、時延低的 IP 地址;
• HTTPDNS 通過智能調(diào)度之后返回的結(jié)果，也會緩存在客戶端。為了不讓緩存使得調(diào)度失真，客戶端可以根據(jù)不同的移動網(wǎng)絡(luò)運營商 WIFI 的 SSID 來分維度緩存。不同的運營商或者 WIFI 解析出來的結(jié)果會不同;

7、OKHttp 接入 HTTPDNS

OkHttp 中使用 HTTPDNS，有兩種方式：

通過攔截器，在發(fā)送請求之前，將域名替換為 IP 地址;

通過 OkHttp 提供的 .dns() 接口，配置 HTTPDNS;

①攔截器接入

攔截器是 OkHttp 中，非常強大的一種機制，它可以在請求和響應之間，做一些我們的定制操作;

在 OkHttp 中，可以通過實現(xiàn) Interceptor 接口，來定制一個攔截器。使用時，只需要在 OkHttpClient.Builder 中，調(diào)用 addInterceptor() 方法來注冊此攔截器即可;

class HTTPDNSInterceptor : Interceptor{ 
    override fun intercept(chain: Interceptor.Chain): Response { 
        val originRequest = chain.request() 
        val httpUrl = originRequest.url() 
        val url = httpUrl.toString() 
        val host = httpUrl.host() 
        val hostIP = HttpDNS.getIpByHost(host) 
        val builder = originRequest.newBuilder() 
        if(hostIP!=null){ 
            builder.url(HttpDNS.getIpUrl(url,host,hostIP)) 
            builder.header("host",hostIP) 
        } 
        val newRequest = builder.build() 
        val newResponse = chain.proceed(newRequest) 
        return newResponse 
    } 

在攔截器中，使用 HttpDNS 這個幫助類，通過 getIpByHost() 將 Host 轉(zhuǎn)為對應的 IP;

②OKHttp 標準 API 接入

OkHttp 其實本身已經(jīng)暴露了一個 Dns 接口，默認的實現(xiàn)是使用系統(tǒng)的 InetAddress 類，發(fā)送 UDP 請求進行 DNS 解析;

我們只需要實現(xiàn) OkHttp 的 Dns 接口，即可獲得 HTTPDNS 的支持。

在我們實現(xiàn)的 Dns 接口實現(xiàn)類中，解析 DNS 的方式，換成 HTTPDNS，將解析結(jié)果返回;

class HttpDns : Dns { 
    override fun lookup(hostname: String): List<InetAddress> { 
        val ip = HttpDnsHelper.getIpByHost(hostname) 
        if (TextUtils.isEmpty(ip)) { 
            //返回自己解析的地址列表 
            return InetAddress.getAllByName(ip).toList()  
        } else { 
            // 解析失敗，使用系統(tǒng)解析 
            return Dns.SYSTEM.lookup(hostname) 
        } 
    } 
} 
mOkHttpClient = httpBuilder 
        .dns(HttpDns()) 
        .build(); 

三、數(shù)據(jù)傳輸優(yōu)化

客戶端與服務(wù)端經(jīng)常進行著頻繁的數(shù)據(jù)傳輸，而數(shù)據(jù)傳輸又影響著用戶體驗，提出合理的優(yōu)化建議

1、傳統(tǒng)的傳輸方案

在開始的時候，采用的是xml傳輸，這就要使用到Serializable/Parcelable序列化以及反序列化，其傳輸速度之慢，基本已經(jīng)被遺棄，后來又出現(xiàn)了JSON序列化傳輸，其常用工具就是GSON和fastjson，但隨著時代的進步，json也體現(xiàn)出了局限性json的局限性主要體現(xiàn)在其是基于字符串的傳輸，在轉(zhuǎn)換的時候會生成大量JsonObject，然后轉(zhuǎn)化為字符串，送進流里面，然后傳輸，在服務(wù)端也要從流中取出，然后反序列化，一大堆繁瑣的過程，其也漸漸不適合當今傳輸數(shù)據(jù)的要求;

2、新的數(shù)據(jù)傳輸方式

• 現(xiàn)在有如下選擇可以用Protocal Buffers：強大，靈活，但是對內(nèi)存的消耗會比較大，并不是移動終端上的最佳選擇;
• Nano-Proto-Buffers：基于Protocal，為移動終端做了特殊的優(yōu)化，代碼執(zhí)行效率更高，內(nèi)存使用效率更佳;
• FlatBuffers：這個開源庫最開始是由Google研發(fā)的，專注于提供更優(yōu)秀的性能;

如下圖：

FlatBuffers幾乎從空間和時間復雜度上完勝其他技術(shù)

FlatBuffers是一個開源的跨平臺數(shù)據(jù)序列化庫，可以應用到幾乎任何語言(C++,C#,Go,Java,JavaScript,PHP,Python)，最開始是Google為游戲或者其他對性能要求很高的應用開發(fā)的;

FlatBuffer的優(yōu)點

FlatBuffer相對于其他序列化技術(shù)，例如XML，JSON，Protocol Buffers等，有哪些優(yōu)勢呢?官方文檔的說法如下：

• 直接讀取序列化數(shù)據(jù)，而不需要解析(Parsing)或者解包(Unpacking)：FlatBuffer把數(shù)據(jù)層級結(jié)構(gòu)保存在一個扁平化的二進制緩存(一維數(shù)組)中，同時能夠保持直接獲取里面的結(jié)構(gòu)化數(shù)據(jù)，而不需要解析，并且還能保證數(shù)據(jù)結(jié)構(gòu)變化的前后向兼容;
• 高效的內(nèi)存使用和速度：FlatBuffer 使用過程中，不需要額外的內(nèi)存，幾乎接近原始數(shù)據(jù)在內(nèi)存中的大小;
• 靈活：數(shù)據(jù)能夠前后向兼容，并且能夠靈活控制你的數(shù)據(jù)結(jié)構(gòu)
• 很少的代碼侵入性：使用少量的自動生成的代碼即可實現(xiàn);
• 強數(shù)據(jù)類性，易于使用，跨平臺，幾乎語言無關(guān);
• JSON是Android中很常用的數(shù)據(jù)序列化技術(shù)，但卻很消耗內(nèi)存，而FlatBuffer正好解決了這個問題，性能還更好了;

3、對于 Post 請求，Body 是用 Gzip 壓縮的，也就是請求的時候帶上 Gzip 請求頭，服務(wù)端返回的時候也加上 Gzip 壓縮，這樣數(shù)據(jù)流就是被壓縮過的。

四、網(wǎng)絡(luò)其他優(yōu)化

1、網(wǎng)絡(luò)分級請求

(1)將網(wǎng)絡(luò)分成移動網(wǎng)絡(luò)、寬帶網(wǎng)絡(luò)、強網(wǎng)絡(luò)、弱網(wǎng)絡(luò)，不同的網(wǎng)絡(luò)環(huán)境對請求進行不同的處理，例如在移動網(wǎng)絡(luò)下需要進行下載任務(wù)時，停止或提示用戶，在弱網(wǎng)絡(luò)下對圖片的請求的區(qū)分等;

(2) 網(wǎng)絡(luò)狀態(tài)可以由TelephonyManager.getNetworkType()方法獲取到;

(3)對下載和上傳文件采用斷點續(xù)傳功能，不浪費用戶之前耗費的時間和流量;

2、流量使用優(yōu)化

(1)局部更新 、分頁加載;

(2) 數(shù)據(jù)加載采用增量，有更新數(shù)據(jù)時才請求新數(shù)據(jù)，合并客戶端舊數(shù)據(jù);

(3)盡量避免客戶端輪詢，采用服務(wù)端推送方式;

3、請求數(shù)據(jù)優(yōu)化

(1)合并請求,可以將多個請求合并成一個接口請求

(2)壓縮請求數(shù)據(jù)

(3)精簡數(shù)據(jù)格式，只取需要的數(shù)據(jù)字段

4、連接優(yōu)化

• 啟用keep-alive，okhttp中已默認打開，但需要服務(wù)器支持;
• 使用http2，使用keep-alive來緩存，通過http2來復用請求連接;
• 復用連接池可以減少多個網(wǎng)絡(luò)請求下的連接建立的消耗，而且OkHttp已經(jīng)默認幫我們實現(xiàn)了這些功能;
• 復用連接的前提是同ip通道，如果每個請求都發(fā)送給不同的ip，那么連接池也復用不了;
• 非Http2的使用完連接后(就是Http請求完成后)，我們需要手動 關(guān)閉RealCall，否則下層代碼就要通過觸發(fā)GC回收來幫我們檢查和關(guān)閉;
• 切換不同的域名，當一個連接失敗的時候用另一個域名進行連接;

總結(jié)

1、傳統(tǒng)的 DNS 有很多問題，例如解析慢、更新不及時。因為緩存、轉(zhuǎn)發(fā)、NAT問題導致客戶端誤會自己所在的位置和運營商，從而影響流量的調(diào)度;

2、HTTPDNS 通過客戶端 SDK 和服務(wù)端，通過 HTTP 直接調(diào)用解析 DNS 的方式，繞過了傳統(tǒng) DNS 的這些缺點，實現(xiàn)了智能的調(diào)度;

3、關(guān)于連接優(yōu)化還有很多知識點，后續(xù)整理出來會發(fā)表出;

4、優(yōu)化部分我們講解了網(wǎng)絡(luò)相關(guān)的，下次會整理出圖片相關(guān)的知識點，一起學習一起進步，加油;

本文轉(zhuǎn)載自微信公眾號「Android開發(fā)編程」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系A(chǔ)ndroid開發(fā)編程公眾號。