記一次針對線上微信電競小程序賽事富文本資訊模塊進行優化。git
原有的資訊採用管理端富文本編輯保存
HTML 文本,因爲小程序提供的 rich-text
組件 沒法支持 video
標籤等侷限性,在小程序端採用 wxParse 外部開源框架 進行轉換和渲染,經過將後臺 CGI 返回的 HTML 文本 轉換成 JSON 樹再進行模版渲染的方式展現。github
因爲賽事資訊大部分會包含騰訊視頻,而騰訊視頻播放路徑須要經過騰訊視頻 SDK 將管理端保存資訊的視頻 VID 轉換出來,所以在 wxParse 工做以前,須要解析 HTML 文本 將 VID 轉換成對應的騰訊視頻播放路徑。小程序
在實際體驗中,發如今某些狀況下在打開資訊,內容呈現時間(這裏的內容呈現時間是指用戶從進入資訊詳情頁拉取到後臺接口返回的文本內容開始到頁面內容呈現到用戶面前之間所須要的時間)會比較慢,所以對其進行了分析優化。微信
目前小程序主要跑在Android和iOS端,可能不一樣的系統性能不一致,致使不一樣機型設備的內容呈現時間有明顯的性能差別。而另外一方面,包含騰訊視頻的資訊,須要經過騰訊視頻SDK走網絡請求進行轉換,所以呈現也可能跟網絡類型相關。網絡
故此,對影響內容呈現時間的因素作了兩點推測:框架
經過以前在小程序端的性能打點上報,以及部門內部的數據自助平臺提取上報的數據,能夠快速地分析到不一樣機型、不一樣網絡類型的平均內容呈現時間。ide
不一樣平臺類型下的平均內容呈現時間post
平臺 | 平均呈現時間(ms) |
---|---|
Android | 1084 |
iOS | 961 |
不一樣網絡類型下的平均內容呈現時間性能
網絡類型 | 平均呈現時間(ms) |
---|---|
wifi | 937 |
4G | 905 |
3G | 1020 |
2G | 1248 |
經過數據大概能夠看到在 Android 和 iOS 兩大平臺中,平均內容呈現時間相差並不大,iOS 略優於 Android 端。而在網絡狀況下,wifi 和 4G 狀況相比 3G 和 2G 狀況,平均內容呈現時間較短。從數據上看,影響內容呈現時間的主要因素是網絡類型。優化
目前微信電競小程序中賽事資訊分爲3種:
因爲大部分的賽事資訊在內容中會包含騰訊視頻 (本文也是針對包含視頻內容的資訊進行優化來展開),而騰訊視頻播放路徑須要經過騰訊視頻 SDK 將管理端保存資訊的視頻 VID 轉換出來,所以在 wxParse 工做以前,須要解析 HTML 文本 將 VID 轉換成對應的騰訊視頻播放路徑。
所以,目前包含視頻的資訊,在完整渲染出來,須要通過如下流程:
其整個過程是一個串行的工做流,下一步的執行須要上一步的結果輸出以後才能執行,所以內容呈現時間能夠由下面公式算出:
內容呈現時間 = 騰訊視頻 VID 轉換 URL 所需時間 + HTML 文本轉換 JSON 結構所需時間 + JSON 結構模版渲染所需時間
經過對現網的上報數據進行分析,發現 騰訊視頻 VID 轉換 URL 和 JSON 結構模版渲染 這兩部分所須要時間比較長。從上面的數據上報分析,也驗證了影響頁面呈現時間的主要因素是騰訊視頻 VID 轉換 URL這一過程這一結論。
既然視頻資訊在解析渲染是一個串行的工做流,那麼咱們想辦法將這個工做流搞成並行的,不就能夠節省一部分時間?能夠很容易發現,騰訊視頻 VID 轉換 URL 這一步驟能夠在小程序進行模版渲染的時候,同時進行處理。
小程序的邏輯層和渲染層是分開的兩個線程
所以,經過此方案優化後,頁面的呈現時間能夠由下面公式算出:
內容呈現時間 = HTML 文本轉換 JSON 結構所需時間 + Max(騰訊視頻 VID 轉換 URL 所需時間, JSON 結構模版渲染所需時間)
在實際優化過程當中,對 wxParse 進行了改造優化,改形成小程序自定義組件,加上對騰訊視頻解析的優化,也剔除了對業務內不須要用到的特性(好比 wxParse 對錶情 Emoli 處理)。
平臺 | 平均呈現時間(ms) |
---|---|
Android | 766 |
iOS | 613 |
能夠對比以前的內容呈現時間,在Android 和 iOS上 能夠優化300-400ms以內,小小的優化,倒是須要作大量的功課。
最後,想體驗的能夠掃如下小程序碼: