自己最近也在看《Professional iOS Network Programming》，理論結(jié)合實(shí)踐，可以好好地總結(jié)一把App在移動(dòng)網(wǎng)絡(luò)下的調(diào)優(yōu)的那些事。
相對(duì)于有線網(wǎng)絡(luò)，移動(dòng)網(wǎng)絡(luò)有如下的特性：帶寬低，延遲高，丟包率高，穩(wěn)定性差。3G網(wǎng)絡(luò)的帶寬一般為下行100-200KB/S，上行10-100KB/S，延遲0-400ms，帶寬方面基本逼近2M有線網(wǎng)絡(luò)，但延遲較高，穩(wěn)定性不夠。而2G更是慘不忍睹：一般只有10KB/S下行和1KB/S左右的上行速度，延遲基本不低于400ms，網(wǎng)絡(luò)環(huán)境不好時(shí)甚至有數(shù)秒的延遲。下面針對(duì)這些情況給出個(gè)人總結(jié)的八條網(wǎng)絡(luò)優(yōu)化的小貼士。
1-在有條件的情況下盡量使用IP而非域名進(jìn)行連接
對(duì)于有線網(wǎng)絡(luò)來(lái)說(shuō)DNS查詢可能是一件不費(fèi)吹灰之力的事，但是對(duì)于移動(dòng)網(wǎng)絡(luò)來(lái)說(shuō)卻不是這樣，一次DNS查詢的耗時(shí)甚至都能趕得上一次連接的耗時(shí)。于是在有條件的情況下，緩存服務(wù)器IP地址和端口，并盡量使用IP進(jìn)行連接是個(gè)好的選擇。另一個(gè)原因是中國(guó)移動(dòng)的DNS服務(wù)相當(dāng)不靠譜，錯(cuò)誤率極高(傳聞出錯(cuò)率在60%以上)。我們就碰到過(guò)幾次某個(gè)地段的童鞋使用移動(dòng)2G總是無(wú)法解析域名的情況。
2-減少不必要的連接請(qǐng)求
大多數(shù)的移動(dòng)網(wǎng)絡(luò)(3G)并不允許一個(gè)給定IP地址超過(guò)兩個(gè)的并發(fā)HTTP請(qǐng)求，既當(dāng)你有兩個(gè)針對(duì)同一個(gè)地址的連接時(shí)，再發(fā)起的第三個(gè)連接總是會(huì)超時(shí)。而2G網(wǎng)絡(luò)下這個(gè)限定為1個(gè)。(詳見(jiàn)這里 )同一時(shí)間發(fā)起過(guò)多的網(wǎng)絡(luò)請(qǐng)求不僅不會(huì)起到加速的效果，反而有副作用。另一方面，由于網(wǎng)絡(luò)連接很是費(fèi)時(shí)，保持和共享某一條連接就是一個(gè)不錯(cuò)的選擇：比如短時(shí)間內(nèi)多次的HTTP請(qǐng)求。
3-合理的超時(shí)時(shí)間
過(guò)短的超時(shí)容易導(dǎo)致連接超時(shí)的事情頻頻發(fā)生，甚至一直無(wú)法連接，而過(guò)長(zhǎng)的超時(shí)則會(huì)帶來(lái)等待時(shí)間過(guò)長(zhǎng)，體驗(yàn)差的問(wèn)題。就目前來(lái)看，對(duì)于普通的TCP連接30秒是個(gè)不錯(cuò)的超時(shí)值，而Http請(qǐng)求可以按照重要性和當(dāng)前網(wǎng)絡(luò)情況動(dòng)態(tài)調(diào)整超時(shí)，盡量將超時(shí)控制在一個(gè)合理的數(shù)值內(nèi)，以提高單位時(shí)間內(nèi)網(wǎng)絡(luò)的利用率。
4-減少網(wǎng)絡(luò)請(qǐng)求
使用一種有效的傳輸格式和壓縮網(wǎng)絡(luò)請(qǐng)求/反饋是兩種行之有效的方法。前者主要應(yīng)用于使用自定義協(xié)議的場(chǎng)景：用protobuf明顯會(huì)比json/xml更省流量；而后者多出現(xiàn)在Http相關(guān)的場(chǎng)景，比如使用gzip對(duì)Http請(qǐng)求和反饋進(jìn)行壓縮。
5-使用緩存
其實(shí)這也算是對(duì)貼士4的補(bǔ)充：在本地有有效數(shù)據(jù)的情況下直接不發(fā)起網(wǎng)絡(luò)請(qǐng)求。配置文件，資源文件，描述文件，幾乎所有的文件都可以成為我們緩存的對(duì)象，而大部分涉及到網(wǎng)絡(luò)相關(guān)的iOS第三方庫(kù)都提供了極其方便的緩存方法，程序員唯一需要考慮的就只有緩存容量和過(guò)期時(shí)間的問(wèn)題。
6-使用斷點(diǎn)上傳和分段上傳
一方面可以在重新傳輸時(shí)省去已傳輸數(shù)據(jù)的流量，而另一方面將文件分成幾個(gè)請(qǐng)求上傳可以盡量減少傳輸中的包大小，避免高丟包率環(huán)境導(dǎo)致TCP包丟包重傳甚至失敗，保證傳輸?shù)某晒β?當(dāng)然也減低了效率)。
7-平衡網(wǎng)絡(luò)延遲和帶寬的影響
對(duì)于移動(dòng)網(wǎng)絡(luò)這種高延遲低帶寬的情況，需要綜合考慮進(jìn)行平衡配置：在一個(gè)固定網(wǎng)絡(luò)下，當(dāng)包大小小于1500字節(jié)時(shí)(一個(gè)TCP的Payload)，網(wǎng)絡(luò)延遲的影響基本是一個(gè)常數(shù)，此時(shí)網(wǎng)絡(luò)延遲的影響主要體現(xiàn)在請(qǐng)求次數(shù)上，所以合并多個(gè)小請(qǐng)求到一個(gè)包內(nèi)是一個(gè)合理且有效的做法。而在包大小超過(guò)1500字節(jié)后，隨著包大小的增加，延遲的影響會(huì)越來(lái)越小，但相應(yīng)的帶寬的影響會(huì)越來(lái)越大。
8-合理地選擇加密
對(duì)于信息安全來(lái)說(shuō)，最理想的狀態(tài)是所有的請(qǐng)求都是通過(guò)加密的。這對(duì)于PC來(lái)說(shuō)并不是一個(gè)問(wèn)題，但是對(duì)于電量資源有限的移動(dòng)端來(lái)說(shuō)卻是一個(gè)需要好好權(quán)衡的問(wèn)題：網(wǎng)絡(luò)傳輸中加密的使用增加了CPU的負(fù)擔(dān)同時(shí)也激活了其他資源，這將導(dǎo)致電量更快地被損耗。對(duì)于非機(jī)密的信息比如圖片資源，描述資源就完全可以不進(jìn)行任何加密。
更多關(guān)于網(wǎng)絡(luò)優(yōu)化的方法或解決方案可以回復(fù)我！！
