一、使用httpDNS優(yōu)化DNS解析和緩存
一般來(lái)說(shuō)在App內(nèi)用域名發(fā)送請(qǐng)求都要經(jīng)過(guò)DNS解析出ip，然后再根據(jù)ip去拿對(duì)應(yīng)的資源，這個(gè)過(guò)程中，如果LocalDNS中存在這個(gè)域名對(duì)應(yīng)的ip，就會(huì)直接返回這個(gè)ip，類似于App內(nèi)做緩存。如果不存在，才會(huì)去權(quán)威DNS查詢改訪問(wèn)哪個(gè)ip，然后查詢到的ip會(huì)在LocalDNS中做緩存。也就是說(shuō)，如果我們要訪問(wèn)新浪http://api.weibo.cn，如果LocalDNS里面有該域名對(duì)應(yīng)的ip，就直接返回了ip了。（DNS基礎(chǔ)知識(shí)：http://www.itdecent.cn/p/a73e963b63b1）
1、這里存在兩個(gè)問(wèn)題
如果之前訪問(wèn)api.weibo.cn的是聯(lián)通用戶，現(xiàn)在新用戶使用電信來(lái)訪問(wèn)api.weibo.cn，由于localDNS緩存的存在，不會(huì)去查詢新浪的權(quán)威DNS，這樣返回的ip是聯(lián)通這個(gè)運(yùn)營(yíng)商的ip，從而會(huì)使得用戶出現(xiàn)訪問(wèn)變慢等狀況。緩存還會(huì)導(dǎo)致一點(diǎn)就是，當(dāng)權(quán)威DNS將域名與ip的映射發(fā)生改變之后，由于LocalDNS緩存沒(méi)有及時(shí)改變，用戶就會(huì)訪問(wèn)到錯(cuò)誤的服務(wù)器，或者直接訪問(wèn)不到資源。
很多三四級(jí)運(yùn)營(yíng)商會(huì)把運(yùn)營(yíng)解析指向他們的緩存服務(wù)器上，并把網(wǎng)頁(yè)里面的廣告替換成他們自己的，或者內(nèi)嵌他們自己的廣告。（之前做的APP出現(xiàn)過(guò)這樣的情況，投訴之后會(huì)好上一段時(shí)間，但是過(guò)段時(shí)間又會(huì)出現(xiàn)廣告）。
竟然DNS解析存在問(wèn)題，那有沒(méi)有一種調(diào)度精準(zhǔn)、成本低廉、配置方便的基于域名的流量調(diào)度系統(tǒng)呢？答案是肯定的。HttpDNS基于Http協(xié)議和域名解析的流量調(diào)度解決方案，可以在很大程度上防止上面的問(wèn)題出現(xiàn)。
HttpDNS原理：
A、客戶端直接訪問(wèn)HttpDNS接口，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問(wèn)延遲最優(yōu)的IP。（基于容災(zāi)考慮，app內(nèi)肯定是需要保留使用運(yùn)營(yíng)商LocalDNS解析域名方式的。）
B、客戶端向獲取到的IP后就向直接往此IP發(fā)送業(yè)務(wù)協(xié)議請(qǐng)求。以Http請(qǐng)求為例，通過(guò)在header中指定host字段，向HttpDNS返回的IP發(fā)送標(biāo)準(zhǔn)的Http請(qǐng)求即可。
總的來(lái)說(shuō)，采用HttpDNS來(lái)解析域名，就繞過(guò)了三四級(jí)運(yùn)營(yíng)商解析域名會(huì)出現(xiàn)的問(wèn)題，在HttpDNS返回了正確的ip之后，我們是直接采用ip去進(jìn)行http請(qǐng)求，只需要關(guān)注通信內(nèi)容的安全即可。
2、基于HttpDNS擴(kuò)展
A、在App內(nèi)維護(hù)一個(gè)Serve IP List。把每次App從HttpDNS取到的ip存儲(chǔ)進(jìn)入該數(shù)組，并設(shè)置權(quán)重，理論上來(lái)說(shuō)從HttpDns解析下來(lái)的ip權(quán)重是最大的。這個(gè)List可以在App啟動(dòng)的時(shí)候，進(jìn)行更新，同時(shí)取出本地緩存的Serve IP List的權(quán)重最大的ip進(jìn)行數(shù)據(jù)的初始化操作（如果第一次啟動(dòng)，沒(méi)有該List的話，就使用LocalDNS進(jìn)行解析）。
Serve IP List里面的權(quán)重設(shè)置機(jī)制，很明顯的一點(diǎn)就是從DNS解析出來(lái)的ip具有最大的權(quán)重，每次從List里面取ip應(yīng)該要取權(quán)重最大的ip。列表中的ip也是需要可以動(dòng)態(tài)更新配置的，根據(jù)連接或者服務(wù)的成功失敗來(lái)進(jìn)行動(dòng)態(tài)調(diào)整，這樣即使DNS解析失敗，用戶在一段時(shí)間后也會(huì)取到合適的ip進(jìn)行訪問(wèn)。
B、對(duì)ip進(jìn)行數(shù)據(jù)統(tǒng)計(jì)。在所有app內(nèi)統(tǒng)計(jì)每個(gè)ip進(jìn)行請(qǐng)求所需平均時(shí)間、最長(zhǎng)時(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里面使用起來(lái)。這樣每次啟動(dòng)App時(shí)可以對(duì)收集起來(lái)的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í)間，以及劫持的問(wèn)題。
C、將圖片、音頻等資源放到單獨(dú)的服務(wù)器里面，與其他資源分開(kāi)。
第一個(gè)是多個(gè)域名可以增加并行下載條數(shù)，因?yàn)榭蛻舳藢?duì)同一個(gè)域的域名下載條數(shù)是有限制的，所以多個(gè)域就會(huì)增加并行下載條數(shù)，從而加快加載速度。當(dāng)然二級(jí)域名也不能使用太多，因?yàn)樘嘁紤]到dns的解析花費(fèi)的時(shí)間。
第二個(gè)是方便管理，一般來(lái)說(shuō)，圖片在站點(diǎn)的加載中是最占帶寬的，可以用獨(dú)立服務(wù)器方便后期管理；還可以使用異步加載的方式，增強(qiáng)用戶體驗(yàn)。同時(shí)是圖片多是靜態(tài)內(nèi)容，可以更好的使用CDN加速。
第三是如果使用了獨(dú)立服務(wù)器的話，在安全設(shè)置上可以有差別的針對(duì)設(shè)置，很是方便。
D、在防止劫持這一塊，需要注意把資源的后綴名去掉，比如說(shuō).mp3\.json這樣的后綴，以免擊中運(yùn)營(yíng)商的攔截。
二、資源優(yōu)化
資源優(yōu)化基本就是盡可能的縮小傳輸數(shù)據(jù)的大小，首先是圖片大小的解決方案。
1、在一定程度上使用webp來(lái)代替jpg、png圖片
上圖就是各種圖片同等質(zhì)量下的大小，其中webp是最小的。當(dāng)我們下載圖片展示的時(shí)候，如果在一定程度上使用webp圖片，就能大大減少用戶流量的損失，以及下載圖片的所需時(shí)間。
一般來(lái)說(shuō)，會(huì)在App內(nèi)固定使用幾種尺寸來(lái)做展示圖，比如說(shuō)，banner圖是640*640，cell展示圖可能是320*320、280*280，類似頭像的可能是80*80等。需要注意的是，webp的圖片要通過(guò)解析才能成為可用的jpg圖片，在iOS開(kāi)發(fā)中，可以使用SDWebImage框架進(jìn)行解析，webp->NSData->Image，app內(nèi)解析是肯定需要花費(fèi)一定時(shí)間和性能的。
根據(jù)實(shí)際使用的反饋情況，發(fā)現(xiàn)在wifi條件下，超過(guò)300*300的圖片使用webp圖片，解析時(shí)間+下載時(shí)間是比直接使用jpg\png圖片要快的，并且在流量方面也是消耗很小。低于300*300的可以直接下載使用jpg\png圖片。
在4G條件下，用戶可能會(huì)對(duì)流量比較敏感，建議都走webp圖片。
2、可以使用ProtocolBuffer代替Json進(jìn)行數(shù)據(jù)傳輸
Protocolbuffer(簡(jiǎn)稱Protobuf或PB)是由Google推出的一種數(shù)據(jù)交換格式，它獨(dú)立于語(yǔ)言，獨(dú)立于平臺(tái)。Google 提供了三種語(yǔ)言的實(shí)現(xiàn)：java、c++ 和 python，每一種實(shí)現(xiàn)都包含了相應(yīng)語(yǔ)言的編譯器以及庫(kù)文件?？梢园阉糜诜植际綉?yīng)用之間的數(shù)據(jù)通信或者異構(gòu)環(huán)境下的數(shù)據(jù)交換。與傳統(tǒng)的XML和JSON不同的是，它是一種二進(jìn)制格式，免去了文本格式轉(zhuǎn)換的各種困擾，并且轉(zhuǎn)換效率非常快，由于它的跨平臺(tái)、跨編程語(yǔ)言的特點(diǎn)，讓它越來(lái)越普及，尤其是網(wǎng)絡(luò)數(shù)據(jù)交換方面日趨成為一種主流。
在tcp中，我們可以使用?ProtocolBuffer代替Json進(jìn)行數(shù)據(jù)傳輸，因?yàn)镻rotocolBuffer數(shù)據(jù)比Json更小，也是跨平臺(tái)的，序列號(hào)與反序列化也很簡(jiǎn)單。在實(shí)際項(xiàng)目中，當(dāng)數(shù)據(jù)變小的時(shí)候會(huì)顯著提高傳輸速度。
