• 這里立個(gè) flag，換工作后，再把之前的學(xué)習(xí)筆記，整理一下，多寫幾篇思路清晰點(diǎn)的文章。 （?? 希望不打臉）

弱網(wǎng)測試方案

一、Charles

1、Enable Throttling：

iOS 設(shè)備設(shè)置完代理，打開設(shè)置：Proxy -> Throttle Settings → Enable Throttling

后根據(jù)場景，設(shè)置需要的弱網(wǎng)效果，一般選最低的選項(xiàng)。

2、直接選中龜速

打開龜速~

【by：具體的效果以上面 Throttle Settings 的弱網(wǎng)參數(shù)為準(zhǔn)。（測試完弱網(wǎng)環(huán)境記得關(guān)閉...）】

二、iOS 設(shè)備自帶弱網(wǎng)測試

設(shè)置-> 開發(fā)者 -> Networking Link Conditioner：

iOS 設(shè)備自帶~

參數(shù)含：

• In bandwidth 下行帶寬
• In packet loss 下行丟包率
• In delay 下行延遲，單位為ms
• Out bandwidth 上行帶寬
• Out packet loss 上行丟包率
• Out delay 上行延遲
• DNS delay DNS 解析延遲
• Protocol 協(xié)議，包括 Any、IPv4、IPv6
• Interface 接口，可選 ALL、Wi-Fi、cellular（蜂窩網(wǎng)）
  （測試完弱網(wǎng)環(huán)境記得關(guān)閉...）

優(yōu)化方案

一、必要的狀態(tài)呈現(xiàn)

弱網(wǎng)優(yōu)化的目的，是調(diào)高用戶的使用體驗(yàn)。
所以很重要的一點(diǎn)就是：不同網(wǎng)絡(luò)加載狀態(tài)的過程反饋，或"積極"反饋給用戶（下文“用戶體驗(yàn)優(yōu)化”里，會(huì)提到加載進(jìn)度從50%起的"積極"反饋?zhàn)龇ǎ?/p>

1、無網(wǎng)絡(luò)提示。

可為 Controller 監(jiān)聽網(wǎng)絡(luò)狀態(tài)的改變：
例如用的 AFNetworking 的 AFNetworkReachabilityStatus。
為無網(wǎng)絡(luò)狀態(tài)等進(jìn)行告知用戶的處理。

2、加載前需要添加“正在加載中的動(dòng)畫/視圖”

例如 MBProgressHUD 的使用。

3、加載后需要先移除網(wǎng)絡(luò)狀態(tài)視圖，并增加判定空數(shù)據(jù)處理。[如有可能，判定是網(wǎng)絡(luò)原因，還是無數(shù)據(jù)的原因。]

[hud hideAnimated:YES]; 
if (數(shù)據(jù)為空) {
 // 這里做空視圖處理
}

4、善用狀態(tài)切換的通知，為界面做出不同的變化。

在 2G、3G、4G、wifi，(現(xiàn)在還有 5g) 等不同的網(wǎng)絡(luò)做出不同的狀態(tài)圖切換，或者交互切換。

二、網(wǎng)絡(luò)請求優(yōu)化

1、制定最合適的超時(shí)時(shí)間：

對總讀寫超時(shí)(從請求到響應(yīng)的超時(shí))、首包超時(shí)、包包超時(shí)(兩個(gè)數(shù)據(jù)段之間的超時(shí))時(shí)間制定不同的計(jì)算方案，加快對超時(shí)的判斷，減少等待時(shí)間，盡早重試。這里的超時(shí)時(shí)間還可以根據(jù)網(wǎng)絡(luò)狀態(tài)動(dòng)態(tài)設(shè)定，例如在網(wǎng)絡(luò)狀態(tài)為 2G、3G、4G、wifi 下設(shè)置不同的超時(shí)時(shí)間。

2、多子模塊請求的“延遲性”：

以用戶等待容忍度不超過 2s 為原則，像首頁這種多個(gè)業(yè)務(wù)模塊一起呈現(xiàn)的頁面，如果一次性請求完所有的接口數(shù)據(jù)，估計(jì)用戶已經(jīng) Home 回到主頁了，所以可以對多子模塊，進(jìn)行分段的“延遲”請求。

• 優(yōu)先模塊：請求數(shù)據(jù)量少、業(yè)務(wù)上需要優(yōu)先顯示的。
• 延后模塊：數(shù)據(jù)量大、類似列表的多條數(shù)據(jù)，適合放置加載動(dòng)畫，時(shí)長上用戶可接受性強(qiáng)，所以除了放在后面外，可做分頁處理、滑動(dòng)后的延遲加載處理。

