借負責的小程序流量暴增事件總結下優化技巧
之前負責的錫慧在線微信小程序是一款公益性質在線教育類小程序，因疫情影響導致流量暴增，日訪問過百萬
高峰期每分鐘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的壓力
服務端建議嘗試云開發，有騰訊云的基礎服務加持也是可以支撐起百萬級訪問的
先總結這么多，如果您有更多方法，歡迎補充
