在學(xué)習(xí)React源碼之前，我們先搞清楚框架的范式都有哪些?？蚣芊妒街饕袃煞N：命令式和聲明式，目前大部份流行框架都采用聲明式渲染，為什么都選擇聲明式渲染呢？對(duì)比命令式它有什么優(yōu)勢(shì)呢？為了搞清楚這些問(wèn)題，我們先從動(dòng)態(tài)渲染頁(yè)面的三種方式：純JS運(yùn)算，innerHTML，虛擬DOM，分別比較他們的性能、可維護(hù)性和心智負(fù)擔(dān)，來(lái)闡明基于虛擬DOM聲明式渲染的優(yōu)勢(shì)。然后會(huì)說(shuō)到與聲明式框架密切相關(guān)的運(yùn)行時(shí)和編譯時(shí)。相信看完你會(huì)對(duì)React、Vue這一類(lèi)采用虛擬DOM的聲明式框架有自己的理解。

1. 命令式和聲明式

在對(duì)比之前，我們先了解一下什么是聲明式，什么是命令式，它們各有什么優(yōu)缺點(diǎn)。作為框架學(xué)習(xí)者，了解這兩種范式的框架對(duì)學(xué)習(xí)框架思想很有幫助。 我們先看看命令式和聲明式框架的概念和具體形式。

1.1 命令式

什么是命令式？早年間大范圍流行的JQuery就是典型的命令式框架，命令式框架最大的特點(diǎn)是關(guān)注過(guò)程，例如我要做如下DOM操作：

• 獲取id為app的div元素
• 把元素的顯示文本設(shè)置為 hello world
• 給他綁定點(diǎn)擊事件
• 事件內(nèi)容是彈窗提示ok

用jQuery可以寫(xiě)出如下代碼:

$("#app") // 1
.text("hello world") // 2
.on('click', function(){ // 3
    alert("ok") // 4
})

可以看到自然語(yǔ)言描述能夠跟實(shí)際寫(xiě)代碼一一對(duì)應(yīng)起來(lái)，寫(xiě)代碼本身就是在描 述做事的過(guò)程，這很符合日常生活的直覺(jué)和邏輯。而且整個(gè)過(guò)程沒(méi)有任何其他的性能開(kāi)銷(xiāo)，因此命令式框架的性能一搬都非常不錯(cuò)。

1.2 聲明式

什么是聲明式？與命令式框架不同關(guān)注過(guò)程不同，聲明式框架更 關(guān)注結(jié)果 ，所見(jiàn)即所得。按照框架的規(guī)范，聲明出用戶想要的結(jié)果，具體怎么實(shí)現(xiàn)無(wú)需關(guān)心，都交給框架處理。 同樣上面的那個(gè)例子里面，用React這種聲明式的框架可以這樣寫(xiě):

<div id="app" onClick={()=>alert("ok")}>hello world</div>

在react里面一般都是用JSX描述頁(yè)面的dom結(jié)構(gòu)。可以看到我們只需提供一個(gè)最終的“結(jié)果”，至于具體怎么實(shí)現(xiàn)這個(gè)結(jié)果的過(guò)程，我們并不需要關(guān)心。換句話說(shuō)React框架幫我們封裝了實(shí)現(xiàn)的過(guò)程，因此應(yīng)該能夠猜到React框架內(nèi)部實(shí)現(xiàn)一定是命令式的，但是暴露給用戶的是更加直觀的聲明式。

1.3 兩種范式的性能和易維護(hù)性

我們首先拋出一個(gè)結(jié)論：聲明式代碼的性能不優(yōu)于命令式代碼的新能。為什么呢？還是拿上面的例子來(lái)說(shuō)，如果要把文本內(nèi)容改為：“react”，用命令式代碼就很簡(jiǎn)單，因?yàn)橛脩裘鞔_的知道要修改的是什么，直接調(diào)用相關(guān)api即可：

app.textContent = 'react'

試想一下，有沒(méi)有其他的實(shí)現(xiàn)方式比這個(gè)代碼性能更好的？答案是沒(méi)有，因?yàn)槲覀兠鞔_的知道是哪些地方發(fā)生了變化，直接修改變化的地方就行， 因此命令式的代碼能做到極致的性能優(yōu)化。但是聲明式的代碼目前還做不到這一點(diǎn)，因?yàn)樗硎龅氖墙Y(jié)果：

// 之前
<div id="app" onClick={()=>alert("ok")}>hello world</div>
// 之后
<div id="app" onClick={()=>alert("ok")}>react</div>

對(duì)于框架來(lái)說(shuō)，為了實(shí)現(xiàn)最好的更新性能，框架需要找到新舊DOM的差異，并且只更新有差異的地方，最終還是用命令式的代碼完成這次變更：

app.textContent = 'react'

如果把修改文本的性能消耗為A，找出新舊內(nèi)容差異的性能損耗為B，那么會(huì)有如下公式：

• 命令式的代碼更新性能為：A
• 聲明式的代碼更新性能為：B + A

可以看出，聲明式代碼比命令式代碼多了找出差異的性能消耗，最理想的情況是查找差異性能的消耗為0，此時(shí)命令式代碼和聲明式代碼的性能相同，但是無(wú)法超過(guò)命令式代碼。因?yàn)?strong>框架本身封裝了命令式的代碼才實(shí)現(xiàn)了面向用戶的聲明式，這也側(cè)面印證了之前的結(jié)論：聲明式代碼的性能不優(yōu)于命令式代碼的新能。

既然命令式代碼性能這么好，又直接，為啥還有類(lèi)似React，Vue這樣的聲明是框架呢？原因是聲明式代碼的可維護(hù)性更強(qiáng)。從之前的例子可以看出，采用命令式代碼實(shí)現(xiàn)的時(shí)候，我們需要關(guān)注整個(gè)實(shí)現(xiàn)過(guò)程的每一步，包括DOM元素的創(chuàng)建、獲取、更新、刪除等操作，過(guò)程繁瑣而且抽象，心智負(fù)擔(dān)高。而聲明式代碼展示就是最終我們想要的結(jié)果，更加直觀，只關(guān)注結(jié)果效率高，而實(shí)現(xiàn)結(jié)果的命令式的代碼框架內(nèi)部已經(jīng)實(shí)現(xiàn)，不需要用戶關(guān)心。

但是聲明式代碼在提升可讀性和維護(hù)性的同時(shí)，面臨的問(wèn)題是性能上有一部分損耗，所以框架要做的是：保持可維護(hù)性的同時(shí)讓性能損耗最小。在這種前提下，就有人提出了 虛擬節(jié)點(diǎn)(Virtual DOM) 這種找出新舊差異的方案，并被廣泛運(yùn)用于React，Vue這類(lèi)框架之中。那么虛擬DOM的性能到底如何呢？

2. 虛擬DOM的性能如何

說(shuō)到這里相信大家有一個(gè)基本的了解，那就是采用虛擬DOM的框架更新新時(shí)，理論上性能不會(huì)比原生JS操作dom性能更好，理論上是指用戶寫(xiě)的命令式代碼是絕對(duì)優(yōu)化的。在實(shí)際場(chǎng)景中這很難，可能需要投入巨大的精力，所以投入產(chǎn)出比不高，目前只談理論性能。
那么有沒(méi)有一種辦法既不需要投入太大的精力，又能保證代碼程序的性能下限，不至于讓?xiě)?yīng)用程序性能太差。甚至經(jīng)過(guò)一定的優(yōu)化處理，接近命令式代碼的性能呢？其實(shí)這就是虛擬DOM要解決的問(wèn)題。

上文說(shuō)的原生JS操作dom的命令式代碼，指的是document.createElement等方法，不包括innerHTML這個(gè)方法，它比較特殊，需要單獨(dú)探討它。在早年使用JQuery或直接寫(xiě)原生JS代碼的時(shí)候，innerHTML操作dom是非常常見(jiàn)的。那么我們可以考慮以下幾個(gè)問(wèn)題：

• innerHTML的渲染流程是什么樣的？
• innerHTML的性能相比較虛擬DOM誰(shuí)的性能好？

首先對(duì)于第一個(gè)問(wèn)題，對(duì)于innerHTML創(chuàng)建頁(yè)面，需要先構(gòu)造一段HTML字符串：

let htmlStr = '<ul>'
for(let i=0; i<data.length; i++) {
   htmlStr += `<li>${data[i].name}</li>`
}
htmlStr += '</ul>'

然后把這個(gè)字符串賦值給dom元素的innerHTML屬性:

app.innerHTML = htmlStr

在賦值之后，由于要渲染出頁(yè)面，首先要吧字符串解析成DOM樹(shù)，這一步是DOM層面的計(jì)算。然而，涉及DOM的運(yùn)算性能要遠(yuǎn)比JS層面的計(jì)算性能差很多，我們可以在jsbench.me這個(gè)網(wǎng)站上給它們跑個(gè)分，比較創(chuàng)建10000個(gè)js對(duì)象和10000個(gè)dom元素的性能，結(jié)果如下：

我們可以看出，純JS運(yùn)算要比操作DOM快得多，他們不在一個(gè)數(shù)量級(jí)上?；谶@個(gè)前提，我們可以得出innerHTML創(chuàng)建頁(yè)面的性能為：拼接HTML字符串的計(jì)算量 + innerHTML 的 DOM計(jì)算量。

我們?cè)倏吹诙€(gè)問(wèn)題，innerHTML的性能相比較虛擬DOM誰(shuí)的性能好？我們?cè)倏匆幌绿摂Mdom創(chuàng)建頁(yè)面的過(guò)程。第一步，先創(chuàng)建JS對(duì)象，這個(gè)對(duì)象是對(duì)真實(shí)DOM的描述，也就是大家說(shuō)的虛擬DOM，第二部是遞歸JS對(duì)象并創(chuàng)建所有對(duì)應(yīng)的真實(shí)DOM。我們也可以用一個(gè)公式來(lái)表述他們的性能消耗：創(chuàng)建JS對(duì)象的計(jì)算量 + 創(chuàng)建真實(shí)DOM的計(jì)算量。

1.比方說(shuō)有這樣一個(gè)虛擬dom對(duì)象：

const vdom = {
  type:'ul',
  children: {
    type: 'li',
  }
}

2.遞歸對(duì)象創(chuàng)建真實(shí)DOM渲染到頁(yè)面

function render(vdom, anchor){
 const el = document.createElement(vdom.type)
 anchor.appendChild(el)
 if(vdom.children){
   render(children, el)
 }
}
render(vdom)

我們列一個(gè)表格對(duì)比一下純JS運(yùn)算、虛擬DOM和innerHTML創(chuàng)建頁(yè)面時(shí)所消耗的性能：

我們可以看出虛擬DOM和innerHTML創(chuàng)建頁(yè)面時(shí)流程差不多，性能兩者差別不大。在相同數(shù)量級(jí)上面，基本上沒(méi)有什么區(qū)別，因?yàn)槎家陆ㄋ械腄OM元素。

看到這里可能有人會(huì)說(shuō)，性能都差不多那還要虛擬DOM干嘛，這不是多此一舉嘛。別急，上面說(shuō)的的新創(chuàng)建DOM。在都是新創(chuàng)建所有的DOM元素來(lái)說(shuō)虛擬DOM對(duì)比innerHTML在性能上確實(shí)沒(méi)有任何優(yōu)勢(shì)可言。但是在我們更新頁(yè)面的時(shí)候，哪怕我們只改了一個(gè)字，用innerHTML這種方式更新頁(yè)面時(shí)，要先銷(xiāo)毀之前所有的DOM元素，然后根據(jù)新的html字符串重新創(chuàng)建所有的DOM。我們?cè)倏纯刺摂MDOM是怎么更新頁(yè)面的，它需要重新創(chuàng)建js對(duì)象(vdom)，然后比較新舊虛擬DOM，找到變化的元素然后更新它。如下面這個(gè)表格所示：

在頁(yè)面更新的時(shí)候，采用虛擬DOM更新頁(yè)面，由于經(jīng)過(guò)JS計(jì)算出哪些DOM元素需要更新，只需要更新對(duì)應(yīng)的DOM元素即可。而采用innerHTML這種方式需要先銷(xiāo)毀所有的DOM元素，然后又創(chuàng)建所有DOM。綜合之前的JS運(yùn)算比DOM運(yùn)算的性能快的多的結(jié)論下，這時(shí)候虛擬DOM的優(yōu)勢(shì)就提現(xiàn)出來(lái)了。

此外，當(dāng)頁(yè)面頁(yè)面更新時(shí)，影響虛擬DOM的性能因素與影響innerHTML的性能因素補(bǔ)貼。對(duì)于虛擬DOM來(lái)說(shuō)，無(wú)論頁(yè)面多大，只更新變化的內(nèi)容，所以性能跟變化內(nèi)容的大小有關(guān)。對(duì)innerHTML這種方式來(lái)說(shuō)，就不關(guān)系變化內(nèi)容的大小了，只關(guān)心要渲染性能跟html字符串的大小有關(guān)。

基于上面的描述，我們可以總結(jié)一下原生JS(指createElement等方法)、虛擬DOM、innerHTML這三個(gè)方法在更新頁(yè)面時(shí)候的性能，如下表所示：

我們分了一個(gè)維度去考量:心智負(fù)擔(dān)、可維護(hù)性、性能：

• 對(duì)于純JS運(yùn)算，毫無(wú)疑問(wèn)原生JS的DOM操作這種方式心智負(fù)擔(dān)最大，因?yàn)樾枰謩?dòng)增刪改查大量的DOM元素。但它的性能是最好的，不過(guò)要承受巨大的心智負(fù)擔(dān)，而且代碼可能讀性很差，不便于后期維護(hù)。
• 對(duì)于innerHTML，由于有一部分是拼接字符串來(lái)實(shí)現(xiàn)的，有點(diǎn)類(lèi)似于聲明式的代碼了，但也存在著一定的心智負(fù)擔(dān)，而且其他的DOM操作（綁事件，增加屬性等）還是得通過(guò)原生JS來(lái)處理。此外如果html字符串如果很大的話還可能有性能問(wèn)題。
• 對(duì)于虛擬DOM：由于虛擬DOM是聲明式的，心智負(fù)擔(dān)比較小，可維護(hù)性強(qiáng)，性能雖然比不上極致優(yōu)化的原生JS，但是在頁(yè)面更新的時(shí)候也有著不錯(cuò)的性能。

一番權(quán)衡之后，發(fā)現(xiàn)虛擬 DOM 是個(gè)還不錯(cuò)的選擇。這也是大部份流行框架采用虛擬DOM的原因。

可能有的人要問(wèn)了，有沒(méi)有一種方法能做到：既可以聲明式的描述UI結(jié)構(gòu)，同時(shí)又具備原生JS的性能呢？這些問(wèn)題在下一節(jié)討論。

3. 運(yùn)行時(shí)和編譯時(shí)

我們先來(lái)說(shuō)一下純運(yùn)行時(shí)的框架。假如我們?cè)O(shè)計(jì)了一個(gè)框架，它提供了一個(gè)Render函數(shù)，用戶只要傳入虛擬DOM，Render函數(shù)就會(huì)遞歸創(chuàng)建真實(shí)DOM把它插入到對(duì)應(yīng)的節(jié)點(diǎn)，還是拿之前的代碼為例：

3.1 運(yùn)行時(shí)

1.虛擬dom對(duì)象：

const vdom = {
  type:'ul',
  children: {
    type: 'li',
  }
}

2.創(chuàng)建真實(shí)DOM：

function render(vdom, anchor){
 const el = document.createElement(vdom.type)
 anchor.appendChild(el)
 if(vdom.children){
   render(children, el)
 }
}
render(vdom)

3.2 運(yùn)行時(shí) + 編譯時(shí)

在瀏覽器上運(yùn)行這段代碼可以看到預(yù)期的結(jié)果。但是有人會(huì)說(shuō)，寫(xiě)這樣的dom描述對(duì)象太不直觀了，而且手寫(xiě)起來(lái)很麻煩。有沒(méi)有一種方式能夠支持寫(xiě)HTML就能得到dom描述對(duì)象呢？答案是有的，我們可以引入編譯手段，將寫(xiě)好的HTML編譯成dom描述對(duì)象，再把這個(gè)對(duì)象交給Render函數(shù)，將他渲染到頁(yè)面上。流程如下：

• 寫(xiě)了一個(gè)Compiler程序，將HTML聲明式的代碼變成了產(chǎn)出dom描述對(duì)象的函數(shù)：

const el = <div id="app" onClick={()=>alert("ok")}>react</div>
const vdom = Compiler(el) 

• 上面的vdom就會(huì)編譯成如下結(jié)果:

{
  type: 'div',
  props: { 
    click: () => alert("ok"),
    chilren: ['react']
  }
}

• Render函數(shù)傳入編譯得到的dom描述對(duì)象就可以把之前聲明式的dom節(jié)點(diǎn)渲染到頁(yè)面上了。

Render(vdom, container)

實(shí)際上面就是 運(yùn)行時(shí) + 編譯時(shí) 框架的基本工作流程。用戶可以選擇提供dom描述對(duì)象或者寫(xiě)HTML片段，來(lái)描述UI界面，如果是dom描述對(duì)象就直接渲染，如果是HTML片段就先編譯再渲染。代碼運(yùn)行起來(lái)才進(jìn)行編譯，叫做運(yùn)行編譯時(shí)，這會(huì)產(chǎn)生一定的性能開(kāi)銷(xiāo)，所以有些框架可以在構(gòu)建的時(shí)候執(zhí)行Compiler將提供的內(nèi)容 提前編譯好，運(yùn)行的時(shí)候就無(wú)需編譯了，這對(duì)程序性能也有一部分提升。像React，Vue就是這么做的。

3.3 編譯時(shí)

有人可能會(huì)問(wèn)了，既然能把能把HTML片段編譯成dom描述對(duì)象，那為啥不直接HTML片段編譯成命令式的代碼呢？答案是可以的，這樣就不支持任何運(yùn)行時(shí)內(nèi)容，用戶的代碼需要編譯才能運(yùn)行，它就是純編譯時(shí)框架了。目前就有一些框架把聲明式的代碼編譯成命令式代碼，例如：sveltejs、solidjs等框架，它既保持了聲明式的易維護(hù)特性，又保證了程序的性能。

4. 總結(jié)

我們先討論了命令式和聲明式這兩種范式的差異，其中命令式更加關(guān)注過(guò)程，而 聲明式更加關(guān)注結(jié)果。命令式在理論上可以做到極致優(yōu)化，但是用戶要承受巨大的心智負(fù)擔(dān)；而 聲明式能夠有效減輕用戶的心智負(fù)擔(dān)，但是性能上有一定的犧牲，框架要想辦法盡量使性 能損耗最小化。

后面，我們討論了虛擬 DOM 的性能，并給出了一個(gè)公式：聲明式的更新性能消耗 = 找出 差異的性能消耗 ＋ 直接修改的性能消耗。虛擬DOM 的意義就在于使找出差異的性能消耗最小 化。我們發(fā)現(xiàn)，用原生JavaSoript操作DOM 的方法（如 document.createElement ）、虛擬 DOM 和 tnnerHTML 三者操作頁(yè)面的性能，不可以簡(jiǎn)單地下定論，這與頁(yè)面大小、變更部分的大小都有關(guān) 系，除此之外，與創(chuàng)建頁(yè)面還是更新頁(yè)面也有關(guān)系，選擇哪種更新策略，需要我們結(jié)合心智負(fù)擔(dān)、 可維護(hù)性等因素綜合考慮。

再后面了解了運(yùn)行時(shí)和編譯時(shí)的相關(guān)知識(shí)和各自的特點(diǎn)。

下一節(jié)我們著重來(lái)說(shuō)一下React聲明式框架是如何將JSX創(chuàng)建虛擬DOM，以及虛擬DOM是怎么渲染到頁(yè)面上的。

到此這篇關(guān)于React中的聲明式渲染框架的文章就介紹到這了,更多相關(guān)React渲染框架內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論