一覆旱、使用httpDNS優(yōu)化DNS解析和緩存
一般來說在App內(nèi)用域名發(fā)送請求都要經(jīng)過DNS解析出ip，然后再根據(jù)ip去拿對應的資源核无，這個過程中扣唱，如果LocalDNS中存在這個域名對應的ip，就會直接返回這個ip团南，類似于App內(nèi)做緩存噪沙。如果不存在，才會去權威DNS查詢改訪問哪個ip吐根，然后查詢到的ip會在LocalDNS中做緩存正歼。也就是說，如果我們要訪問新浪http://api.weibo.cn拷橘，如果LocalDNS里面有該域名對應的ip局义，就直接返回了ip了。（DNS基礎知識：http://www.reibang.com/p/a73e963b63b1）
1冗疮、這里存在兩個問題
如果之前訪問api.weibo.cn的是聯(lián)通用戶萄唇，現(xiàn)在新用戶使用電信來訪問api.weibo.cn，由于localDNS緩存的存在赌厅，不會去查詢新浪的權威DNS穷绵，這樣返回的ip是聯(lián)通這個運營商的ip，從而會使得用戶出現(xiàn)訪問變慢等狀況特愿。緩存還會導致一點就是仲墨，當權威DNS將域名與ip的映射發(fā)生改變之后，由于LocalDNS緩存沒有及時改變揍障，用戶就會訪問到錯誤的服務器目养，或者直接訪問不到資源。
很多三四級運營商會把運營解析指向他們的緩存服務器上毒嫡，并把網(wǎng)頁里面的廣告替換成他們自己的癌蚁，或者內(nèi)嵌他們自己的廣告。（之前做的APP出現(xiàn)過這樣的情況，投訴之后會好上一段時間努释，但是過段時間又會出現(xiàn)廣告）碘梢。
竟然DNS解析存在問題，那有沒有一種調(diào)度精準伐蒂、成本低廉煞躬、配置方便的基于域名的流量調(diào)度系統(tǒng)呢？答案是肯定的逸邦。HttpDNS基于Http協(xié)議和域名解析的流量調(diào)度解決方案恩沛，可以在很大程度上防止上面的問題出現(xiàn)。
HttpDNS原理：
A缕减、客戶端直接訪問HttpDNS接口雷客，獲取業(yè)務在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP。（基于容災考慮桥狡，app內(nèi)肯定是需要保留使用運營商LocalDNS解析域名方式的搅裙。）
B、客戶端向獲取到的IP后就向直接往此IP發(fā)送業(yè)務協(xié)議請求总放。以Http請求為例呈宇，通過在header中指定host字段，向HttpDNS返回的IP發(fā)送標準的Http請求即可局雄。
總的來說甥啄，采用HttpDNS來解析域名，就繞過了三四級運營商解析域名會出現(xiàn)的問題炬搭，在HttpDNS返回了正確的ip之后蜈漓，我們是直接采用ip去進行http請求，只需要關注通信內(nèi)容的安全即可宫盔。
2融虽、基于HttpDNS擴展
A、在App內(nèi)維護一個Serve IP List灼芭。把每次App從HttpDNS取到的ip存儲進入該數(shù)組有额，并設置權重，理論上來說從HttpDns解析下來的ip權重是最大的彼绷。這個List可以在App啟動的時候巍佑，進行更新，同時取出本地緩存的Serve IP List的權重最大的ip進行數(shù)據(jù)的初始化操作（如果第一次啟動寄悯，沒有該List的話萤衰，就使用LocalDNS進行解析）。
Serve IP List里面的權重設置機制猜旬，很明顯的一點就是從DNS解析出來的ip具有最大的權重脆栋，每次從List里面取ip應該要取權重最大的ip倦卖。列表中的ip也是需要可以動態(tài)更新配置的，根據(jù)連接或者服務的成功失敗來進行動態(tài)調(diào)整椿争，這樣即使DNS解析失敗怕膛，用戶在一段時間后也會取到合適的ip進行訪問。
B丘薛、對ip進行數(shù)據(jù)統(tǒng)計嘉竟。在所有app內(nèi)統(tǒng)計每個ip進行請求所需平均時間邦危、最長時間洋侨、最短時間、請求成功次數(shù)倦蚪、失敗次數(shù)希坚，需要注意的是，要區(qū)分網(wǎng)絡環(huán)境進行統(tǒng)計陵且，Wifi裁僧、4G、3G慕购，對在不同的網(wǎng)絡環(huán)境下數(shù)據(jù)優(yōu)秀的ip進行存儲聊疲，下發(fā)到App里面使用起來。這樣每次啟動App時可以對收集起來的ip根據(jù)不同的網(wǎng)絡環(huán)境進行測速沪悲，選擇最好的ip進行請求获洲。需要注意的是，在網(wǎng)絡環(huán)境切換的時候殿如，必須要重新進行速度測試贡珊。做到這一步，可以節(jié)約DNS解析時間涉馁，以及劫持的問題门岔。
C、將圖片烤送、音頻等資源放到單獨的服務器里面寒随，與其他資源分開。
第一個是多個域名可以增加并行下載條數(shù)帮坚，因為客戶端對同一個域的域名下載條數(shù)是有限制的妻往，所以多個域就會增加并行下載條數(shù)，從而加快加載速度叶沛。當然二級域名也不能使用太多蒲讯，因為太多要考慮到dns的解析花費的時間。
第二個是方便管理灰署，一般來說判帮，圖片在站點的加載中是最占帶寬的局嘁，可以用獨立服務器方便后期管理；還可以使用異步加載的方式晦墙，增強用戶體驗悦昵。同時是圖片多是靜態(tài)內(nèi)容，可以更好的使用CDN加速晌畅。
第三是如果使用了獨立服務器的話但指，在安全設置上可以有差別的針對設置，很是方便抗楔。
D棋凳、在防止劫持這一塊，需要注意把資源的后綴名去掉连躏，比如說.mp3\.json這樣的后綴剩岳，以免擊中運營商的攔截。
二入热、資源優(yōu)化
資源優(yōu)化基本就是盡可能的縮小傳輸數(shù)據(jù)的大小拍棕，首先是圖片大小的解決方案。
1勺良、在一定程度上使用webp來代替jpg绰播、png圖片
上圖就是各種圖片同等質(zhì)量下的大小，其中webp是最小的尚困。當我們下載圖片展示的時候蠢箩，如果在一定程度上使用webp圖片，就能大大減少用戶流量的損失尾组，以及下載圖片的所需時間忙芒。
一般來說，會在App內(nèi)固定使用幾種尺寸來做展示圖讳侨，比如說呵萨，banner圖是640*640，cell展示圖可能是320*320跨跨、280*280潮峦，類似頭像的可能是80*80等。需要注意的是勇婴，webp的圖片要通過解析才能成為可用的jpg圖片忱嘹，在iOS開發(fā)中，可以使用SDWebImage框架進行解析耕渴，webp->NSData->Image拘悦，app內(nèi)解析是肯定需要花費一定時間和性能的。
根據(jù)實際使用的反饋情況橱脸，發(fā)現(xiàn)在wifi條件下础米，超過300*300的圖片使用webp圖片分苇，解析時間+下載時間是比直接使用jpg\png圖片要快的，并且在流量方面也是消耗很小屁桑。低于300*300的可以直接下載使用jpg\png圖片医寿。
在4G條件下，用戶可能會對流量比較敏感蘑斧，建議都走webp圖片靖秩。
2、可以使用ProtocolBuffer代替Json進行數(shù)據(jù)傳輸
Protocolbuffer(簡稱Protobuf或PB)是由Google推出的一種數(shù)據(jù)交換格式竖瘾，它獨立于語言沟突，獨立于平臺。Google 提供了三種語言的實現(xiàn)：java准浴、c++ 和 python事扭，每一種實現(xiàn)都包含了相應語言的編譯器以及庫文件±趾幔可以把它用于分布式應用之間的數(shù)據(jù)通信或者異構環(huán)境下的數(shù)據(jù)交換。與傳統(tǒng)的XML和JSON不同的是今野，它是一種二進制格式葡公，免去了文本格式轉(zhuǎn)換的各種困擾，并且轉(zhuǎn)換效率非程跛快催什，由于它的跨平臺、跨編程語言的特點宰睡，讓它越來越普及蒲凶，尤其是網(wǎng)絡數(shù)據(jù)交換方面日趨成為一種主流。
在tcp中拆内，我們可以使用?ProtocolBuffer代替Json進行數(shù)據(jù)傳輸旋圆，因為ProtocolBuffer數(shù)據(jù)比Json更小，也是跨平臺的麸恍，序列號與反序列化也很簡單灵巧。在實際項目中，當數(shù)據(jù)變小的時候會顯著提高傳輸速度抹沪。
