[[414087]]

前言小計(jì)

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

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

1.最直觀的就是用戶交互體驗(yàn);

2.流量的流失;

3.電量的消耗;

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

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

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

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

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

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

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

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

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

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

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

2、問題分析

• 一個(gè)新用戶使用來訪問api.weibo.cn，由于localDNS緩存的存在，不會(huì)去查詢新浪的權(quán)威DNS，這樣返回的ip是聯(lián)通這個(gè)運(yùn)營商的ip，從而會(huì)使得用戶出現(xiàn)訪問變慢等狀況;
• 緩存還會(huì)導(dǎo)致一點(diǎn)就是，當(dāng)權(quán)威DNS將域名與ip的映射發(fā)生改變之后，由于LocalDNS緩存沒有及時(shí)改變，用戶就會(huì)訪問到錯(cuò)誤的服務(wù)器，或者直接訪問不到資源;
• 很多三四級(jí)運(yùn)營商會(huì)把運(yùn)營解析指向他們的緩存服務(wù)器上，并把網(wǎng)頁里面的廣告替換成他們自己的，或者內(nèi)嵌他們自己的廣告(之前做的APP出現(xiàn)過這樣的情況，投訴之后會(huì)好上一段時(shí)間，但是過段時(shí)間又會(huì)出現(xiàn)廣告);
• 竟然DNS解析存在問題，那有沒有一種調(diào)度精準(zhǔn)、成本低廉、配置方便的基于域名的流量調(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é)議請(qǐng)求。以Http請(qǐng)求為例，通過在header中指定host字段，向HttpDNS返回的IP發(fā)送標(biāo)準(zhǔn)的Http請(qǐng)求即可;
• 采用HttpDNS來解析域名，就繞過了三四級(jí)運(yùn)營商解析域名會(huì)出現(xiàn)的問題，在HttpDNS返回了正確的ip之后，我們是直接采用ip去進(jìn)行http請(qǐng)求，只需要關(guān)注通信內(nèi)容的安全即可;

4、HTTPDNS 工作模式

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

請(qǐng)求的方式是這樣的。

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}} 

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

5、HttpDNS緩存設(shè)計(jì)

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

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

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

7、OKHttp 接入 HTTPDNS

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

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

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

①攔截器接入

攔截器是 OkHttp 中，非常強(qiáng)大的一種機(jī)制，它可以在請(qǐng)求和響應(yīng)之間，做一些我們的定制操作;

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

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 這個(gè)幫助類，通過 getIpByHost() 將 Host 轉(zhuǎn)為對(duì)應(yīng)的 IP;

②OKHttp 標(biāo)準(zhǔn) API 接入

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

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

在我們實(shí)現(xiàn)的 Dns 接口實(shí)現(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)常進(jìn)行著頻繁的數(shù)據(jù)傳輸，而數(shù)據(jù)傳輸又影響著用戶體驗(yàn)，提出合理的優(yōu)化建議

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

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

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

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

如下圖：

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

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

FlatBuffer的優(yōu)點(diǎn)

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

• 直接讀取序列化數(shù)據(jù)，而不需要解析(Parsing)或者解包(Unpacking)：FlatBuffer把數(shù)據(jù)層級(jí)結(jié)構(gòu)保存在一個(gè)扁平化的二進(jìn)制緩存(一維數(shù)組)中，同時(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)
• 很少的代碼侵入性：使用少量的自動(dòng)生成的代碼即可實(shí)現(xiàn);
• 強(qiáng)數(shù)據(jù)類性，易于使用，跨平臺(tái)，幾乎語言無關(guān);
• JSON是Android中很常用的數(shù)據(jù)序列化技術(shù)，但卻很消耗內(nèi)存，而FlatBuffer正好解決了這個(gè)問題，性能還更好了;

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

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

1、網(wǎng)絡(luò)分級(jí)請(qǐng)求

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

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

(3)對(duì)下載和上傳文件采用斷點(diǎn)續(xù)傳功能，不浪費(fèi)用戶之前耗費(fèi)的時(shí)間和流量;

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

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

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

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

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

(1)合并請(qǐng)求,可以將多個(gè)請(qǐng)求合并成一個(gè)接口請(qǐng)求

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

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

4、連接優(yōu)化

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

總結(jié)

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

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

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

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

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