自己最近也在看《Professional iOS Network Programming》，理論結合實踐劣光，可以好好地總結一把App在移動網(wǎng)絡下的調優(yōu)的那些事。
相對于有線網(wǎng)絡剖踊，移動網(wǎng)絡有如下的特性：帶寬低脸秽，延遲高，丟包率高掌动，穩(wěn)定性差四啰。3G網(wǎng)絡的帶寬一般為下行100-200KB/S，上行10-100KB/S粗恢，延遲0-400ms柑晒，帶寬方面基本逼近2M有線網(wǎng)絡，但延遲較高眷射，穩(wěn)定性不夠匙赞。而2G更是慘不忍睹：一般只有10KB/S下行和1KB/S左右的上行速度，延遲基本不低于400ms妖碉，網(wǎng)絡環(huán)境不好時甚至有數(shù)秒的延遲涌庭。下面針對這些情況給出個人總結的八條網(wǎng)絡優(yōu)化的小貼士。
1-在有條件的情況下盡量使用IP而非域名進行連接
對于有線網(wǎng)絡來說DNS查詢可能是一件不費吹灰之力的事嗅绸，但是對于移動網(wǎng)絡來說卻不是這樣脾猛，一次DNS查詢的耗時甚至都能趕得上一次連接的耗時。于是在有條件的情況下鱼鸠，緩存服務器IP地址和端口猛拴，并盡量使用IP進行連接是個好的選擇。另一個原因是中國移動的DNS服務相當不靠譜蚀狰，錯誤率極高(傳聞出錯率在60%以上)愉昆。我們就碰到過幾次某個地段的童鞋使用移動2G總是無法解析域名的情況。
2-減少不必要的連接請求
大多數(shù)的移動網(wǎng)絡(3G)并不允許一個給定IP地址超過兩個的并發(fā)HTTP請求麻蹋，既當你有兩個針對同一個地址的連接時跛溉，再發(fā)起的第三個連接總是會超時。而2G網(wǎng)絡下這個限定為1個。(詳見這里 )同一時間發(fā)起過多的網(wǎng)絡請求不僅不會起到加速的效果芳室，反而有副作用专肪。另一方面，由于網(wǎng)絡連接很是費時堪侯，保持和共享某一條連接就是一個不錯的選擇：比如短時間內多次的HTTP請求嚎尤。
3-合理的超時時間
過短的超時容易導致連接超時的事情頻頻發(fā)生，甚至一直無法連接伍宦，而過長的超時則會帶來等待時間過長芽死，體驗差的問題。就目前來看次洼，對于普通的TCP連接30秒是個不錯的超時值关贵，而Http請求可以按照重要性和當前網(wǎng)絡情況動態(tài)調整超時，盡量將超時控制在一個合理的數(shù)值內卖毁，以提高單位時間內網(wǎng)絡的利用率揖曾。
4-減少網(wǎng)絡請求
使用一種有效的傳輸格式和壓縮網(wǎng)絡請求/反饋是兩種行之有效的方法。前者主要應用于使用自定義協(xié)議的場景：用protobuf明顯會比json/xml更省流量势篡；而后者多出現(xiàn)在Http相關的場景翩肌，比如使用gzip對Http請求和反饋進行壓縮模暗。
5-使用緩存
其實這也算是對貼士4的補充：在本地有有效數(shù)據(jù)的情況下直接不發(fā)起網(wǎng)絡請求禁悠。配置文件，資源文件兑宇，描述文件碍侦，幾乎所有的文件都可以成為我們緩存的對象，而大部分涉及到網(wǎng)絡相關的iOS第三方庫都提供了極其方便的緩存方法隶糕，程序員唯一需要考慮的就只有緩存容量和過期時間的問題瓷产。
6-使用斷點上傳和分段上傳
一方面可以在重新傳輸時省去已傳輸數(shù)據(jù)的流量，而另一方面將文件分成幾個請求上傳可以盡量減少傳輸中的包大小枚驻，避免高丟包率環(huán)境導致TCP包丟包重傳甚至失敗濒旦，保證傳輸?shù)某晒β?當然也減低了效率)。
7-平衡網(wǎng)絡延遲和帶寬的影響
對于移動網(wǎng)絡這種高延遲低帶寬的情況再登，需要綜合考慮進行平衡配置：在一個固定網(wǎng)絡下尔邓，當包大小小于1500字節(jié)時(一個TCP的Payload)，網(wǎng)絡延遲的影響基本是一個常數(shù)锉矢，此時網(wǎng)絡延遲的影響主要體現(xiàn)在請求次數(shù)上梯嗽，所以合并多個小請求到一個包內是一個合理且有效的做法。而在包大小超過1500字節(jié)后沽损，隨著包大小的增加灯节，延遲的影響會越來越小，但相應的帶寬的影響會越來越大。
8-合理地選擇加密
對于信息安全來說炎疆，最理想的狀態(tài)是所有的請求都是通過加密的卡骂。這對于PC來說并不是一個問題，但是對于電量資源有限的移動端來說卻是一個需要好好權衡的問題：網(wǎng)絡傳輸中加密的使用增加了CPU的負擔同時也激活了其他資源形入，這將導致電量更快地被損耗偿警。對于非機密的信息比如圖片資源，描述資源就完全可以不進行任何加密唯笙。
更多關于網(wǎng)絡優(yōu)化的方法或解決方案可以回復我Ｃ簟！
