乙個網路請求可以簡單分為連線伺服器 -> 獲取資料兩個部分。
其中連線伺服器前還包括 dns 解析的過程；獲取資料後可能會對資料進行快取。
一、連線伺服器優化策略
1. 不用網域名稱，用 ip 直連
省去 dns 解析過程，dns 全名 domain name system，解析意指根據網域名稱得到其對應的 ip 位址。
如 www.codekk.com 的網域名稱解析結果就是 104.236.147.76。
首次網域名稱解析一般需要幾百毫秒，可通過直接向 ip 而非網域名稱請求，節省掉這部分時間，同時可以預防網域名稱劫持等帶來的風險。
當然為了安全和擴充套件考慮，這個 ip 可能是乙個動態更新的 ip 列表，並在 ip 不可用情況下通過網域名稱訪問。
2. 伺服器合理部署
伺服器多運營商多地部署，一般至少含三大運營商、南中北三地部署。
配合上面說到的動態 ip 列表，支援優先順序，每次根據地域、網路型別等選擇最優的伺服器 ip 進行連線。
對於伺服器端還可以調優伺服器的 tcp 擁塞視窗大小、重傳超時時間(rto)、最大傳輸單元(mtu)等。
二、獲取資料優化策略
1. 連線復用
節省連線建立時間，如開啟 keep-alive。
對於 android 來說預設情況下 httpurlconnection 和 httpclient 都開啟了 keep-alive。只是 2.2 之前 httpurlconnection 存在影響連線池的 bug，具體可見：android httpurlconnection 及 httpclient 選擇
2. 請求合併
即將多個請求合併為乙個進行請求，比較常見的就是網頁中的 css image sprites。
如果某個頁面內請求過多，也可以考慮做一定的請求合併。
3. 減小請求資料大小
(1) 對於 post 請求，body 可以做 gzip 壓縮，如日誌。
(2) 對請求頭進行壓縮
這個 http 1.1 不支援，spdy 及 http 2.0 支援。
http 1.1 可以通過服務端對前乙個請求的請求頭進行快取，後面相同請求頭用 md5 之類的 id 來表示即可。
4. cdn 快取靜態資源
快取常見的、js、css 等靜態資源。
5. 減小返回資料大小
(1) 壓縮
一般 api 資料使用 gzip 壓縮，下圖是之前測試的 gzip 壓縮前後對比圖。
(3) 對於不同的裝置不同網路返回不同的內容
如不同解析度大小。
(4) 增量更新
需要資料更新時，可考慮增量更新。如常見的服務端進行 bsdiff，客戶端進行 bspatch。
6. 資料快取
快取獲取到的資料，在一定的有效時間內再次請求可以直接從快取讀取資料。
關於 http 快取規則 grumoon 在 volley 原始碼解析最後雜談中有詳細介紹。
三、其他優化手段
這類優化方式在效能優化系列總篇中已經有過完整介紹
1. 預取
包括預連線、預取資料。
2. 分優先順序、延遲部分請求
將不重要的請求延遲，這樣既可以削峰減少併發、又可以和後面類似的請求做合併。
3. 多連線
四、監控
優化需要通過資料對比才能看出效果，所以監控系統必不可少，通過前後端的資料監控確定調優效果。
注：伺服器部署方面的優化有參考手 q 和 qzone 去年的技術分享。
**：
客戶端優化
from 輪迴mm 1.討厭的ie的濾鏡和css expressions少用，小心把瀏覽器搞掛，cup 100 宕機。2.css放到前面，js能放到後面的放在 後面。將頁面盡早展示給使用者。3.減少iframe的使用，避免cpu扛不住。4.減少dom個數，減低瀏覽器解析壓力。5.使用 而不是 imp...
客戶端優化經驗
從專案中積累了一些客戶端效能優化經驗 1.目前專案的在手機上跑，記憶體占用最大的是ui。在profile下看，一張2048的大圖集占用的記憶體比一張1024的圖集占用的記憶體要多出一倍，大概8m。所以優化方案是拆分圖集，把大圖集按功能分割成若干小圖集 做成1024 1024 把單獨的大圖獨自拉出來用...
Hbase客戶端優化
scan caching scanner一次快取多少資料來scan 從服務端一次抓多少資料回來scan 預設值是 1，一次只取一條。scan attribute selection scan時建議指定需要的column family，減少通訊量，否則scan操作缺省會返回整個row的所有資料 所有c...