導(dǎo)言
這一節(jié)目標(biāo)著眼于常見的網(wǎng)絡(luò)請(qǐng)求方面的優(yōu)化
基礎(chǔ)
首先分析一個(gè)網(wǎng)絡(luò)請(qǐng)求的基本過程
1.創(chuàng)建一個(gè)請(qǐng)求坎藐，然后在工作線程中執(zhí)行
2.對(duì)域名進(jìn)行DNS解析，然后進(jìn)行連接能颁，其中TCP連接要完成三次握手杂瘸，如果是HTTPS的話也要完成TLS握手
3.連接完成后往輸入流中寫入數(shù)據(jù)，然后等待服務(wù)端往輸出流中寫入數(shù)據(jù)
4.服務(wù)端處理完業(yè)務(wù)邏輯伙菊，將數(shù)據(jù)寫入輸出流中
5.客戶端接收到數(shù)據(jù)败玉，進(jìn)行后期處理，然后回到主線程中處理
基于以上的步驟镜硕，考慮一下優(yōu)化的方案
準(zhǔn)備
首先考慮第一步运翼，網(wǎng)絡(luò)請(qǐng)求要在工作線程中進(jìn)行，那么線程的執(zhí)行數(shù)量必然會(huì)收到限制兴枯，同樣的血淌，為了不限制性能，請(qǐng)不要使用AsyncTask和HandlerThread模型财剖，但是請(qǐng)求串行處理會(huì)降低效率悠夯，最明顯的就是當(dāng)執(zhí)行到一個(gè)速度較慢的接口會(huì)直接拖慢整體的運(yùn)行效率
1.線程數(shù)受限，要求并發(fā)請(qǐng)求接口不宜過多躺坟，同時(shí)因?yàn)橐恍┖笈_(tái)任務(wù)的執(zhí)行沦补，所以考慮CPU核心數(shù)-1會(huì)合適一點(diǎn)
2.非單核手機(jī)不應(yīng)該串行執(zhí)行網(wǎng)絡(luò)請(qǐng)求，否則很容易出現(xiàn)卡頓的情況
3.初始任務(wù)也應(yīng)該放入工作線程中執(zhí)行瞳氓，比方說參數(shù)的拼接獲取策彤、加解密操作等等，因?yàn)檫@些操作往往會(huì)大于16.67ms執(zhí)行時(shí)間
4.從性能上面來說匣摘，應(yīng)該要求接口盡可能的少店诗，也就是要合并接口，此外這也是一個(gè)耗電問題音榜，網(wǎng)絡(luò)請(qǐng)求本身是一個(gè)耗電操作
DNS解析
第二步中提到要對(duì)DNS進(jìn)行一個(gè)解析操作庞瘸，這是因?yàn)閟ocket連接維度是基于IP地址和端口，比方說HTTP默認(rèn)就是80端口赠叼，而HTTPS就是443端口
傳統(tǒng)的DNS解析模式為客戶端向運(yùn)營(yíng)商DNS發(fā)起域名解析請(qǐng)求擦囊，然后DNS返回IP地址违霞，之后客戶端再通過IP和端口發(fā)起連接
從這塊進(jìn)行優(yōu)化的技術(shù)為HTTPDNS，具體可以看下面的地址瞬场，講的非常詳細(xì)
https://github.com/CNSRE/HTTPDNSLib
大致總結(jié)一下：
1.要防止本地DNS劫持买鸽。本地在第一次訪問DNS服務(wù)器得到結(jié)果的時(shí)候，也是會(huì)在本地緩存一份IP映射表贯被，這樣做是為了在下一次獲取的時(shí)候提速眼五，所以說這里存在劫持或者緩存過期的問題（同樣，自己的HTTPDNS也會(huì)有這個(gè)問題彤灶，不過可以在劫持方面做一些努力看幼，會(huì)相對(duì)好一些）
2.降低延時(shí)，提高用戶的體驗(yàn)幌陕。IP分配類似CDN的思想诵姜，比方說按照片區(qū)劃分，這樣深圳的用戶能夠就近訪問廣州機(jī)房的機(jī)器搏熄，而不是去訪問廈門的機(jī)器棚唆，這樣也會(huì)快不少
3.降低失敗率。簡(jiǎn)單說就是提供多一種手段來處理心例，比方說先用HTTPDNS瑟俭，失敗后再用本地DNS處理，都失敗那就沒辦法了
TCP和TLS握手及TCP慢啟動(dòng)問題
建立一次HTTPS的連接契邀，必須做這么幾件事情，首先是TCP的三次握手失暴，然后就是TLS的握手流程
現(xiàn)代IM基于長(zhǎng)連接坯门，很大的一個(gè)優(yōu)點(diǎn)就是去除了大量的握手操作，從而加快了數(shù)據(jù)傳輸
這一點(diǎn)在OkHttp中也有體現(xiàn)逗扒，OkHttp會(huì)嘗試重用連接古戴，從而減少重復(fù)的TCP握手
這可以看OkHttp閱讀筆記（四）
并且TCP具有慢啟動(dòng)的特點(diǎn)，在之前已經(jīng)使用過的前提下矩肩，再次使用效率也會(huì)較之前的更好
所以說在一些頻繁使用的場(chǎng)景下现恼，比方說日志上報(bào)、IM這塊使用持續(xù)連接會(huì)更好
結(jié)果處理
等服務(wù)端成功返回?cái)?shù)據(jù)之后黍檩，客戶端需要對(duì)數(shù)據(jù)進(jìn)行解密等一系列的操作叉袍，這一塊考慮如下：
1.返回后的統(tǒng)一處理，比方說利用GSON序列化數(shù)據(jù)為對(duì)象刽酱，這類型的操作大約為500ms以上級(jí)別的操作喳逛，要考慮這個(gè)操作是在當(dāng)前網(wǎng)絡(luò)線程中執(zhí)行或者在額外的工作線程中再執(zhí)行，如果要求網(wǎng)絡(luò)執(zhí)行快的話棵里，那么建議利用其余線程處理润文，這樣可以使得當(dāng)前線程被快速重用到其余等待執(zhí)行的網(wǎng)絡(luò)請(qǐng)求
2.數(shù)據(jù)處理完畢之后姐呐，有的操作實(shí)際上是沒有必要回到主線程中的，或者說有的操作過于簡(jiǎn)單典蝌，都不需要調(diào)度線程曙砂，因?yàn)檎{(diào)度線程還是有一定的開銷的，所以說網(wǎng)絡(luò)庫(kù)要具備靈活處理回調(diào)后結(jié)果的能力
結(jié)語(yǔ)
這一節(jié)只是一些基礎(chǔ)的處理方式骏掀，也是一個(gè)基本的網(wǎng)路封裝的考量