3、固定模塊加入緩存機(jī)制、或增量更新機(jī)制：

對首頁及特定一級頁面進(jìn)行數(shù)據(jù)緩存，在一定的有效時(shí)間內(nèi)再次請求可以直接從緩存讀取數(shù)據(jù)，也可避免空白頁出現(xiàn)影響體驗(yàn)。
或者進(jìn)行判斷數(shù)據(jù)是否有增量變化，有點(diǎn)的話在插入動(dòng)畫的前提下，進(jìn)行數(shù)據(jù)的更新。

4、多模塊的重新加載操作：

像一些多模塊，模塊之間相關(guān)聯(lián)的復(fù)雜頁面，多個(gè)模塊會(huì)有多個(gè)請求，當(dāng)某個(gè)請求失敗需要添加“重新加載”的按鈕時(shí)，建議所有請求重新請求一遍，防止模塊之間關(guān)聯(lián)的數(shù)據(jù)出現(xiàn)偏差，或者 UI 布局錯(cuò)亂。
例如，鏈家的 APP(僅供討論，無其他意思哈，鏈家請見諒?? )，弱網(wǎng)環(huán)境下，中間某模塊 UI 產(chǎn)生混亂，如果在用戶下拉重新加載請求的情況下，如果不是首頁這整個(gè)模塊請求后完，進(jìn)行布局重新計(jì)算，那么后面的 UI 就一直是這個(gè)狀態(tài)。
所以，如果有做網(wǎng)絡(luò)請求失敗后，重新加載的按鈕/下拉操作，建議是：

• 多模塊再各自請求一遍。
• 復(fù)雜 UI 重新計(jì)算一下。

原因是：弱網(wǎng)環(huán)境，本身請求到的數(shù)據(jù)可能也不齊全，多個(gè)請求或許只能拿到部分?jǐn)?shù)據(jù)，而大部分情況是，各模塊是相輔相成的。

弱網(wǎng)狀態(tài)下的“鏈家”APP

5、預(yù)加載設(shè)置“臨界值”

使用 Threshold 進(jìn)行預(yù)加載是一種最為常見的預(yù)加載方式，知乎客戶端就使用了這種方式預(yù)加載條目，而其原理也非常簡單，根據(jù)當(dāng)前 UITableView 的所在位置，除以目前整個(gè) UITableView.contentView 的高度，來判斷當(dāng)前是否需要發(fā)起網(wǎng)絡(luò)請求：在當(dāng)前頁面已經(jīng)劃過了 70% 的時(shí)候，就請求新的資源，加載數(shù)據(jù)；

但是，僅僅使用這種方法會(huì)有另一個(gè)問題，尤其是當(dāng)列表變得很長時(shí)，十分明顯，會(huì)導(dǎo)致新加載的頁面都沒有看，應(yīng)用就會(huì)發(fā)出另一次請求，獲取新的資源。

【問題可參照：預(yù)加載與智能預(yù)加載 (VIA)】

6、從請求這個(gè)動(dòng)作下手：

優(yōu)化DNS查詢：應(yīng)盡量減少DNS查詢，做DNS緩存，避免域名劫持、DNS污染，同時(shí)把用戶調(diào)度到“最優(yōu)接入點(diǎn)”。
減小數(shù)據(jù)包大小和優(yōu)化包量：通過壓縮、精簡包頭、消息合并等方式，來減小數(shù)據(jù)包大小和包量。
優(yōu)化ACK包：平衡冗余包和ACK包個(gè)數(shù)，達(dá)到降低延時(shí)，提高吞吐量的目的。

這幾個(gè)，都是在優(yōu)化請求的數(shù)據(jù)處理和查詢上做優(yōu)化的。感興趣的話，可以翻到最下面的資料網(wǎng)翻閱，或通過查詢 HTTP 協(xié)議，TCP/UDP 協(xié)議這部分網(wǎng)絡(luò)優(yōu)化內(nèi)容，分析總結(jié)并對網(wǎng)絡(luò)請求這塊進(jìn)行細(xì)致優(yōu)化。

7、斷線重連。

在無線網(wǎng)絡(luò)中有太多的原因?qū)е聰?shù)據(jù)連接中斷了。這里可以使用CDN。
（CDN 是構(gòu)建在數(shù)據(jù)網(wǎng)絡(luò)上的一種分布式的內(nèi)容分發(fā)網(wǎng)。 CDN 的作用是采用流媒體服務(wù)器集群技術(shù)，克服單機(jī)系統(tǒng)輸出帶寬及并發(fā)能力不足的缺點(diǎn)，可極大提升系統(tǒng)支持的并發(fā)流數(shù)目，減少或避免單點(diǎn)失效帶來的不良影響。）

