用vue想拿20k，面試題要這樣答（原始碼版）

資料來源視頻：用vue想拿20k，面試題要這樣答
文章是在看完視頻之后總結的筆記 這個視頻我覺得他將的好是在于直接去決議vue的原始碼，從原始碼分析問題，簡而易懂且有說服力，

總結：一共9節9個小知識點

1、v-if和v-for的比較
2、vue組件data函式形式
3、key的作用
4、diff演算法
5、組件化
6、vue設計理念
7、MVC MVP 和MVVM
8、vue優化
9、vue3特性

1、v-if和v-for的那個優先級更高，如果兩個同時出現，應該怎么優化得到更好的性能

先上結論：v-for優先于v-if被決議

注：-l：是串列渲染的函式 return才是最終的結果，
查看vue原始碼：路徑為src/compiler/codegen/index.js檔案中發現

在原始碼中發現 先處理靜態節點（staticRoot） 然后處理once 最后才會處理for 代碼顯示for優先于if 斷點除錯之后也是證實for優先于if
結論：
1、v-for優先于v-if被決議（把你怎么知道的告訴面試官，看過原始碼）
2、如果同時出現，每次渲染都會先執行回圈在判斷條件，無論如何回圈都不可避免，浪費了性能
3、要避免出現這種情況，在外層嵌套template，在這一層進行v-if判斷，然后在內部進行v-for回圈

2、vue組件data為什么必須是個函式，而vue根實體則沒有此限制？

先上結論：
1、data必須是個函式是保證在多實體的時候，為了保護相互之間的狀態不干擾，不污染，
2、每次在創建根實體的時候，使用new的方式，全域的范圍內只創建一個，不會創建多個，不會存在污染的問題，因此可以不使用函式

函式每次執行都會回傳全新的data物件實體

測驗代碼如下：

資料初始化是在：src/core/instance/init.js檔案中

重點在于initData函式中 研究原始碼發現：

116行 這里會對data做一個判斷，如果data是function型別的則執行，并把結果作為data選項的值，
否則就使用用戶設定的data
在上面的測驗案列中 vue.component的comp屬性其實只執行了一次也就是說第二個引數選項在被處理的時候，只會處理一次，data的選項指向的都是同一個地方，一個組件的不同實體使用的其實就是一個data，由此產生了資料污染，
如果是一個組件，組件中的data不能像測驗中那樣設定

每次在創建根實體的時候，使用new的方式，全域的范圍內只創建一個，不會創建多個，不會存在污染的問題，因此可以不使用函式，

在多實體的時候，為了保護相互之間的狀態不干擾，不污染，vue的根實體所以需要使用function函式

結論：

vue組件可能存在多個實體，如果使用物件心事定義data，則會導致他們共用一個data物件，那么狀態變更將會影響所有的組件實體，這是不合理的；采用函式形式定義沒在initData是會將其作為工廠函式回傳全新data物件，有效規避多實體之間的狀態污染問題，而在vue根實體創建程序中則不存在改限制，也是因為根實體只能有一個，不需要擔心這種問題

3、key作業原理，說說對它的理解

原始碼中找答案：src/core/vdom/patch.js-updateChildren()
正常回答是：可以唯一確定一個dom元素，從而執行diff演算法更高效
案例分析：執行2秒后在c的前面插入f

如果不使用key 更新了3次 一次插入操作
使用了key只做了一次插入操作

結論：

1、key的作用主要是為了高效的更新虛擬DOM，其原理是vue在patch程序中通過key可以精準的判斷兩個節點是否是同一個，從而避免頻繁更新不同元素，使得整個patch程序更加高效，減少了dom的操作量，提高性能

2、如果不設定key可能在串列更新時引發一些隱藏的bug 比如說更新和不更新看不出來，

3、vue中在使用相同標簽名元素的過渡切換是，也會用到key屬性，其目的也是為了讓vue可以區分他們，否則vue只會替換其內部屬性而不會觸發過渡效果，需要用key來作為唯一性的判斷，

4、怎么理解vue中的diff演算法

總結：
diff演算法：并非vue中專用，凡是涉及到虛擬dom中都有diff演算法
必要性：diff演算法能精確的比較新舊虛擬DOM中的key的變化，從而提高更新效率
執行方式：深度優先，同級比較
高效性：
查看原始碼：

