京東云開發者|關于“React 和 Vue 該用哪個”我真的栓Q( 四 )


京東云開發者|關于“React 和 Vue 該用哪個”我真的栓Q

文章插圖
  • Vue是借助 ES6 的API攔截數據操作,分別在數據讀取、設置階段進行依賴的收集和通知,數據的依賴其實是一個個 Watcher 對象(Watcher 可能是組件、計算屬性、或者 Watch方法) 。如果 Watcher 是組件的情況,則再調用組件的 render 函數生成虛擬DOM ,與舊虛擬 DOM 做對比,進行更細粒度的 UI 更新 。在這里借助依賴收集和局部的 DOM Diff,平衡了全量 DOM Diff 帶來的性能影響 。更新機制如下圖(來自 Vue 官網):

京東云開發者|關于“React 和 Vue 該用哪個”我真的栓Q

文章插圖
8. 性能對比對比說明
  • 拋開場景談性能,就像拋開劑量談毒性,全是瞎扯,所以本章節性能對比的數據皆有據可查,對比僅覆蓋了一些常見場景,但未能覆蓋全部場景:
  • 框架測試用例倉庫(點擊查看),截止到2022年6月23日,已有 4.6k Star,
  • 對比數據(點擊查看),可根據條件篩選框架對比的結果
  • 測試中的對比對象:React v18.0.0 和Vuev3.2.37,不包含舊版本框架,本著框架升級帶來性能提升的常規認知(反優化的案例也不是沒有,但不在這做考慮),本章節默認最新版本的React和Vue在各自歷史版本中擁有著最優性能 。
  • 測試使用設備配置:i7-8750H, 64 GB RAM, Fedora 36 (Linux 5.17.3, mitigations=off, Wayland)
  • 測試使用瀏覽器:Chrome 102.0.5005.61 (64-bit)
  • 其他:本章節的數據對比,是對已有結果的總結
對比內容1)持續時間,這里進行的主要是數據量較大的列表操作,對比維度為:
    • 創建列表
    • 替換所有行
    • 局部更新
    • 選擇行
    • 交換行
    • 刪除行
    • 創建多行
    • 追加多行
    • 刪除多行結論:可以看到Vue在此場景中近乎完勝,尤其是交換行的情況下,Vue 更是大幅度領先 。結果可查看下圖 , 綠色表示操作所需時間更短 , 紅色表示操作所需時間長 。vanillajs 那一列指的是原生 js 下的性能數據 。

京東云開發者|關于“React 和 Vue 該用哪個”我真的栓Q

文章插圖
2)啟動指標,主要從以下幾個方面對比:
    • 加載時長:主要指標是TTI(Time To Interactive),指從頁面開始加載到頁面可進行交互的時長 , TTI 值越?。磧沒Э梢愿緄夭僮饕趁?,體驗就越好
    • 主線程工作時間:包含樣式、布局、執行邏輯等
    • 網絡傳輸字節數:指加載頁面中所有資源的成本
    • 結果如下圖,仍然是Vue的成績較為優秀:

京東云開發者|關于“React 和 Vue 該用哪個”我真的栓Q

文章插圖
3)以 MB 為單位的內存分配,對比維度為:
    • 頁面加載后的內存使用情況
    • 運行內存,添加 1000 行后的內存使用情況
    • 每 10 行點擊更新 5 次后的內存使用情況
    • 單擊創建 1000 行 5 次后的內存使用情況
    • 創建和清除 1000 行 5 次后的內存使用情況
    • 結果如下圖,Vue 依然勝出了:

京東云開發者|關于“React 和 Vue 該用哪個”我真的栓Q

文章插圖
  • 4)聊些對比之外的話以上在運行時的對比都是以1000行數據為基準做參考,問各位小伙伴一個問題 , 如果數據量更龐大呢,5w行或者10w行,再或者50w行?數據會有變化嗎?各位可以再思考一下這個問題:那僅僅從以數據作為評測標準又是否可行呢?其實筆者不以為然,雖然React的數據落于下風 , 但是從React的 Fiber 架構上看,尤其涉及到超過一定數量級的虛擬 DOM 對比上,React 是具有優勢的,此架構下的 Diff 不會阻塞主線程,用戶對 UI 界面依然有控制權 , 雖然頁面數據沒有更新,但是對于用戶的感知是相對友好的 。所以筆者認為以下對比數據具有參考性,但并非是決定性的,在框架對比上還是希望各位小伙伴有多方面更理性的思考。
9. 心智模型關于心智負擔 , 有觀點認為React重,也有觀點認為Vue重,而筆者認為都有道理 , 原因是兩方的關注點不同 。
說React重,可以從兩方面闡述: