在理想的世界第煮，網(wǎng)絡(luò)“只要運(yùn)行”就可以解幼。網(wǎng)絡(luò)連接是可靠的、快速的包警、低延時(shí)的撵摆。在真實(shí)的世界，網(wǎng)絡(luò)大多數(shù)時(shí)候是運(yùn)行的害晦，但它會(huì)斷特铝，它經(jīng)常以匪夷所思的方式斷開(kāi)。例如：

• 網(wǎng)絡(luò)鏈路過(guò)載或斷開(kāi)會(huì)導(dǎo)致數(shù)據(jù)包丟失壹瘟。如果鏈路丟失了一定數(shù)量的數(shù)據(jù)包鲫剿，則可能難以在這條鏈路上建立連接，并且性能會(huì)與你期望的相去甚遠(yuǎn)稻轨。
• 當(dāng)網(wǎng)絡(luò)鏈接飽和時(shí)灵莲，該鏈路兩側(cè)的路由會(huì)緩存數(shù)據(jù)流以避免丟失數(shù)據(jù)。這增加了額外的延時(shí)殴俱。在大量加載的DSL連接上看到幾秒鐘的延時(shí)并不罕見(jiàn)政冻。
• 捕獲（captive）網(wǎng)絡(luò)（通常用于賓館、咖啡店线欲、或其他公共場(chǎng)所）可以阻止軟件的HTTP請(qǐng)求明场，并提供一個(gè)登錄頁(yè)面來(lái)取代被期望的數(shù)據(jù)。
• 用戶和目標(biāo)之間的防火墻李丰，可能會(huì)阻止除少數(shù)端口外的所有其他連接苦锨。
• 執(zhí)行網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）的防火墻，可能不允許遠(yuǎn)程服務(wù)器連接用戶電腦或其他設(shè)備的端口。
• 第三方防火墻軟件可能阻止應(yīng)用的傳出連接請(qǐng)求逆屡，用以等待用戶允許圾旨。

雖然你的軟件不可能修復(fù)一個(gè)真正斷開(kāi)的網(wǎng)絡(luò)，但是糟糕的網(wǎng)絡(luò)代碼可以輕松地讓事情變得更加糟糕魏蔗。例如砍的，假設(shè)一個(gè)服務(wù)器嚴(yán)重超載，并且需要45秒才能響應(yīng)每個(gè)請(qǐng)求莺治。如果你的應(yīng)用連接到這個(gè)服務(wù)器設(shè)定了30秒超時(shí)廓鞠，它占用了服務(wù)器的資源，但是卻從沒(méi)有成功接收過(guò)任何數(shù)據(jù)谣旁。

甚至在網(wǎng)絡(luò)運(yùn)行良好的情況下床佳，糟糕的網(wǎng)絡(luò)代碼也會(huì)給用戶帶來(lái)問(wèn)題——電池壽命降低、性能差等等榄审。本章部分描述了無(wú)論是網(wǎng)絡(luò)條件是否理想砌们，應(yīng)用都應(yīng)該做到的事情，以便減輕用戶的痛苦搁进。

高效的使用電量和帶寬

在寫(xiě)網(wǎng)絡(luò)代碼的時(shí)候浪感，首先要考慮到的重要事情，是應(yīng)用無(wú)論何時(shí)上傳或下載數(shù)據(jù)饼问，它都會(huì)消耗用戶的時(shí)間和金錢(qián)影兽。

網(wǎng)絡(luò)操作消耗用戶時(shí)間是因?yàn)椋?/p>

• 用戶必須等待這個(gè)操作完成才能執(zhí)行其他任務(wù)。
• 數(shù)據(jù)傳輸經(jīng)常要求無(wú)線電保持活躍莱革。對(duì)于電池供電的設(shè)備峻堰，就減少用戶使用設(shè)備的時(shí)間。

網(wǎng)絡(luò)操作也消耗用戶的金錢(qián)是因?yàn)閹挷皇敲赓M(fèi)的盅视。這些花費(fèi)包括：

• 電能捐名。無(wú)線硬件（Wi-Fi、蜂窩網(wǎng)絡(luò)左冬、等等）消耗大量電能桐筏。無(wú)線硬件處于活動(dòng)狀態(tài)的時(shí)間越長(zhǎng)，就會(huì)越消耗電量拇砰。
• 實(shí)際數(shù)據(jù)傳輸梅忌。很多用戶（特別是蜂窩網(wǎng)絡(luò)用戶）會(huì)為它們的真實(shí)的數(shù)據(jù)傳輸付費(fèi)。應(yīng)用傳輸?shù)臄?shù)據(jù)越多除破，他們所花費(fèi)的錢(qián)越多牧氮。即使用戶使用統(tǒng)一費(fèi)率服務(wù)，ISP也會(huì)基于用戶的平均消耗帶寬來(lái)設(shè)置費(fèi)率瑰枫。
• 帶寬踱葛。無(wú)論用戶的網(wǎng)絡(luò)連接是按流量的還是按統(tǒng)一費(fèi)率丹莲，用戶通常會(huì)為更高的連接速度支付更高的費(fèi)率。

作為一個(gè)網(wǎng)絡(luò)軟件的開(kāi)發(fā)者尸诽，你有責(zé)任讓你的應(yīng)用的電量和帶寬的消耗最小化甥材。

批量傳輸，并盡可能的空閑

在編寫(xiě)通用代碼的時(shí)候性含，你應(yīng)該盡可能的執(zhí)行更多工作洲赵，然后返回到空閑狀態(tài)。這對(duì)于網(wǎng)絡(luò)活動(dòng)來(lái)說(shuō)是雙贏的商蕴。例如：

• 如果應(yīng)用從HTTP服務(wù)器接收流視頻片段叠萍，一次下載整個(gè)文件（或至少是文件的大部分）要比每次請(qǐng)求一小段要好。
• 如果應(yīng)用提供廣告绪商，一次下載多個(gè)廣告并在一段時(shí)間內(nèi)顯示他們苛谷，要比在需要的時(shí)候再下載要好。
• 如果應(yīng)用從服務(wù)器下載email格郁，基于假設(shè)用戶會(huì)閱讀大部分email腹殿，所以一次下載多封email要比在用戶選中的時(shí)候才下載更好。

一次下載一點(diǎn)內(nèi)容會(huì)導(dǎo)致兩個(gè)問(wèn)題例书。首先赫蛇，他會(huì)使應(yīng)用對(duì)細(xì)微的網(wǎng)絡(luò)延遲非常敏感，造成停頓雾叭、視頻卡頓等等。其次落蝙，它會(huì)一直讓蜂窩網(wǎng)絡(luò)或Wi-Fi無(wú)線電持續(xù)使用织狐。這會(huì)浪費(fèi)電量，特別是當(dāng)應(yīng)用和蜂窩網(wǎng)絡(luò)連接通信的時(shí)候筏勒。如果應(yīng)用在一小段時(shí)間下載大量數(shù)據(jù)移迫，然后允許無(wú)線連接進(jìn)入完全休眠，這會(huì)顯著提高用戶的電池壽命管行。

這同樣適用于socket編程厨埋。除了少數(shù)例外（例如遠(yuǎn)程終端程序），你永遠(yuǎn)不要一次只發(fā)送少量字節(jié)捐顷。這樣做在CPU負(fù)載方面是非常低效的荡陷，并會(huì)導(dǎo)致操作系統(tǒng)發(fā)送更多不必要的數(shù)據(jù)包。

盡可能下載最小可用資源迅涮，并在本地緩存資源

下載數(shù)據(jù)有很多與之相關(guān)的成本——電池壽命废赞、性能、以及在多種情況下真實(shí)的數(shù)據(jù)傳輸成本叮姑。因此唉地，你應(yīng)該始終根據(jù)需要來(lái)下載最小化的資源。

例如，如果你有一個(gè)圖片應(yīng)用耘沼，它下載一系列大型圖片极颓，并以縮略圖的方式呈現(xiàn)，那你應(yīng)該在服務(wù)器端完成縮略圖的加工群嗤。應(yīng)用應(yīng)該在一開(kāi)始只下載縮略圖菠隆，只有當(dāng)用戶選擇了某個(gè)縮略圖的時(shí)候，才下載全尺寸的圖片版本骚烧。這樣做有兩個(gè)原因：

• 傳輸數(shù)據(jù)會(huì)因?yàn)橐掷m(xù)運(yùn)行網(wǎng)絡(luò)硬件以及長(zhǎng)時(shí)間CPU供電而導(dǎo)致電能消耗浸赫。通過(guò)減少應(yīng)用傳輸資源的尺寸，可以提高用戶的電池壽命（因?yàn)檫@減少了總傳輸數(shù)據(jù)）赃绊。
• 如果用戶使用計(jì)費(fèi)網(wǎng)絡(luò)（例如蜂窩電話）既峡，傳輸較少的資源可以減少用戶的數(shù)據(jù)流量費(fèi)。

因?yàn)橥瑯拥脑虮滩椋严螺d資源保存在本地緩存运敢，可以節(jié)省時(shí)間、帶寬忠售、以及電池壽命传惠。想要做到這一點(diǎn)，當(dāng)下載完數(shù)據(jù)之后稻扬，不再向服務(wù)器請(qǐng)求資源卦方，而是向它請(qǐng)求有改變的資源。如果沒(méi)有改變泰佳，就使用本地的副本盼砍。

在OS X和iOS中有很多高級(jí)APIs（例如NSURL）提供緩存支持（例如NSURLCache）。但是你你必須選擇合適的緩存尺寸逝她。無(wú)論你是使用內(nèi)置的緩存API還是自建的浇坐，你都應(yīng)該嘗試使用緩存尺寸和替換策略來(lái)決定哪些對(duì)你的應(yīng)用最有意義。

注意：這個(gè)目的和之前的目的（一次下載大量數(shù)據(jù)以便網(wǎng)絡(luò)硬件變成閑置狀態(tài)）之間經(jīng)常存在沖突黔宛。
例如，考慮一個(gè)加載圖像縮略圖的應(yīng)用臀晃。如果用戶滾動(dòng)幾個(gè)被縮略圖填充的屏幕，那么應(yīng)用應(yīng)該在一次下載足夠多的圖片來(lái)填充前面幾個(gè)屏幕积仗，以便網(wǎng)絡(luò)硬件進(jìn)入空閑狀態(tài)。但是寂曹，如果用戶基本上不滾動(dòng)到第二屏哎迄，那么所有額外下載的圖片就浪費(fèi)了帶寬
每個(gè)網(wǎng)絡(luò)應(yīng)用都應(yīng)該平衡這種沖突。這取決于開(kāi)發(fā)者的決定漱挚。

優(yōu)雅的處理網(wǎng)絡(luò)問(wèn)題

在當(dāng)今高度移動(dòng)的世界，你不能再假設(shè)網(wǎng)絡(luò)連接一旦建立旨涝，就會(huì)保持不變蹬屹；或者認(rèn)為帶寬是不變的。這也就是說(shuō)白华，唯一不變的是變化。作為一個(gè)開(kāi)發(fā)者厦取，你必須為這些常見(jiàn)的故障進(jìn)行規(guī)劃管搪，并設(shè)計(jì)代碼來(lái)恰當(dāng)?shù)奶幚硭鼈儭?/p>

為變動(dòng)網(wǎng)絡(luò)接口可用性設(shè)計(jì)

網(wǎng)絡(luò)接口的可用性會(huì)因?yàn)闊o(wú)數(shù)原因而經(jīng)常改變，特別是iOS霎箍。例如用戶的如下行為：

• 乘坐地鐵，每次進(jìn)站的時(shí)候獲得無(wú)線信號(hào)漂坏，而在出站之后失去信號(hào)媒至。
• 離開(kāi)當(dāng)前的Wi-Fi網(wǎng)絡(luò)范圍。
• 激活飛行模式或關(guān)閉Wi-Fi。
• 拔掉網(wǎng)絡(luò)線纜蒂胞。

因此，在寫(xiě)使用網(wǎng)絡(luò)的應(yīng)用的時(shí)候蛤织，必須準(zhǔn)備好處理網(wǎng)絡(luò)故障鸿染。當(dāng)網(wǎng)絡(luò)故障發(fā)生的時(shí)候，應(yīng)用應(yīng)該基于多種考慮來(lái)決定做什么摊鸡，最重要的是，這個(gè)請(qǐng)求是否由用戶明確指定的免猾。

對(duì)于用戶要求的請(qǐng)求：

• 始終嘗試建立連接是辕。不要嘗試猜測(cè)網(wǎng)絡(luò)服務(wù)是否可用猎提，也不要緩存該決定。
• 如果連接失敗锨苏，使用SCNetworkReachability來(lái)幫助分析導(dǎo)致失敗的原因伞租。然后：
• 如果連接失敗是因?yàn)闀簳r(shí)錯(cuò)誤，嘗試再次建立連接肯夏。
• 如果連接失敗是因?yàn)闊o(wú)法連接主機(jī)，等待SCNetworkReachabilityAPI調(diào)用你注冊(cè)的回調(diào)烁兰。當(dāng)主機(jī)再次變成可達(dá)時(shí)徊都，應(yīng)用應(yīng)該可以在無(wú)用戶干涉的情況下，自動(dòng)嘗試重新建立連接（除非用戶取消了這個(gè)請(qǐng)求主之，例如關(guān)閉了瀏覽窗口或點(diǎn)擊了取消按鈕）李根。
• 嘗試以非模態(tài)的方式顯示連接狀態(tài)信息。但是粤攒，如果你必須顯示錯(cuò)誤對(duì)話框囱持，請(qǐng)確保它不會(huì)在遠(yuǎn)程主機(jī)再次可達(dá)時(shí)妨礙應(yīng)用自動(dòng)重試的能力。在主機(jī)再次可達(dá)的時(shí)候自動(dòng)關(guān)閉該對(duì)話框盔几。

對(duì)于后臺(tái)提出的請(qǐng)求:

• 嘗試建立連接掩幢。如果需要上鞠，使用SCNetworkReachability來(lái)避免在不恰當(dāng)?shù)臅r(shí)候建立連接顺献。例如注整，通過(guò)檢查kSCNetworkReachabilityFlagsIsWWAN標(biāo)識(shí)來(lái)避免蜂窩連接的不必要流量。

重要：檢查可達(dá)性標(biāo)識(shí)不保證你的流量將不通過(guò)蜂窩網(wǎng)絡(luò)連接發(fā)送肿轨。詳見(jiàn)Restrict Cellular Networking Correctly椒袍。

• 如果連接失敗，如果它還可用驹暑，使用SCNetworkReachability來(lái)等待主機(jī)重新變?yōu)榭蛇_(dá)，然后再次嘗試請(qǐng)求京办。
• 不要顯示任何對(duì)話框帆焕；用戶通常不關(guān)心不是由他們啟動(dòng)的后臺(tái)下載的故障。
• 即使當(dāng)網(wǎng)絡(luò)可達(dá)API告訴應(yīng)用網(wǎng)絡(luò)已經(jīng)改變财饥，也要避免快速的重試折晦。你應(yīng)該逐漸的增加兩次嘗試之間的間隔時(shí)間，直到到達(dá)一個(gè)相當(dāng)長(zhǎng)的間隔（例如15分鐘）打颤。

應(yīng)用應(yīng)該能夠優(yōu)雅的響應(yīng)當(dāng)前網(wǎng)絡(luò)接口的改變漓滔。為了支持這點(diǎn)乖篷，使用SCNetworkReachabilityAPI撕蔼。通過(guò)注冊(cè)網(wǎng)絡(luò)改變通知秽誊，應(yīng)用可以在可用的網(wǎng)絡(luò)接口改變的時(shí)候收到警告琳骡。Reachability樣本代碼演示了注冊(cè)回調(diào)，它會(huì)在當(dāng)前網(wǎng)絡(luò)接口改變時(shí)響應(yīng)接到的通知最易。閱讀SCNetworkReachability Reference炫狱，可看到對(duì)于SCNetworkReachability的完整討論。

重要：SCNetworkReachabilityAPI不適用于確定網(wǎng)絡(luò)連接的預(yù)檢機(jī)制嬉荆。你通過(guò)嘗試連接來(lái)確定網(wǎng)絡(luò)的連接酷含。如果連接失敗，查閱SCNetworkReachability API來(lái)幫助診斷導(dǎo)致失敗的原因限番。

無(wú)論請(qǐng)求是用戶產(chǎn)生的還是還是后臺(tái)產(chǎn)生的什往，SCNetworkReachabilityAPI提供一個(gè)很好的方式來(lái)查看接口可達(dá)性的改變。當(dāng)你使用的網(wǎng)絡(luò)接口消失時(shí)躯舔，你應(yīng)該快速的重連省古，來(lái)避免給用戶帶來(lái)不必要的延遲感。

還有惜互，在iOS中琳拭，如果你連接的是蜂窩網(wǎng)絡(luò)，你應(yīng)該在Wi-Fi服務(wù)再次可用的時(shí)候快速在后臺(tái)進(jìn)行重連坑鱼。Wi-Fi連接使用更少的電量絮缅，通常也更快呼股，且比蜂窩網(wǎng)絡(luò)省錢(qián)画恰。

為變動(dòng)的網(wǎng)絡(luò)速度設(shè)計(jì)

應(yīng)用必須為網(wǎng)絡(luò)速度的改變做好準(zhǔn)備允扇，即便當(dāng)前的網(wǎng)絡(luò)接口不改變也要如此。例如蔼两，當(dāng)一個(gè)移動(dòng)設(shè)備用戶改變位置時(shí)额划，Wi-Fi或者蜂窩網(wǎng)絡(luò)的性能會(huì)顯著變化，可能是因?yàn)楦蓴_的增減俊戳，也可能是因?yàn)樵O(shè)備切換到了繁忙的基站抑胎。這種變化甚至不需要有太大的位置變化；從一個(gè)房間走到另一個(gè)房間阿逃，就可能會(huì)產(chǎn)生顯著的網(wǎng)速變化恃锉。

此外，即便忽略爭(zhēng)用和干擾破托，接口本身也沒(méi)有告訴你有關(guān)全路徑的真實(shí)帶寬土砂。當(dāng)用戶嘗試連接Google的時(shí)候Wi-Fi網(wǎng)絡(luò)可能是最快的，但是在用戶和服務(wù)器之間的路由可能經(jīng)過(guò)蜂窩網(wǎng)絡(luò)或者衛(wèi)星網(wǎng)絡(luò)吴叶。類(lèi)似的序臂，用戶可能有一個(gè)千兆以太網(wǎng)來(lái)連接局域網(wǎng)上的服務(wù)器，但與外部世界只有128k的上行連接造寝。由于這個(gè)原因吭练，你不應(yīng)該基于當(dāng)前的網(wǎng)絡(luò)接口對(duì)網(wǎng)速進(jìn)行假定。

只有一種方式可以確定網(wǎng)速：使用它鲫咽。在你下載少量的數(shù)據(jù)之后分尸，你可以對(duì)網(wǎng)速進(jìn)行初步的估算。你應(yīng)該持續(xù)監(jiān)控你的下載速率來(lái)保持精確的估算孔庭，然后相應(yīng)地調(diào)整你的預(yù)期材蛛。例如，如果你正在傳輸視頻流芽淡，當(dāng)確定視頻流的幀率不能夠維持播放的時(shí)候豆赏，你應(yīng)該切換到較低帶寬流來(lái)支持播放，用戶不會(huì)感受到這種變化白胀。如果之后下載速度提高耙饰，你可以再切換回來(lái)。

為高延時(shí)設(shè)計(jì)

作為開(kāi)發(fā)者廷痘，要假設(shè)用戶可能會(huì)使用高延時(shí)的連接件已。高延時(shí)在一些蜂窩網(wǎng)絡(luò)接口類(lèi)型上是特別常見(jiàn)的，因?yàn)樗o設(shè)備使用的時(shí)隙有限兄猩。例如，在EDGE連接上的往返延時(shí)通常以秒計(jì)鸠姨。但是在衛(wèi)星連接或一般忙碌的DSL連接淹真，如果應(yīng)用設(shè)計(jì)時(shí)對(duì)此沒(méi)有估計(jì)的話，即使是半秒鐘的延時(shí)也會(huì)造成嚴(yán)重的問(wèn)題巍糯。

當(dāng)應(yīng)用向多個(gè)遠(yuǎn)程主機(jī)發(fā)送多個(gè)請(qǐng)求時(shí)客扎，如果它在創(chuàng)建第二個(gè)請(qǐng)求之前需要等待第一個(gè)請(qǐng)求的返回結(jié)果徙鱼，連接延遲會(huì)相加。兩次請(qǐng)求之間的延時(shí)會(huì)不斷累加疆偿。

為了避免這個(gè)問(wèn)題杆故，當(dāng)應(yīng)用需要發(fā)送任何彼此不相互依賴的多個(gè)信息時(shí)（資源請(qǐng)求、確認(rèn)等等）饲趋，同時(shí)發(fā)送它們要比一個(gè)個(gè)的發(fā)送要好撤蟆。圖1-1說(shuō)明了同時(shí)發(fā)送多個(gè)信息應(yīng)用獲得的增速。

圖1-1 比較同時(shí)和順序請(qǐng)求的響應(yīng)時(shí)間

如果在iOS應(yīng)用中使用NSURLConnection龄砰，你可以通過(guò)啟用HTTP管道（pipelining）很輕松的獲得增速换棚。當(dāng)管道被啟用時(shí)反镇，你的連接自動(dòng)同時(shí)發(fā)送多個(gè)HTTP請(qǐng)求。通過(guò)調(diào)用你提供給連接的NSMutableURLRequest對(duì)象的setHTTPShouldUsePipelining:方法來(lái)啟用管道夕玩。

注意：一些服務(wù)器不支持管道。如果你連接到的服務(wù)器不支持管道禽作，這個(gè)連接依然工作揩页，但不會(huì)提高性能。

在各種條件下測(cè)試

Xcode提供了一個(gè)名為Network Link Conditioner（網(wǎng)絡(luò)鏈接調(diào)節(jié)器）的工具，它能模擬各種網(wǎng)絡(luò)條件衷蜓，包括減少帶寬磁浇、高延時(shí)、DNS延時(shí)置吓、丟包等等衍锚。在你準(zhǔn)備發(fā)布任何使用網(wǎng)絡(luò)的軟件之前，你應(yīng)該安裝這個(gè)工具度宦，啟用它告匠，然后運(yùn)行你的應(yīng)用來(lái)查看它在真實(shí)條件下的性能。

有幾件需要測(cè)試的事：

• 確保應(yīng)用即便是在惡劣的帶寬條件下也保持可用划鸽。盡可能多的調(diào)整帶寬消耗戚哎。
• 將延時(shí)增加3到4秒。確保任何用戶操作只延時(shí)幾秒鐘崭捍，而不是幾分鐘啰脚。
• 當(dāng)網(wǎng)絡(luò)鏈接丟包時(shí)，應(yīng)用應(yīng)該可以繼續(xù)運(yùn)行粒梦，只是慢一點(diǎn)而已匀们。

你或許還可以發(fā)現(xiàn)使用一些第三方工具（例如tcptrace），可以幫助你在惡劣網(wǎng)絡(luò)條件下對(duì)應(yīng)用的網(wǎng)絡(luò)訪問(wèn)模式進(jìn)行可視化觀察重抖。