成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

Regular進階: 幾點性能優(yōu)化的建議

idealcn / 2114人閱讀

摘要：不要小看這個優(yōu)化，由于內(nèi)部監(jiān)聽器中的比例很高超過所以在的情況下，可以帶來比較大的提升。但是它的時間復雜度是，在大列表下會帶來顯著的性能開銷甚至完全超過更新的開銷。更多網(wǎng)易技術產(chǎn)品運營經(jīng)驗分享請訪問網(wǎng)易云社區(qū)。文章來源網(wǎng)易云社區(qū)

本文由作者鄭海波授權(quán)網(wǎng)易云社區(qū)發(fā)布。

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

這里大部分是關于臟檢查的性能優(yōu)化，不了解的可以先看下《Regular臟檢查介紹》

首先，我們可以用一個簡化后的公式來描述Regular的單次臟檢查的復雜度

N·logN · M · T

其中

N : 代表組件深度

M : 代表組件平均監(jiān)聽器數(shù)量

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

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

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

以上圖為例，葉子節(jié)點進行$update()時，會首先找到DigestRoot （默認情況下，即頂層使用 new 創(chuàng)建的組件），再層層向下進行組件的$digest()檢查，在目前組件抽象較細致的開發(fā)習慣下，很容易產(chǎn)生10多層的組件深度，適當控制下digest深度可以得到可觀的性能提升。

注 : 這個digest flow設計是為了避免產(chǎn)生網(wǎng)狀更新鏈

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

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

但這種方式同時讓a的數(shù)據(jù)變更無法傳達到b組件極其內(nèi)部，如下圖所示

如果需要實現(xiàn)a->b的單向傳導，可以設置isolate=1

isolate = 1 實際就形成了組件的單向數(shù)據(jù)流

方案2. 合理抽象組件
除了通過isolate手動控制更新樹的深度之外，我們直接減小組件深度當然也可以。 但這似乎與React等框架推崇的方式相悖，其實不然。

過度抽象的組件，除了引入使用負擔和增加組件層級外，無法帶來直觀的收益。 抽象記得要基于復用的前提，沒有復用前提的組件抽象，除了讓你的文件夾變得更復雜外，毫無益處。 當然它可以給你帶來好看的組件結(jié)構(gòu)圖 :)

降低M: 平均監(jiān)聽者數(shù)量
在Dirty-Check Loop中，在每個組件節(jié)點上都會經(jīng)歷$digest階段: 遍歷監(jiān)聽者數(shù)組，檢查數(shù)據(jù)是否發(fā)生變更。

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

K·P·T

其中

K: 臟檢查穩(wěn)定性檢測輪數(shù) (1~30次不等，30次仍不穩(wěn)定將拋出錯誤)

P:?digest影響到的所有監(jiān)聽器

T: 單個監(jiān)聽器的消耗時間

在Github: 0.5.2版本，有一個優(yōu)化就是講監(jiān)聽器分為了 穩(wěn)定監(jiān)聽器（stable) 和 不穩(wěn)定監(jiān)聽器(unstable)

不穩(wěn)定的監(jiān)聽器即具有Side Effect，比如

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

穩(wěn)定的監(jiān)聽器就是一些沒有Side Effect的監(jiān)聽比如大部分內(nèi)置的監(jiān)聽(文本插值、r-html、屬性插值等), 這類監(jiān)聽處理邏輯只有讀操作，而沒有寫操作。其實只需要檢測一次即可

這樣公式就修改為了

K·P1·T + P2·T

其中 P1+P2 = P , P2 為Stable監(jiān)聽器， P1為非穩(wěn)定。不要小看這個優(yōu)化，由于內(nèi)部監(jiān)聽器中, P2的比例很高(超過80%)所以在K>1的情況下，可以帶來比較大的提升。

除此之外，你同時也可以自己主動來標記哪個監(jiān)聽器是屬于stable

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

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

除非明確了不再對某個監(jiān)聽感興趣，通過 一次綁定表達式 來提升性能其實并不是特別關鍵，但如果這個表達式正好在一個list循環(huán)中，那控制的收益會比較大，比如

{#list list as item by item_index} {/list}
如果這個列表有100項，那可以直接減少100個對item.list綁定(何況大部分情況都不止一個屬性傳入)， 屬于操作少收益大。

降低T: 單個監(jiān)聽器的平均消耗時間
其實每個表達式比如user.firstName + "-" + user.lastName 需要判斷變化的開銷各不相同，我們只需要針對高開銷的監(jiān)聽器進行控制即可達到效果。

盡可能帶上list語句的by描述

list是最容易產(chǎn)生性能瓶頸的部分，下面做下簡單說明

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

它的優(yōu)點是，不需額外標記，就可以找到盡可能少的步驟從一個字符串過渡到另一個(但并不保證相同值一定被保留), 數(shù)組同理. 這樣映射到框架內(nèi)部，就可以以盡可能少的步驟來變更DOM了,相信大家都知道DOM開銷很大了。

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

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

{#list items as item by item_index}

  • {item.name}

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

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

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

    這個問題在最新版本已經(jīng)被修復, 即你可以更精確的控制，是否要復用某一個項對應結(jié)構(gòu)(內(nèi)部組件是不會重建的，即config、init不會被觸發(fā))

    {#list items as item by item.id}

  • {item.name}
    • {/list}
    舉個例子，只要item.id ===0的項還在，那對應的DOM結(jié)構(gòu)就確保不會被回收，只會進行更新操作. 這里的時間復雜度也是O(n), 但實際開銷會比by item_index高不少。

    升級到v0.5.2減少銷毀時間

    在之前的版本, Regular的模板內(nèi)容在銷毀時，內(nèi)部會進行大量的splice操作導致了性能問題，在0.5.2版本進行優(yōu)化，整體銷毀時間有了 數(shù)倍的提升

    總結(jié)
    從操作難易度和關鍵度上，主要是以下建議

    升級到Regular最新版本(也方便你使用最新的SSR、跨組件通信等特性)，至少也是v0.5.2來整體提高性能(這個版本還做了不少別的性能優(yōu)化)

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

    組件通過isolate來控制digest深度

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

    下一篇應該是關于跨組件通信的文章。

    更多網(wǎng)易技術、產(chǎn)品、運營經(jīng)驗分享請訪問網(wǎng)易云社區(qū)。

    文章來源： 網(wǎng)易云社區(qū)

    文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

    轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/25332.html

    相關文章

    • Regular進階： 跨組件通信

      摘要：以上面的例子為代表完整生命周期如下下一篇，應該會以為例，介紹一種基于來解決跨組件的數(shù)據(jù)通信的方式免費領取驗證碼內(nèi)容安全短信發(fā)送直播點播體驗包及云服務器等套餐更多網(wǎng)易技術產(chǎn)品運營經(jīng)驗分享請訪問網(wǎng)易云社區(qū)。文章來源網(wǎng)易云社區(qū) 本文由作者鄭海波授權(quán)網(wǎng)易云社區(qū)發(fā)布。 背景在組件化不斷深入的大環(huán)境下，無論使用哪種 MDV 框架都最終會遇到一個頭疼的問題，就是「跨組件通信」。 下圖是個簡單的例子 ...

      keithyau 評論0 收藏0

    • 正則表達式

      摘要：最全正則表達式總結(jié)驗證號手機號中文郵編身份證地址等是正則表達式的縮寫，作用是對字符串執(zhí)行模式匹配。學習目標了解正則表達式語法在中使用正則表達式在中使 JS高級技巧 本篇是看的《JS高級程序設計》第23章《高級技巧》做的讀書分享。本篇按照書里的思路根據(jù)自己的理解和經(jīng)驗，進行擴展延伸，同時指出書里的一些問題。將會討論安全的類型檢測、惰性載入函數(shù)、凍結(jié)對象、定時器等話題。1. 安全的類型檢測...

      yibinnn 評論0 收藏0

    • 你只知道別人很牛，卻不知道那些1-5年的Android開發(fā)者是如何提升的

      摘要：作為開發(fā)年的開發(fā)者該如何系統(tǒng)的提升自己如今，國內(nèi)移動互聯(lián)網(wǎng)的紅利期已過，開發(fā)工程師也從最初的一人難求，到現(xiàn)在的一個崗位百人競爭，僧多粥少的情況直接導致整個行業(yè)對求職者的要求越來越高。另外，開發(fā)越來越規(guī)范，間接導致項目對質(zhì)量要求的提升。 ...

      lpjustdoit 評論0 收藏0

    • API

      摘要：是一個極度純凈的上傳插件，通過簡單調(diào)整就可以融入到任何項目，支持多文件上傳上傳速率動態(tài)控制真實進度監(jiān)控分塊生成分塊上傳校驗秒傳暫停取消等。 跨域?qū)W習筆記 前言: 當一個資源，向與之所在服務器不同的域或端口請求另一個資源時，這個HTTP請求，我們認為是跨域的請求。出于安全考慮，瀏覽器會限制腳本發(fā)起的跨域HTTP請求。 那天后端讓我把token放到http請求頭字段里，說是為了和RN端統(tǒng)一...

      lsxiao 評論0 收藏0

    • 【回顧九月份第二周】 前端你該知道的事兒

      摘要：順便一說，這首歌的原唱是秋田，中島當年嗓子壞了，才有這歌。中文是直接翻譯來的，作曲是秋田。一部電影春夏秋冬又一春春夏秋冬又一春是由金基德執(zhí)導，金英民吳英秀金基德主演的一部韓國電影。年月日于韓國上映。 原鏈接： http://bluezhan.me/weekly/#/9-2 1、web前端 Angular vs. React vs. Vue: A 2017 comparison 9 S...

      sixgo 評論0 收藏0

    發(fā)表評論

    0條評論

    閱讀需要支付1元查看
    <