日訪問百萬級微信小程式優化技巧總結

• 2020 年 2 月 17 日
• 筆記

借負責的小程式流量暴增事件總結下優化技巧

之前負責的錫慧在線小程式是一款公益性質在線教育類小程式，因疫情影響導致流量暴增，日訪問過百萬

高峰期每分鐘1w+在線訪問

影片播放卡頓嚴重，使用體驗很差。 部落客已是離職狀態，但是公司內並沒有找到可以接手的同學，小程式前端是我從零一手做出來的，有點特殊情感，於是就以小程式顧問的身份幫忙處理了小程式端的工作。

應對本次問題，影片卡頓是選擇把影片課件資源從文件伺服器上遷移至騰訊雲存儲，現已經修複發版完畢

在此總結下小程式優化相關知識。

# 小程式端

# 提高載入性能

小程式呈現到用戶面前，實際上經歷了下面兩個階段：

• 運行環境的預載入
  • 微信會在用戶打開小程式之前就已經準備好環境，用戶點擊小程式入口後，直接下載小程式的程式碼包即可
• 下載程式碼包啟動小程式
  • 小程式程式碼包裡面的程式碼，不是小程式的源程式碼，而是編譯、壓縮、打包之後的程式碼包

小程式提供的運行環境，分為邏輯層（AppService）和 視圖層（webView），邏輯層是執行javascript的地方，視圖層是渲染頁面的地方。當小程式的程式碼包下載完畢後，業務程式碼分別注入邏輯層和渲染層。

# 優化關鍵點

控制小程式包的大小

• 程式碼級優化
  • 壓縮程式碼
  • 清理無用的程式碼(含注釋掉的程式碼、log等)
  • 業務級優化，邏輯復用，組件復用
• 圖片優化
  • 放CDN
  • 選用其它靜態存儲伺服器
  • 最其次使用優化過大小後的本地圖片
• 採用分包策略
  • 分包預載入
  • 獨立分包

非同步請求優化

• onLoad階段就可發起請求
• 實時性要求不高的或者非頻繁變動的業務數據盡量不要在onShow時請求
• 請求結果放在快取中、利用時間戳控制有效期，減少更新次數
• 核心頁面在請求過程中添加骨架屏展示處理
• 細節體驗處理，及時給予用戶回饋
  • 如點擊按鈕後先改變樣式(切換啟停用狀態)，再發出請求，防止用戶多次請求

# 提高渲染性能

setData操作優化

• 減少setData的數據量
• 不影響渲染層的數據不用放在setData
• 合併精簡setData
• 避免列表數據全局刷新、局部更新單條數據

this.setData({    list[index] = newList[index]  })

定時器及時銷毀

• 小程式多個頁面會多開webview，獨立執行緒運行，當離開頁面存在定時器時需要及時銷毀

謹慎使用onPageScroll，該事件是一次webview層向js邏輯層的通訊，開銷較大

• 只在必要時監聽pageScroll
• onPageScroll中避免執行複雜邏輯，頻繁setData，查詢節點資訊

善用小程式組件 自定義組件更新只在組件內部進行，不受頁面其他內容影響

• 運營活動的定時模組可以單獨抽出來，做成一個定時組件，定時組件的更新並不會影響頁面上其他元素的更新；
• 各個組件具有各自獨立的邏輯空間，分別擁有自己的獨立的數據、setData調用

canvas渲染

• 分層繪製到不同canvas
• 不變的部分單獨繪製到一個canvas
• 動態生成的繪製到一個canvs

前端數據過濾

• 前端數據過濾及驗證，不規範的數據不必發送請求增加服務端壓力

開發者工具提供的環境與真機不同，建議真機調試

# 服務端

硬體升級

• 伺服器負載均衡
• 雲資料庫多台主從讀寫分離
• redis快取
• 小程式靜態資源使用CDN和OSS文件存儲

分析瓶頸

• 資料庫適當索引加持
• 找出導致瓶頸的關鍵業務，如密集計算需求，資料庫讀寫

redis快取

• 寫入數據時資料庫和redis中都寫入，優先查詢redis的數據，沒有再從資料庫讀取
• 進行介面快取，直接快取介面返回的json數據，用戶再次查相同的內容，直接返回json數據

負載均衡 將流量分發到不同的伺服器上進行處理，減輕對cpu的壓力

服務端建議嘗試雲開發，有騰訊雲的基礎服務加持也是可以支撐起百萬級訪問的