DNS查找時間
可以使用的工具
$ dig www.baidu.com
$ traceroute www.baidu.com
最小化應用使用的專有域名的數量
如果子域名數量上升至兩位數,我們需要仔細考慮這方面的優化了
冷啓動時不必要鏈接的域名
對於後續的子域名,嘗試更早的進行DNS解析,也被稱爲
DNS預先下載
DNS預先下載
可以參考以下兩種方法:
如果子域名和主機在控制範圍內,可以配置一個預設的URL,不返回任何數據,只返回
HTTP 204
的狀態碼。(對主機進行僞鏈接)使用
gethostbyname
執行一個明確的DNS
查找。
建議使用第一種方法,針對不同的協議
gethostbyname
可能會解析至不同的IP
,雖然這很不常見,但第7層的路由可以根據實際的請求解析IP
地址,例如,圖像是一個地址,視頻時另外一個地址。
SSL握手時間
如果應用中所有連接均是通過 TLS/SSL
的(使用HTTPS
)
最大程度減少應用發起的連接數,也需要減少應用連接的獨有域名的數量
請求結束後不要關閉
HTTP/S
連接爲所有的
HTTP/S
的請求添加頭Connection: keep-alive
這確保了同樣的連接在下一次請求時可以複用
使用域分片
- > 域分片在
SPDY
及其後續版本HTTP/2
中時可用的
網絡類型
確保主機的可到達性
可使用的工具:可到達性庫: Reachability
- WiFi
- 4G:
LTE
,HSPA+
- 3G:
HSDPA
,HSUPA
,UMTS
,DMA2000
- 2G:
EDGE
,GPRS
設計時考慮不同的網絡可用性
出現失敗時,
在隨機的,以指數增長的延遲後進行重試
設置強制刷新之間的最短時間
在用戶明確要求刷新時,不要立即發出請求。檢查是否已經存在一個請求,或者當前請求與上次請求的時間間隔是否小於閾值
如果滿足上述條件,則不要發送此次請求
使用可到達性庫: Reachability 發現網絡狀態變化
發現網絡不可用時,向用戶提示。通過讓用戶瞭解潛在的連接問題,可以避免應用受到指責
不要緩存網絡狀態
基於網絡類型下載內容
比如說圖片,不用總下載原始的、高質量的圖像。應該始終下載和設備最適配的圖像
樂觀的預下載
在WiFi網絡中,預先下載用戶在後續時刻需要的內容。
最好分次下載內容,在使用後關掉網絡連接,有助於節省電量
如果適用,當網絡可用時,
支持同步的離線存儲
總是要將網絡和通信與UI
解耦
延遲
需要追蹤以下數據
- 連接超時
- 響應超時
- 載荷大小
網絡API
你可能需要掌握
網絡任務的暫停,停止和重新啓動
每個會話的存儲(緩存,cookie jar 等)
後臺聯網的好處
身份驗證
異步方法
數據格式和數據壓縮
工具
dig
traceroute
網絡鏈接調節器
Charles
AT&T