摘要：到此為止所承擔(dān)的操作與非常相近，但是為了讓與相互獨(dú)立，改變后的通知是分發(fā)給，收到改變的通知就會(huì)調(diào)用的接口來(lái)改變用戶界面。的優(yōu)點(diǎn)非常顯然，極大的提高了可維護(hù)性，與之間的相互手動(dòng)維護(hù)更新被釋放，改為自動(dòng)更新。

　　首先歡迎大家關(guān)注我的掘金賬號(hào)和Github博客，也算是對(duì)我的一點(diǎn)鼓勵(lì)，畢竟寫東西沒(méi)法獲得變現(xiàn)，能堅(jiān)持下去也是靠的是自己的熱情和大家的鼓勵(lì)。

　　之所以想寫本系列文章的主要原因是將近一個(gè)月時(shí)間沒(méi)有寫點(diǎn)東西了，加上最近各種事情特別多使得我沒(méi)有過(guò)多的時(shí)間研究自己喜歡的東西。前段時(shí)間看到大神livoras的博客，關(guān)于Virtual DOM的講解的非常透徹，由于自己從事React開(kāi)發(fā)，也算是Virtual DOM的使用者，所以萌發(fā)了寫關(guān)于Virtual DOM的系列文章，并且也想嘗試自己實(shí)現(xiàn)一套Virtual DOM。因此本系列文章會(huì)圍繞這Virtaul DOM這個(gè)話題做一系列的分析甚至也會(huì)嘗試著和大家一起實(shí)現(xiàn)自己的Virtual DOM 框架，感興趣的同學(xué)可以關(guān)注的我的掘金賬號(hào)或者關(guān)注我的Github博客。
　　

　　首先聽(tīng)到Virtual DOM這個(gè)概念應(yīng)該來(lái)自于React，并且在不了解時(shí)覺(jué)得這個(gè)概念是一個(gè)逼格特別高的詞。其實(shí)任何技術(shù)的誕生都是有相應(yīng)的歷史的，沒(méi)有任何事物是憑空出現(xiàn)的，就像我聽(tīng)到很多人詬病JavaScript語(yǔ)言的語(yǔ)法糟粕太多，但實(shí)質(zhì)上你要了解到JavaScript出現(xiàn)的原因和它的作者Brendan Eich僅僅用了十幾天就設(shè)計(jì)出一門廣泛流行的高級(jí)語(yǔ)言，你一定不會(huì)這樣想。同樣的，Virtual DOM的出現(xiàn)也是有一定的歷史原因的，這就不得不講到前端框架的歷史了。
　　
　　其實(shí)所有框架所能做到的事情我們手動(dòng)都可以實(shí)現(xiàn)，對(duì)于我們?cè)诖髮W(xué)課堂(當(dāng)然有的學(xué)習(xí)并沒(méi)有開(kāi)設(shè)相關(guān)的課程)的學(xué)習(xí)JavaScript時(shí)候，想用JavaScript創(chuàng)建一個(gè)表單驗(yàn)證的程序時(shí)，十幾行代碼就能搞定，這時(shí)候框架這種東西對(duì)你是臃腫的、沒(méi)有必要的。甚至框架會(huì)極大的提高你的學(xué)習(xí)成本、降低你程序的運(yùn)行速度(框架并不能保證效率一定高于你的手動(dòng)操作)。但是當(dāng)你的程序規(guī)模逐漸增大，你會(huì)發(fā)現(xiàn)你的代碼數(shù)量會(huì)指數(shù)級(jí)膨脹，甚至一個(gè)js文件中會(huì)有上萬(wàn)行的代碼(不要驚訝，我真的見(jiàn)過(guò)這場(chǎng)常見(jiàn))，這時(shí)候維護(hù)這套代碼將是一場(chǎng)災(zāi)難。
　　
　　這時(shí)候各種前端框架就應(yīng)用而生了，框架出現(xiàn)的目的并不是為了提升性能，而是為了可維護(hù)性、為了便于團(tuán)隊(duì)開(kāi)發(fā)。但是天下沒(méi)有白吃的午餐，你為了程序的可維護(hù)性，出讓了一部分性能作為妥協(xié)，畢竟什么框架都沒(méi)有手動(dòng)原生操作性能高，因?yàn)榭蚣芤哂羞m普性，要能處理各種各樣的場(chǎng)景。
　　

　　其實(shí)對(duì)于前端所需要的做的就是展示數(shù)據(jù)的界面(View)以及在界面的更改能觸發(fā)相應(yīng)的數(shù)據(jù)(Model)變化，并且數(shù)據(jù)(Model)發(fā)生改變時(shí)界面(View)也能及時(shí)響應(yīng)并做相應(yīng)的變化。說(shuō)到底就是如何協(xié)調(diào)View與Modal的關(guān)系。
　　
　　
　　早期出現(xiàn)類似于Backbone的框架就是典型的MVC(其實(shí)我也并沒(méi)有經(jīng)歷過(guò)這個(gè)年代)。通過(guò)在View與Model設(shè)置Controller層，這樣用戶交互觸發(fā)的操作都會(huì)轉(zhuǎn)交給Controller,由Controller層控制相應(yīng)的改變Model的數(shù)據(jù)。在Model數(shù)據(jù)發(fā)生改變時(shí)，會(huì)通過(guò)觀察者模式去通知對(duì)應(yīng)的View，然后View重新請(qǐng)求Model數(shù)據(jù)做相應(yīng)的界面改變。
　　
　　隨著應(yīng)用規(guī)模的增加你會(huì)發(fā)現(xiàn)MVC模式會(huì)存在幾個(gè)顯著的問(wèn)題，Model與View的對(duì)應(yīng)關(guān)系是多對(duì)多的，可能一個(gè)Model會(huì)對(duì)應(yīng)多個(gè)View或者一個(gè)View對(duì)應(yīng)多個(gè)Model，甚至更加復(fù)雜的場(chǎng)景，Model與View之間錯(cuò)綜復(fù)雜的關(guān)系使得開(kāi)發(fā)的難度增加。并且由于View是依賴于Model的，因此想要在這種模式下實(shí)現(xiàn)視圖的組件化是相對(duì)比較難的。
　　

　　我們并不希望View和Model之間依賴的這么緊，所以我們可以改進(jìn)MVC模式，就出現(xiàn)了MVP模式。
　　
　　
　　
　　MVP是MVC的改進(jìn)版本，將MVC中的Controller改為Presenter，用戶交互觸發(fā)的操作會(huì)轉(zhuǎn)交給Presenter處理。然后會(huì)由Presenter控制改變相應(yīng)Model的改變。到此為止Presenter所承擔(dān)的操作與Controller非常相近，但是為了讓Model與View相互獨(dú)立，Model改變后的通知是分發(fā)給Presenter，Presenter收到Model改變的通知就會(huì)調(diào)用View的接口來(lái)改變用戶界面。
　　
　　這樣我們通過(guò)Presenter就實(shí)現(xiàn)了Model和View的相互獨(dú)立，只要View與Model之間預(yù)留好所需要的接口，二者互相是沒(méi)有影響關(guān)系，互相是透明的，在這個(gè)基礎(chǔ)上，我們要實(shí)現(xiàn)View的組件化是非常容易的。但是這種模式也并不是沒(méi)有缺點(diǎn)，Presenter的邏輯不僅需要承擔(dān)之前Controller的所有功能，而且還需要接受Model數(shù)據(jù)改變的通知并按照對(duì)應(yīng)的功能改變用戶界面，這就使得Presenter所要承擔(dān)的功能過(guò)于多，使得Presenter太臃腫、難以維護(hù)。
　　

　　我們發(fā)現(xiàn)MVP也有相應(yīng)的缺點(diǎn)，因此前人在MVP的基礎(chǔ)上做了改良，出現(xiàn)了MVVM的結(jié)構(gòu)。
　　
　　
　　
　　我們看到MVP的缺點(diǎn)主要是Presenter過(guò)于龐大，其實(shí)Model改變通知Presenter并且Presenter改變View這條邏輯并不是一定需要手動(dòng)控制，其實(shí)對(duì)應(yīng)的Model變化引起對(duì)應(yīng)固定的View改變的規(guī)則一般來(lái)講是不變的，那這一部分邏輯就可以釋放出來(lái)由引擎自動(dòng)處理。MVP按照這個(gè)思路進(jìn)行改良，將原來(lái)的Presenter進(jìn)化為View Of Model(VM:視圖模型)，視圖模型中包含Binder(或者說(shuō)是Data-binding engine)，負(fù)責(zé)View與Model的雙向綁定。在編寫View時(shí)可以使用聲明式的指令將View與對(duì)應(yīng)的Model進(jìn)行綁定。ViewModel在對(duì)應(yīng)Model進(jìn)行改變時(shí)可以自動(dòng)更新View，同理View發(fā)生改變時(shí)，ViewModel也會(huì)對(duì)應(yīng)Model的數(shù)據(jù)，這也就是我們通常所講雙向數(shù)據(jù)綁定(Two-way data-binding)。
　　
　　MVVM的優(yōu)點(diǎn)非常顯然，極大的提高了可維護(hù)性，View與Model之間的相互手動(dòng)維護(hù)更新被釋放，改為自動(dòng)更新。但是由于ViewModel的構(gòu)建和維護(hù)成本相對(duì)較高，對(duì)于一些簡(jiǎn)單的頁(yè)面并不適用，對(duì)于復(fù)雜的視圖卻又帶來(lái)了性能成本。
　　

