絕大多數網絡請求的第一步都是DNS解析，解析請求根據當時網絡情況不同，各平臺的DNS緩存策略差異等因素，對移動端app整體網絡性能會產生或大或小的影響。移動端app網絡性能優化涉及到很多方面，DNS映射只是其中一環，也是十分重要的一環，因為它帶來的好處不僅僅是降低網絡請求的延遲。
降低DNS請求帶來的延遲
客戶端app的請求第一步都是DNS解析，但由于cache的存在使得大部分的解析請求并不會產生任何延遲。各品臺都有自己的cache過期策略。像iOS系統一般是24小時之后會過期，還有進入飛行模式再切回來，開關機，重置網絡設置等也會導致DNS cache的清除。所以一般情況下用戶在第二天打開你的app都會經歷一次完整的DNS解析請求，網絡情況差的時候會明顯增加應用請求的總耗時。如果能直接跳過DNS解析這一步，當然能提升網絡性能了。
預防DNS劫持
DNS劫持指的是改變DNS請求的返回結果，將目的ip指向另一個地址。一般有兩種方式，一是通過病毒的方式改變本機配置的DNS服務器地址，而是通過攻擊正常DNS服務器而改變其行為。不管是哪種方式，都會影響app本身的業務請求。如果遇到惡意的攻擊還會衍生出各種安全問題?？蛻舳俗约鹤鯠NS與ip地址的映射就跨過了解析，讓劫持者無從下手。
服務器動態部署
DNS映射實際是模擬了DNS請求的解析行為。如果客戶端將自己的位置信息諸如ip地址，國家碼等加入映射文件的請求參數當中，服務器就可以根據客戶端所處的位置不同，下發距離其物理位置最近的server ip地址，從而減小整體網絡請求的延遲，實現一定程度的服務器動態部署。
如何設計自己的DNS映射機制？
DNS解析請求簡單來說，無非是輸入一個域名，輸出一個ip地址。做自己的映射機制也就是客戶端本地維護這樣一個映射文件，只不過這個映射文件需要能從服務器更新，還要做一些容錯處理。我們先從這幾個基本要求出發制定下面幾個必須滿足的需求。
一個打包到app包里面的默認映射文件，這樣可以避免第一次去服務器取配置文件帶來的延遲。
有一個定時器能每隔一段時間從服務器獲取最新的映射，并覆蓋本地。
每次取到最新的映射文件之后，同時把上一次的映射文件保存起來作為替補，一旦出現線上配置失誤不至于導致請求無法處理。
如果映射文件不能處理域名，要能回滾使用默認的DNS解析服務。
如果一個映射過后的ip持續導致請求失敗，應該能從機制上保證這個ip地址不再使用。也就是需要一個無效映射淘汰機制。
無效的ip地址能及時上報到服務器，及時發現問題更新映射文件。
基于這些基本需求，可以做出如下簡單的設計：
大致有3個角色，mapper，validator，reporter。各自職責如下：
mapper
mapper是和外部交互的部分，主要負責在輸入domain的情況下輸出ip，同時還要檢測來自應用層請求成功和失敗的信息。失敗的情況下要將失敗的ip進行進一步的檢測，以確定是否真的是ip地址無效，如果無效則進行上報。mapper還要負責從mapper文件的更新機制。
validator
validator在接受到請求失敗的ip時，要負責對這個ip做進一步的有效性檢測。檢測規則的強弱可自己定制。但一般來說流程在后臺線程使用這個地址做多次連接嘗試。如果失敗則告訴mapper這個地址確實無效。如果成功則表明這個地址有效，很有可能只是當時的網絡環境導致了請求的失敗。
reporter
reporter主要負責告訴server整個mapping機制的健康狀況。在出現某個ip經過validator檢測依然失敗的情況下，要及時的告訴server出問題的ip。很有可能出現了某個服務器故障或者映射文件的配置失誤等等。
在上面這些基礎需求之外，還可以根據自身的業務特點及技術條件做一些深度定制。比如從服務器定期更新映射文件，可以改成socket長鏈接通道在需要更新時push，或者利用http2.0的server push機制。還有上報機制，除了上報錯誤的ip地址映射之外，還可以對請求的總量，成功率，映射成功率等數據進行偵測。
PPDNSMapping
PPDNSMapping是根據以上設計原則所做的iOS平臺例子，附有測試demo代碼。
PPDNSMappingManager對應圖一當中的mapper，PPIPValidator對應validator，PPDNSReporter對應reporter。
github地址
貌似因為蘋果在6月份之前要求所有上架的APP要兼容IPv6，所以IP直連貌似不可行了..