1、diff演算法必要性：

分析：任何一個vue組件實體，再去創建完成之后，去掛載的時候呼叫的，一個組件呼叫一次mounted，同時也會呼叫右側watcher，在vue中 watcher的實體和vue的實體是一一對應的，

結論：組件中存在多個data中key的使用，怎么確保key發生了變化，執行diff演算法就可以比較新舊兩次虛擬dom的比較，為了精確的知道

2、diff演算法的執行方式

核心原始碼：586行開始

分析：patchVnode是diff發生的地方，整體策略：深度優先，同層比較，
先開始比較根節點，看看是否有子節點，如果都有，更新子節點 在比較子節點，直到底層，
具體代碼



如果找到直接更新子節點，如果沒有就看有其他的操作，

3、diff演算法的高效性：

就是上面提到的updateChildern（）

總結：
1、diff演算法是虛擬DOM技術的必然產物：通過新舊虛擬DOM做對比（既diff），將變化的地方更新在真實DOM上，另外，也需要diff高效的執行對比程序，從而降低時間復雜度為O（n）
2、vue2.0x中為了降低watcher粒度，每個組件只有一個watcher與之對應，只有引入diff才能精確的找到發生變化的地方
3、vue中diff執行的時刻是組件實體執行更新函式時，它會對比與上一次渲染結果oldVnode和新的渲染結果，此程序稱為patch
4、diff程序整體遵循深度優先，同層次比較的策略，兩個節點之間比較會根據他們是否擁有子節點或者文本節點做不同操作，比較兩組子節點是演算法重點，首先假設頭部節點可能相同做4次對比嘗試，如果沒有找到相同節點才按照通用的方式去進行遍歷查找，查找結束再按情況處理剩下的節點，借助key通常可以非常精確找到相同節點，因此整個patch程序非常高效，

5、vue組件化的理解

總體回答思路：
組件化定義，優點，使用場景和注意事項等方面展開稱述，同時要強調vue組件化中一些特點

1、原始碼分析：組件定義

把一些獨立的功能單獨提出來，有獨立的函式，方便復用
vue中常見的定義第一種是全域定義 第二種是單檔案組件的定義

原始碼：src/global/assets.js/

2、原始碼分析：組件化優點

原始碼：lifecycle.js-mountComponent()
組件化優點：維護性 測驗性，復用性，從組件 Watcher，渲染函式中去分析
在執行組件的時候，每一個組件會對應一個watcher，組件邊變化的時候只會呼叫組件里面的渲染函式，可以把經常發生資料變化的單獨放一個組件中，后期只需要執行這一個函式，起到區域重繪的作用，

3、組件化的實作

建構式：src/core/global-api/extend.js
實體化及掛載：src/core/vdom、patch.js-createElm()
總結
1、組件是獨立和可復用的代碼組織單元，組件系統是vue核心特性之一，它使得開發者使用小型，獨立和通常可復用的組件構建大型應用
2、組件化開發能大幅度提高應用開發效率，測驗性，復用性等
3、組件使用按分類有：頁面組件，業務組件，通用組件
4.vue的組件是基于配置的，我們通常撰寫的組件是組件配置而非組件，框架后續會生成與其建構式，他們基于vueComponent，擴展與vue
5、vue中常見組件化技術有：屬性prop 自定義事件，插槽等，他們主要用于組件通信，擴展等
6、合理的劃分組件，有助于提升應用性能
7.組件內應該是高內聚，低耦合的
8、遵循單向資料流的原則

6、vue設計原則的理解

vue的官網上寫了定義和特點：
vue是一個漸進式的javscript框架
易用，高效，靈活

根據這個兩個點去回答
漸進式javascript框架：

跟其他大型框架不同的是，vue被設計為可以自底向上逐層應用，vue的核心庫只關注視圖層，不僅易于上手，還便于與第三方庫活既有的專案整合，另一方面，當現代的工具鏈以及各種支持類別庫結合使用的時候，vue也完全能夠為復雜的單頁面提供驅動
核心庫就是一些宣告是的渲染，組件系統 只關注視圖層
可以作為一個庫在其他專案中去用，也能作為一個大型的框架去搭建專案，這就是漸進式
學習程序也是漸進式的，只學習模板語法，基礎功能也能開發，后期才學習工程化，

