一、iPhone手機弱網(wǎng)環(huán)境配置

?

選擇現(xiàn)有網(wǎng)絡(luò)狀態(tài)

或自定義網(wǎng)絡(luò)狀態(tài)

設(shè)置參數(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、WLAN、Cellular

二、優(yōu)化方案

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

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

監(jiān)聽網(wǎng)絡(luò)狀態(tài)的改變，可用的?AFNetworking?的?AFNetworkReachabilityStatus。
無網(wǎng)絡(luò)狀態(tài)時，進行告知用戶的處理。

1.2、加載網(wǎng)絡(luò)請求前，添加“正在加載中的動畫”

如MBProgressHUD

1.3、加載網(wǎng)絡(luò)請求完成后，需要先移除網(wǎng)絡(luò)狀態(tài)動畫，并增加判定空數(shù)據(jù)處理。（判定是網(wǎng)絡(luò)原因，還是無數(shù)據(jù)的原因）

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

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

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

2.1、制定最合適的超時時間

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

讓用戶可以取消長時間運行或者速度很慢的網(wǎng)絡(luò)操作。

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

以用戶等待容忍度不超過?2s?為原則，像首頁這種多個業(yè)務模塊一起呈現(xiàn)的頁面，如果一次性請求完所有的接口數(shù)據(jù)，會等待很久，所以可以對多子模塊，進行分段的“延遲”請求。

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

2.3、固定模塊加入緩存機制、或增量更新機制

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

2.4、多模塊的重新加載操作

像一些多模塊，模塊之間相關(guān)聯(lián)的復雜頁面，多個模塊會有多個請求，當某個請求失敗需要添加“重新加載”的按鈕時，建議所有請求重新請求一遍，防止模塊之間關(guān)聯(lián)的數(shù)據(jù)出現(xiàn)偏差，或者?UI?布局錯亂。
所以，如果有做網(wǎng)絡(luò)請求失敗后，重新加載的按鈕/下拉操作，建議是：

• 多模塊再各自請求一遍。
• 復雜?UI?重新計算一下。

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

2.5、預加載設(shè)置“臨界值”

根據(jù)當前?UITableView?的所在位置，除以目前整個?UITableView.contentView?的高度，來判斷當前是否需要發(fā)起網(wǎng)絡(luò)請求：在當前頁面已經(jīng)劃過了?70%?的時候，就請求新的資源，加載數(shù)據(jù)；

2.6、從請求這個動作下手

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

2.7、斷線重連

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

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

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

3、用戶體驗優(yōu)化

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

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

3.2、進度的驅(qū)使

不管網(wǎng)絡(luò)條件如何，加載進度始終是從50%起，并且停留在大約98%進度左右的地方。

3.3、固定的 UI 顯示布局，加載時可預加載虛擬布局視圖

類似知乎，在加載時，“正在加載中的動畫/視圖”，改為主頁面顯示預加載的占位圖。

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

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

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

4.1、使用更快的圖片格式

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

4.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.3、SDWebImage 參數(shù)選項

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

4.4、不加載圖片

弱網(wǎng)情況下，在一些不影響操作，并能通過簡單文字的描述告知用戶該區(qū)域的內(nèi)容，可以不加載圖片，待到網(wǎng)絡(luò)流暢狀態(tài)再進行圖片的加載。當然這種方法要視情況而定，或者一般都在?APP?的設(shè)置選項，增加一個“弱網(wǎng)狀態(tài)不顯示圖片”的按鈕。文章來源地址http://www.zghlxwxcb.cn/news/detail-491025.html

到了這里，關(guān)于iOS 性能優(yōu)化方案-弱網(wǎng)優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！