Regular進階: 幾點性能優化的建議

本文由做者鄭海波受權網易雲社區發佈。

本文旨在用 20% 的精力解決使用Regular過程當中 80% 的性能問題.

這裏大部分是關於髒檢查的性能優化，不瞭解的能夠先看下《Regular髒檢查介紹》

首先，咱們能夠用一個簡化後的公式來描述Regular的單次髒檢查的複雜度

N·logN · M · T

其中

N : 表明組件深度

M : 表明組件平均監聽器數量

T : 表明單個Watcher的檢查時間

這樣問題就落在瞭如何下降這三個因子了

下降N —— 組件層級
這層是收益最高的方案，由於影響因子是 N·logN.

以上圖爲例，葉子節點進行$update()時，會首先找到DigestRoot （默認狀況下，即頂層使用 new 建立的組件），再層層向下進行組件的$digest()檢查，在目前組件抽象較細緻的開發習慣下，很容易產生10多層的組件深度，適當控制下digest深度能夠獲得可觀的性能提高。

注 : 這個digest flow設計是爲了不產生網狀更新鏈

方案1. 使用isolate 控制digest深度
第一個方式即便用isolate屬性控制組件的數據流向，如 這樣,在第一次初始化後，b組件就再也不與a組件有任何數據綁定關係

如圖所示，b組件此時就會成爲g組件的實際DigestRoot。b組件內部的$update不會再會冒泡到外層

但這種方式同時讓a的數據變動沒法傳達到b組件極其內部，以下圖所示

若是須要實現a->b的單向傳導，能夠設置isolate=1

isolate = 1 實際就造成了組件的單向數據流

方案2. 合理抽象組件
除了經過isolate手動控制更新樹的深度以外，咱們直接減少組件深度固然也能夠。 但這彷佛與React等框架推崇的方式相悖，其實否則。

過分抽象的組件，除了引入使用負擔和增長組件層級外，沒法帶來直觀的收益。 抽象記得要基於複用的前提，沒有複用前提的組件抽象，除了讓你的文件夾變得更復雜外，毫無益處。 固然它能夠給你帶來好看的組件結構圖 :)

下降M: 平均監聽者數量
在Dirty-Check Loop中，在每一個組件節點上都會經歷$digest階段: 遍歷監聽者數組，檢查數據是否發生變動。

方案1. 升級到v0.5.2版本以上
首先將上面的公式再簡化,並拓展到 一輪完整的髒檢查Dirty-Check Loop ，能夠用下面的公式來表示

K·P·T

其中

K: 髒檢查穩定性檢測輪數 (1~30次不等，30次仍不穩定將拋出錯誤)

P:digest影響到的全部監聽器

T: 單個監聽器的消耗時間

在Github: 0.5.2版本，有一個優化就是講監聽器分爲了 穩定監聽器（stable) 和 不穩定監聽器(unstable)

不穩定的監聽器即具備Side Effect，好比

this.$watch('firstName', (firstName)=>{ this.data.nickname = firstName + '先生'})
當firstName改變時，nickname也會隨之改變，因此爲了確保不出錯，框架會檢測多輪直到這類監聽表達式再也不變化

穩定的監聽器就是一些沒有Side Effect的監聽好比大部份內置的監聽(文本插值、r-html、屬性插值等), 這類監聽處理邏輯只有讀操做，而沒有寫操做。其實只須要檢測一次便可

這樣公式就修改成了

K·P1·T + P2·T

其中 P1+P2 = P , P2 爲Stable監聽器， P1爲非穩定。不要小看這個優化，因爲內部監聽器中, P2的比例很高(超過80%)因此在K>1的狀況下，能夠帶來比較大的提高。

除此以外，你同時也能夠本身主動來標記哪一個監聽器是屬於stable

this.$watch('title', (title)=>{ this.$refs.top.innerText = title
}, {stable: true})

1. 使用一次綁定表達式@(expression)

除非明確了再也不對某個監聽感興趣，經過 一次綁定表達式 來提高性能其實並非特別關鍵，但若是這個表達式正好在一個list循環中，那控制的收益會比較大，好比

{#list list as item by item_index} <some-component list={@(item.list)} />{/list}
若是這個列表有100項，那能夠直接減小100個對item.list綁定(況且大部分狀況都不止一個屬性傳入)， 屬於操做少收益大。

下降T: 單個監聽器的平均消耗時間
其實每一個表達式好比user.firstName + '-' + user.lastName 須要判斷變化的開銷各不相同，咱們只須要針對高開銷的監聽器進行控制便可達到效果。

1. 儘量帶上list語句的by描述

list是最容易產生性能瓶頸的部分，下面作下簡單說明

默認狀況下，Regular使用的萊文斯坦編輯距離(Levenshtein Distance), 別被嚇到了，實際上wiki百科等資源上都有完成的僞代碼描述, 是個簡單的經常使用算法。

它的優勢是，不需額外標記，就能夠找到儘量少的步驟從一個字符串過渡到另外一個(但並不保證相同值必定被保留), 數組同理. 這樣映射到框架內部，就能夠以儘量少的步驟來變動DOM了,相信你們都知道DOM開銷很大了。

可是它的時間複雜度是O(n^2) ，在大列表下會帶來顯著的性能開銷, 甚至徹底超過DOM更新的開銷。

因此在Regular v0.3的某個版本引入了by的用法, 例如

{#list items as item by item_index}

<li>{item.name}</li>

{/list}
顧名思義，新舊列表按順序其item_index是不會變化的，即0,1,2... . 因此列表更新時，不會嘗試去銷燬重建，而是直接更新內部的值. 這種更新方式，內部的diff複雜度是 O(n), 屬於極大的優化了性能.並且在DOM更新上比LS算法模式更輕量

這樣用by item_index其實也帶來一個問題，就是雖然循環對應的值改變了，但內部組件是不會重建的，即config、init不會被觸發。

理論上 by 關鍵詞以後能夠接任意表達式，可是在以前版本是不生效的 (詳情看#90 regularJS的track by沒起做用) .

這個問題在最新版本已經被修復, 即你能夠更精確的控制，是否要複用某一個項對應結構(內部組件是不會重建的，即config、init不會被觸發)

{#list items as item by item.id} <li>{item.name}</li>{/list}
舉個例子，只要item.id ===0的項還在，那對應的DOM結構就確保不會被回收，只會進行更新操做. 這裏的時間複雜度也是O(n), 但實際開銷會比by item_index高很多。

1. 升級到v0.5.2減小銷燬時間

在以前的版本, Regular的模板內容在銷燬時，內部會進行大量的splice操做致使了性能問題，在0.5.2版本進行優化，總體銷燬時間有了 數倍的提高

總結
從操做難易度和關鍵度上，主要是如下建議

升級到Regular最新版本(也方便你使用最新的SSR、跨組件通訊等特性)，至少也是v0.5.2來總體提升性能(這個版本還作了很多別的性能優化)

list記得使用by語句，特別是by item_index (item_index取決於你的命名)

組件經過isolate來控制digest深度

本文來自於那個2年只更新了0.2個版本的Regular做者之手，請輕噴。

下一篇應該是關於跨組件通訊的文章。

更多網易技術、產品、運營經驗分享請訪問網易雲社區。

文章來源： 網易雲社區