易用性：

vue提供資料回應式，宣告式模板語法和基于配置的組件系統等核心特性，這些使我們只需要關注應用的核心業務即可，只要會寫js，html和css就能輕松撰寫vue應用

靈活性：

漸進式框架最大的優點就是靈活性，如果應用足夠小，我們可能僅僅需要vue的核心特性就能去完成功能了，隨著應用規模的不斷擴大，我們才可能追殲引入路由，狀態管理，vue-cli等庫和工具，不管是應用體積還是學習難度都是一個逐漸增加的平和曲線

高效性：

超快的虛擬DOM和diff演算法使我們的應用有最佳的性能表現，
追求更高效的程序還在繼續，vue3中引入proxy對資料回應式的改進以及編譯器中對于靜態內容的改進都會讓vue更加高效

7、MVC MVP 和MVVM的理解

答題思路：

涉及的知識點比較多，很難說清楚，說透，因為mvc MVp這些模式我們前端程式員自己都沒用過，當時恰恰反應了這些年全從無到有，從有到優的變化程序，沿著這個思路來回答

web1.0時代

在web1.0時代 并沒有前端的概念，開發用過web應用多數采用ASP.NET、java PHP 專案通常有多個aspx/jsp/hph的單檔案去組成，每個檔案都有html css js或者java代碼

為了讓開發更加便捷，代碼易于維護，前后端職責清晰，出現嗎MVC 開發模式和框架，前端展示模板的形式出現的典型的框架就是Spring Structs Hibernate （SSH）

目標就是把資料，視圖，業務邏輯控制分層，便于維護和讀寫，前端只完成后端中的view層
但是還是吧所有代碼邏輯放在服務端，
存在問題：1、前端頁面開發效率不高，2、前后端職責不清晰

web2.0時代

自從Gmail的出現 ajax技術開始出現，前后端職責就更加清晰了，因為前端可以通過ajax與后端進行整體的資料互動，因此，整體的架構圖也變化成了：

前端只需要開發頁面內容，資料由后臺提供，而且專案能實作ajax可以使得頁面實作部分重繪，減少了服務端負載和流量的消耗，很多渲染從服務端變成了客戶端，前端也發展了一些庫 jquery

存在問題：
缺乏可行的開發模式承載更復雜的業務需求，頁面內容都糅雜在一起，一旦應用規模增加，就會導致難以維護，因此，前端的MVC也隨之到來

前后端分離的架構演變：MVC MVP MVVM
MVC
前端的MVC與后端類似，具備View，Controller和Model
Model：負責應用資料的保存，與后端資料進行同步
Contoller：負責業務邏輯，根據用戶行為對Model資料進行修改
View：負責視圖展示，將model中的資料可視化出來
模型：

理論上是可行的，可是實際上并不方便，然后慢慢演變 （下面這個還是mvc）

這樣的模式也可能帶來一些問題：
1、資料流混亂

如圖 view比較龐大，controller比較單純，由于很多開發者會在view中寫一些邏輯的代碼 逐漸導致view中的內容會越來越大，而controller變的越來越單薄
前端的變化中 似乎少了mvp這種模式，是因為Angular早早的把MVVM模式代入前端 跳過了MVP

MVP
MVP與mvc很接近 P指的是Persenter 理解為一個中間人，他負責view和model之間的資料流，防止view好emodel之間直接交流，

P負責和M還有V進行雙向互動，view變成了被動視圖，而且本身編的很小，分離了v和m，但是應用變的很大，導致P的體積增大，難以維護，

MVVM

mvvm核心是中間的vm層：
ViewModel通過實作一套資料相應式機制自動回應Model中數據變化，同時ViewModel會實作一套更新側率自動將資料變化轉化為視圖更新
通過時間監聽回應View中用戶互動修改Model中資料，
這樣在ViewModel中就減少了大量DOM操作代碼
MVVM在保持view和Model松耦合的同時，還減少了維護他們的關系的代碼，使用用戶專注于業務邏輯，兼顧開發率和可維護性

