fiddler模擬限速的原理
我們可以通過fiddler來模擬限速，因為fiddler本來就是個代理，它提供了客戶端請求前和服務器響應前的回調接口，我們可以在這些接口里 面自定義一些邏輯。Fiddler的模擬限速正是在客戶端請求前來自定義限速的邏輯，此邏輯是通過延遲發送數據或接收的數據的時間來限制網絡的下載速度和 上傳速度，從而達到限速的效果。
他提供了一個功能，讓我們模擬低速網路環境…啟用方法如下：
Rules → Performances → Simulate Modem Speeds ：模擬調制解調器的速度
啟動fiddler需要進行如下設置：
1.設置端口號:
Tools →Fiddler options →Connections
allow remote computers to connect “允許遠程計算機連接”為設置的代理可以連接到fiddle上，必須勾選.
2.重啟fiddler
3.設置模擬調制解調器的速度
4.設置手機代理
手機代理設置“ip地址為本機的ip，端口號為之前設置的端口號（確保端口號不被占用）”
在本機命令行輸入：ipconfig，找到本機的ip地址。
5.手動設置設置上行，下行速率，模擬網路速度的原理，每上傳/下載1KB 要delay 多久…
網絡取值的算法就是 1000/下載速度 = 需要delay的時間(毫秒)，比如50kb/s 需要delay200毫秒來接收數據。
查找代碼如下：
if (m_SimulateModem) {
//Delay sends by 300ms per KB uploaded. //每延遲300ms發送1kb的數據，也就是每1s發送3kb的數據
oSession["request-trickle-delay"] = 300
//Delay receives by 150ms per KB downloaded.
oSession["response-trickle-delay"] = 150//每延遲150ms下行1kb的數據
}
(1).首先來判斷m_SimulateModem是否為true，也就是是否設置了弱網模式。
(2).如果為弱網模式。則分析代碼:
- oSession[“request-trickle-delay”] = “300”; 注釋的也很明白，Delay sends by 300ms per KB uploaded.上傳1KB需要300ms，轉化一下上傳速度：1Kb/0.3s = 10/3(KB/s)
- 如果你想設置上傳的速度為50KB/s，你則需要設置Delay 時間為 20ms
- 同樣的方法，也可以限制上傳的速度，調整oSession[“response-trickle-delay”]即可。
代碼中 oSession["request-trickle-delay"] = "50";表示上傳的速度，表示每50ms每KB的上傳速度
oSession["response-trickle-delay"] = "50";表示下行的速度，表示每50ms每KB的上行速度
(3).點擊保存，就可模擬各種限速的情況了。
PS：目前2G網絡的的下行速度約在20kb/s,換算好后約是每50ms每KB的下行速度
目前2G網絡的的下行速度約在180kb/s,換算好后約是每6ms每KB的下行速度
2G：150Kbps，折合下載速度15-20K/s；
3G：1-6Mbps，折合下載速度120K/s-600K/s
4G：10-100Mbps，折合下載速度1.5M/s-10M/s
請注意，當你存檔之后，原本已經勾選的SimulateModem Speeds 會被取消勾選，要記得再到Rules → Performances → Simulate Modem Speeds 勾選喔！
6.設置完成后，清空原有的log，並使用你的app進行弱網條件下的操作，
打開android設備的“設置”->“WLAN”，找到你要連接的網絡，在上面長按，然后選擇“修改網絡”，彈出網絡設置對話框，然后勾選“顯示高級選項”。
在這里我用的是夜神模擬器.
在“代理”后面的輸入框選擇“手動”，在“代理服務器主機名”后面的輸入框輸入電腦的ip地址，在“代理服務器端口”后面的輸入框輸入8888，然后點擊“保存”按鈕。
然后啟動android設備中的瀏覽器，訪問百度的首頁，在fiddler中可以看到完成的請求和響應數據。
弱網測試的現象及原因
1、 現象：用戶登錄應用時下載初始化數據，下載過程中因網速太慢點擊取消並重新登錄，數據初始化完成后出現重復，造成數據不一致。
原因：數據下載過程中、下載失敗后，未進行數據回滾，中止后重新下載，出現數據重復
解決方案：通過事務處理數據下載邏輯，下載失敗后，應用本地數據庫進行數據回滾。
2、 現象：用戶點擊數據上傳，數據上傳過程中網絡弱且不穩定，基於聯網狀態自動觸發數據上傳，導致出現數據重復寫入，形成臟數據
原因：數據上傳過程中，由於失敗重傳機制，會出現連續兩次寫操作，並且未做唯一識別處理
解決方案：根據數據特性，對可能造成臟數據的地方，通過關鍵字段，例如創建時間，key-value值等生成hash鍵，標記記錄唯一性，即數據寫入時，檢查hash鍵是否存在，如果已經存在，當前重復數據丟棄。
3、 現象：在弱網環境下，用戶輸入用戶名和密碼點擊登錄，應用鏈接超時返回用戶名和密碼錯誤提示。
原因：在弱網環境下的連接超時后，按照強網業務邏輯處理，導致返回超時異常。
解決方案： 弱網連接超時后，檢查應用本地數據庫是否有用戶登錄信息，若存在，獲取應用本地用戶信息進行登錄。
4、 現象：在弱網環境下，用戶輸入用戶名和密碼后點擊登錄，登錄過程中應用崩潰並且閃退。
原因：弱網環境下數據下載超時，加載數據嚴重依賴於后來的異步加載。數據還沒來得及返回，應用跳轉到下個activity，導致崩潰。
解決方案：健壯數據加載流程，通過標記后台數據下載狀態加載界面，依賴數據下載完成后，再進行頁面跳轉。
5、 現象：弱網絡環境下，用戶請求頁面響應時間較長，等待的過程中，頁面上的部分控件仍然可以操作，當用戶點擊控件時，出現應用閃退現象；
原因：沒有對數據加載流程進行判斷，直接暴露控件可控，當出現依賴數據的控件操作時，沒有在數據返回前做兼容處理。
解決方案：在數據加載過程中，設置頁面對外暴露的控件為“不可操作”，當數據加載完再釋放。
6、 現象：在弱網環境下，用戶第一次輸入搜索關鍵字沒有得到響應后，再次輸入全新關鍵字並發送請求，等待搜索結果返回后，當前結果頁被之前的關鍵字搜索結果刷新覆蓋
原因：中間的請求返回較慢，顯示最終的結果后，之前請求返回的數據應不做處理。
解決方案：對異步請求未完成的任務進行cancel.