摘要：到此為止所承擔的操作與非常相近，但是為了讓與相互獨立，改變后的通知是分發給，收到改變的通知就會調用的接口來改變用戶界面。的優點非常顯然，極大的提高了可維護性，與之間的相互手動維護更新被釋放，改為自動更新。

　　首先歡迎大家關注我的掘金賬號和Github博客，也算是對我的一點鼓勵，畢竟寫東西沒法獲得變現，能堅持下去也是靠的是自己的熱情和大家的鼓勵。

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

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

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

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

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

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

其實所描述的DOM結構就是下面的樣子:

    按鈕

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

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