APP弱網路條件下，體驗優化之道

當然，html的加速方式有很多種

當然很多情況下使我們的介面設計得不夠合理，多次請求乙個相同資料 or 慢查詢造成的。我們也可以使用chrome://inspect外掛程式，檢視自己的device請求情況（android 手機連線上adb）。如下圖所示：

常用的優化點：

1 .慢查詢監控

mysql是支援慢查詢日誌監控的，我們能夠在日誌中準確的看出那一條記錄的查詢讀寫時間。具體操作大家可以檢視：

2 .多次查詢優化

盡量避免在for迴圈裡面進行sql查詢！！！這個是我們最近被外包坑的心得。能夠構造出一兩句通過sql查詢的語句就盡量不要在**裡面處理，也不需要進行多次查詢。

3 .常用介面cache

這個cache的機制我不多說了，各式各樣的cache框架，直接避免了與sql打交道。個人覺得是不得已而為之，對於實時性要求過高的介面，還是不能採取。

說到網路優化，絕大部分都是對的優化。

cdn 是構建在資料網路上的一種分布式的內容分發網。 cdn

的作用是採用流**伺服器集群技術，克服單機系統輸出頻寬及併發能力不足的缺點，可極大提公升系統支援的併發流數目，減少或避免單點失效帶來的不良影響。

公司裡面使用的是阿里雲的cdn服務

cdn說是可以使用最近的網路節點提供服務，避免網路傳輸中的消耗，但是真正的試驗後我們會發現，cdn的優化畢竟有限，並不能起到體驗質的飛躍。

webp格式，谷歌（google）開發的一種旨在加快載入速度的格式。壓縮體積大約只有jpeg的2/3，並能節省大量的伺服器頻寬資源和資料空間。facebook

但webp是一種有失真壓縮。相較編碼jpeg檔案，編碼同樣質量的webp檔案需要占用更多的計算資源。

webp的格式介紹我自己也早有耳聞，但是卻沒有真正的使用過。

從原來的760k直接變成了121k，大小僅僅為原圖的六分之一，(⊙o⊙)！！！！不敢相信。

分別開啟兩張作對比，雖然說webp是失真壓縮，我們在對比檢視的時候如果沒有很仔細的看，確實看不出來兩圖的區別。細節上webp確實存在一點瑕疵，但是想到1/6的壓縮，這一點點瑕疵已經無所謂了。

的格式更換了，我們在想想的精度、的尺寸是否也能夠按照不同的情況下做下發呢？

我們同樣的實驗了一下，得到的結果如下所示：

ok，可能很多朋友會跟我說，我艹，這麼複雜的處理，不同尺寸、不同精度、不同格式的，我們得怎麼存？我們是否每次產品方上傳產品的時候都需要對處理，那麼圖床的壓力得多大啊。有沒有成套的解決方案？

答案是有的，也就是我公司現在所採用的解決方案。七牛雲儲存（我不是廣告，真心好用）：

對於我們的研發來說，它們所提供的處理功能缺失不錯。

imageview2/1/w/640/h/300/format/webp/interlace/0/q/100

怎麼使用呢？

當然，這個是儲存的是原圖。

這個時候我們處於不同的網路條件下，希望更換尺寸、格式到上述描述的條件，我們只需要在連線上加上引數

就將原圖轉化為寬度640,高度300，格式為webp，精度為100的了。(⊙o⊙)!!!!!

網路條件不好的條件下，我們做再多的優化也是如同治標不治本，很難達到與wifi環境下一樣的體驗。既然，網路請求、快取、壓縮的方案都採取了，那麼你可以想一下，是否是自己的互動，讓使用者感覺到卡頓、慢？

不從0開始的進度條

如下圖所示，不管網頁的載入進度如何，不管網路條件如何，uc瀏覽器的載入進度始終是從50%起，並且停留在大約98%進度左右的地方。給予使用者一種，網頁馬上就要載入完了的感覺。

先顯示文字在載入

同樣是在webview之中，或者多**的載入速度肯定是遠遠慢過文字的載入速度的。由於不同的webview顯示和渲染效果不同，我們可以先讓webview先顯示文字，在顯示。給使用者一種可以先預覽整個網頁概況的感覺。

即：

//本身含義阻止網路資料
websettings.setblocknetworkimage(true);
// 網頁載入完成後，將阻塞的載入放開。
//解除資料阻止
websettings.setblocknetworkimage(false);

當然，如果是在非webview中，為了避免網路資源的消耗，也可以模仿類似的操作。

3 .常用資訊加入快取機制、增量更新

/* * @author zhoushengtao(周聖韜)

* @since 2023年7月16日下午16:47:20

* @weixin stchou_zst

* @blog