8、減少數(shù)據(jù)連接的創(chuàng)建次數(shù)

由于創(chuàng)建連接是一個(gè)非常昂貴的操作，所以應(yīng)盡量減少數(shù)據(jù)連接的創(chuàng)建次數(shù)，且在一次請求中應(yīng)盡量以批量的方式執(zhí)行任務(wù)。如果多次發(fā)送小數(shù)據(jù)包，應(yīng)該盡量保證在2秒以內(nèi)發(fā)送出去。在短時(shí)間內(nèi)訪問不同服務(wù)器時(shí)，盡可能地復(fù)用無線連接。

三、用戶體驗(yàn)優(yōu)化

1、內(nèi)容分先后顯示：

例如，一個(gè)業(yè)務(wù)模塊文字圖片都有的情況。
一個(gè)完整的請求和加載，可能一直卡在50%-90%的時(shí)候，那么先加載文字，再加載圖片。

2、進(jìn)度的驅(qū)使：

不管網(wǎng)絡(luò)條件如何，加載進(jìn)度始終是從50%起，并且停留在大約98%進(jìn)度左右的地方。
(當(dāng)然， 不建議在數(shù)據(jù)量比較大的請求中做這樣的顯示機(jī)制，因?yàn)闀?huì)讓用戶產(chǎn)生網(wǎng)絡(luò)波動(dòng)較大的體驗(yàn)。)

3、固定的 UI 顯示布局，加載時(shí)可預(yù)加載虛擬布局視圖：

知乎截圖

交互上，數(shù)據(jù)的加載會(huì)讓用戶對 APP 的 UI 設(shè)計(jì)有熟悉感。

4、弱網(wǎng)加載失敗/空數(shù)據(jù)，可添加“重新加載”的按鈕，或可增加下拉刷新操作。

例如：請求無數(shù)據(jù)/網(wǎng)絡(luò)失敗，添加‘重新加載“按鈕，讓用戶意識到處于“可控”狀態(tài)，降低用戶焦躁情緒。

四、圖片加載優(yōu)化

1、使用更快的圖片格式：

嚴(yán)格說也不算弱網(wǎng)下的優(yōu)化，但一個(gè)更快的圖片格式真的很重要！這里建議采用 WebP 格式。（WebP 格式，谷歌（google）開發(fā)的一種旨在加快圖片加載速度的圖片格式。圖片壓縮體積大約只有 JPEG 的2/3，并能節(jié)省大量的服務(wù)器帶寬資源和數(shù)據(jù)空間。但 WebP 是一種有損壓縮。相較編碼 JPEG 文件，編碼同樣質(zhì)量的 WebP 文件需要占用更多的計(jì)算資源。）

2、根據(jù)網(wǎng)絡(luò)狀態(tài)呈現(xiàn)不同精度的圖：

如（對于原圖是 600X480 的圖片）：

• 2/3G 使用低清晰度圖片：下發(fā) 300X240，精度為 80 的圖片；
• 4G 普通清晰度圖片下發(fā) 600X480，精度為 80 的圖片；
• WiFi 高清晰度圖片（最好根據(jù)網(wǎng)速來判斷，WiFi 也有慢的）：下發(fā) 600X480，精度為 100 的圖片。

4、SDWebImage 參數(shù)選項(xiàng)：

根據(jù)使用場景，參照 SDWebImageOptions常量說明，對圖片的加載進(jìn)行。

5、干脆不加載圖片...

這也是一個(gè)方法，弱網(wǎng)情況下，在一些不影響操作，并能通過簡單文字的描述告知用戶該區(qū)域的內(nèi)容，可以不加載圖片，待到網(wǎng)絡(luò)流暢狀態(tài)再進(jìn)行圖片的加載。

當(dāng)然這種方法要視情況而定，或者一般都在 APP 的設(shè)置選項(xiàng)，增加一個(gè)“弱網(wǎng)狀態(tài)不顯示圖片”的按鈕。

關(guān)于網(wǎng)絡(luò)加載、弱網(wǎng)優(yōu)化可參考資料：

【比較全的弱網(wǎng)優(yōu)化資料：http://www.52im.net/thread-1588-1-1.html】
【短連接的優(yōu)化手段總結(jié)：http://www.52im.net/thread-1413-1-1.html】
【iOS網(wǎng)絡(luò)深度優(yōu)化總結(jié)：http://m.itdecent.cn/p/a470ab485e39】

（轉(zhuǎn)載請標(biāo)明原文出處，謝謝支持 ~ ^- ~）
? by：啊左~