　　到此為止我們了解了MV*類型的框架是如何解決Model層與View層連接的，通過(guò)在Model與View之間構(gòu)建各種中間層(Controller、Presenter、View of Model)來(lái)處理兩者之間的同步關(guān)系。但是我們能不能換一種思路，View可以看成Model對(duì)應(yīng)一定規(guī)則的視圖表示，因此當(dāng)Model發(fā)生改變時(shí)直接重新渲染View。
　　
　　我們不禁感到這種操作方式真是騷??！
　　
　　
　　
　　這種方法行不行？當(dāng)然！其實(shí)React的總體思路不就是這種嗎？但是經(jīng)驗(yàn)豐富的你一定會(huì)立刻質(zhì)疑這東西性能靠譜嗎？事實(shí)上，如果Model改變引起的View改變非常大(譬如所有的界面都改變了)，這種模式反而性能會(huì)很好，因?yàn)楸旧淼慕缑娓淖兙偷韧谥匦落秩?。但是如果?dāng)前的Model改變只會(huì)引起界面一個(gè)非常細(xì)微的變化(例如某個(gè)按鈕的顏色發(fā)生改變)，我們就重新刷新整個(gè)界面，那實(shí)在是太恐怖了。
　　
　　搞過(guò)前端的同學(xué)一定都明白DOM的速度相比于JavaScript的簡(jiǎn)直就是龜速，因?yàn)镈OM的屬性、結(jié)構(gòu)本身就設(shè)計(jì)的非常復(fù)雜。那這種方式是不是就完全可以廢棄呢？
　　
　　不是！否則React就不會(huì)出現(xiàn)。
　　
　　大學(xué)學(xué)習(xí)過(guò)計(jì)算機(jī)組成原理的同學(xué)應(yīng)該還記的，CPU的計(jì)算速度是非常快，但是相比于CPU，其他的IO部件，例如硬盤，速度是非常低的，差的都不是一個(gè)數(shù)量級(jí)的問(wèn)題。這時(shí)候計(jì)算機(jī)就引入了RAM，RAM的速度低于CPU但是卻高于硬盤，對(duì)于CPU所需的數(shù)據(jù)，可以先從硬盤放入RAM，然后CPU運(yùn)算的結(jié)果也放入RAM中，如果需要數(shù)據(jù)的永久化存儲(chǔ)時(shí)才會(huì)存入硬盤中。甚至CPU會(huì)覺(jué)得RAM速度還是慢，在CPU內(nèi)部引進(jìn)了各級(jí)Cache，來(lái)解決RAM與CPU之間的性能瓶頸。
　　
　　前端就可以借鑒這種思維方式，DOM是低速的，但JavaScript性能確實(shí)相當(dāng)?shù)牟诲e(cuò)，尤其在擁有V8引擎的今天。那么我們就可以用JavaScript來(lái)描述DOM結(jié)構(gòu)，類似于下面的結(jié)構(gòu):
　　

其實(shí)所描述的DOM結(jié)構(gòu)就是下面的樣子:

    按鈕

　　當(dāng)然這種表示方法并不唯一，只要能描述清對(duì)應(yīng)的DOM結(jié)構(gòu)，你可以隨意發(fā)揮。
　　
　　這樣在每次Model改變之后，我們首先可以拿到本次Model的對(duì)應(yīng)的Virtual DOM結(jié)構(gòu)，它代表的就是本次Model對(duì)應(yīng)View的DOM結(jié)構(gòu)。如果我們還在程序中緩存了上次Model對(duì)應(yīng)的Virtual DOM結(jié)構(gòu)，那么我們就可以去比較前后兩個(gè)Virtual DOM結(jié)構(gòu)，采用一定的算法，得出兩個(gè)Virtual DOM的不一致的地方，這個(gè)算法就是我們通常所講的Diff算法。然后用最優(yōu)的方法將兩個(gè)Virtual DOM的差異應(yīng)用的真實(shí)DOM上。
　　
　　那這種方式一定是高于我們最開(kāi)始所講的重新渲染的思路嗎？當(dāng)然不是，如果界面變化非常大，那么我們之前所講的Virtual DOM性能可能就低于重新渲染,因?yàn)镈iff的過(guò)程也是有性能損耗了，即使在React采用了各種啟發(fā)式算法將兩個(gè)Virtual DOM樹(shù)形結(jié)構(gòu)由O(n ^ 3)降到了O(n)的情況下，在節(jié)點(diǎn)非常多的情況下，Diff的代價(jià)也是要被考慮的。
　　

　　本篇文章我們大致環(huán)顧了各種MV*框架的改進(jìn)歷史，從而講述了React所提出的另一套新穎的解決思路，并且為什么React會(huì)引入Virtual DOM的原因。讀到這里可能對(duì)你了解Virtual DOM有了些許幫助，歡迎大家關(guān)注我的博客，以后會(huì)繼續(xù)更新Virtual DOM的系列文章以及其他我在前端學(xué)習(xí)中感悟。如有不正確的地方，歡迎各位賜教。