總結：
1、這三者都是框架模式，他們的設計目標都是為了解決Model和View的耦合問題
2、MVC模式出現較早主要應用在后端，如Spring MVC ASP.NET MVC等，有點是分層清晰，缺點是資料流混亂，靈活性帶來的維護問題
3.MVP模式在MVC的進化形式， Presenter作為中間層負責MV通訊，解決了兩者的耦合問題，但p層過去臃腫會導致維護問題
4、MVVM模式在前端領域有廣泛應用，他不僅解決了MV耦合問題，還同時解決了維護兩者射影關系的大量繁雜代碼和DOM操作，也就是說不用去挨個改變DOM操作了，在提高開發效率，可讀性同時還保持了優越的性能表現

8、你了解哪些vue的性能優化方法

主要討論vue層面的優化

1、路由懶加載：

2、keep-alive快取頁面

3、使用v-show復用DOM

4、v-for遍歷避免同時使用v-if

計算屬性提前把陣列進行過濾

5、長串列性能優化

如果串列純粹是顯示資料 不會有改變 資料就不需要回應式

使用freeze方法進行凍結，或者更改屬性為false

如果是大資料串列，可以采用虛擬滾動，只渲染少部磁區域內容

參考第三方組件

6、事件銷毀

vue組件銷毀時，會自動解綁他的全部指令及事件監聽器，但僅限于組件本身的事件

7、圖片懶加載

對于圖片過多的頁面 為了加速頁面的加載速度，所以很多時候我們需要將頁面內未出現在可視區域內的圖片不做加載，等到滾動到可視區域之后再去加載

8、第三方插件按需匯入

像element-ui這樣的第三方組件庫可以按需映入避免體積太大

使用bable的插件

9、無狀態組件標記為函式式組件

展示型組件 ，這樣的話就沒有實體 標記functional

10.子組件分割

子組件中有一些比較耗時的就單獨分割成為一個組件，自己做自己的渲染，不會影響其他的組件

11、變數本地化

reault實際上是computed出來的屬性 同時也是base的屬性 base屬性比較耗時，

12 、SSR

服務端渲染，

9 vue3.0的新特性

更快：

虛擬DOM重寫
優化slots的生成
靜態樹提升
靜態屬性提升
基于Proxy的回應式系統

更小：

通過搖樹優化核心庫體積 靜態節點標記出來 減少重寫

更容易維護：

TypeScript+模塊化

更加友好：

跨平臺：編譯器核心和運行核心與平臺無關，使得vue更容易與任何平臺（web Android IOS）一起使用

更容易使用：

改進的TypeScript支持，編輯器能提供強有力的型別檢查和錯誤及警告
更好的除錯支持
獨立的回應式模塊
CompositionAPI

重點提出幾個方向來寫：
虛擬DOM重寫
期待更多的編譯時提示來減少運行時的開銷，使得有效代碼來創建虛擬節點
組件快速路勁+單個呼叫+子節點型別檢測
跳過不必要的條件分支
JS引擎更容易優化

優化slots生成
vue3中可以單獨重新渲染父級和子級
確保實體正確的跟蹤依賴關系
避免不必要的父子組件重新渲染

靜態樹提升 （staticTree Hoisting）
使用靜態樹提升，意味著vue3的編譯器將能夠檢測到什么是靜態的 然后將其提升，從而降低了渲染成本、
跳過修補整棵樹，從而降低渲染成本
即使多次出現也能正常作業

靜態屬性提升
使用靜態屬性的提升，vue3打補丁的時候將跳過這些屬性不會改變的節點 孩子還需要繼續改變

基于Proxy的資料回應式
vue2.0使用的是Object.definfPropertyde getter 和setter vue3將使用ES6中的Proxy作為觀察機制：
組件實體初始化速度提100%
使用Proxy節省以前一半的記憶體太小，就愛快速度，但存在低瀏覽器版本不兼容，為了繼續支持IE11 vue3將發布一個就觀察者機制 和新的Proxy版本構建

高可維護性
vue3將帶來更可維護性的源代碼，不僅使用Typescript 而且還許多包被解耦 更加模塊化

今天是國慶最后一天啦，沉寂了很久最近也要開始認真學習了，得有三個多月沒好好寫博客做筆記了，最近也開始新的規劃準備寫新的系列了，主要還是vue一些底層原理和演算法吧，秋招已經落下帷幕，目前已經穩定了，繼續學習 準備春招，能看到這里的同學一定很棒，學習的道路很難，但是難得時候說明你在走上坡路，加油，一定會活成你想要的樣子的！！！