passive的作用和原理
passived到底有什麼用？
passived主要用於優化瀏覽器頁面滾動的效能，讓頁面滾動更順滑~~
passived產生的歷史時間線
addEventListener()：大家都是認識的，為dom新增觸發事件，故事就從這裡開始。
在早期addEventListener是這樣的：
addEventListener(type, listener, useCapture)useCapture:是否允許事件捕捉，但是很少會傳true，然後就變成可選項了：
addEventListener(type, listener[, useCapture ])到現在就變成了這個樣子：
addEventListener(type, listener, { capture: false, //捕獲 passive: false, once: false //只觸發一次 })
我們的主角passive就出現了
passive為什麼能優化頁面的滾動效能？
簡述chrome的執行緒化渲染框架
chrome的執行緒化渲染框架的兩個執行緒：
- 核心執行緒（Main/Render Thread）：負責DOM樹構建、元素的佈局、圖層繪製記錄部分（main-thread side）、JavaScript的執行
- 合成執行緒（Compositor Thread）：圖層繪製實現部分（impl-side）、圖層影象合成
上圖可知，頁面Frame#1在核心執行緒中完成js執行、佈局和繪製後，經過一個週期合成執行緒去執行Frame#1頁面影象的合成。
使用者輸入事件分類：
- 在核心執行緒處理的事件
- 直接由合成執行緒處理的事件
那麼有什麼區別呢？
在核心執行緒處理的事件：需要經過核心執行緒處理的輸入事件要在核心執行緒執行邏輯，遇到核心執行緒在忙，無法立即響應。如使用者的大部分輸入事件都跟頁面元素有關係，一旦頁面元素註冊了對應事件的監聽器，監聽器的邏輯程式碼（JavaScript）必須在核心執行緒中執行（V8引擎執行在核心執行緒），因此這種輸入事件經常無法立即得到響應。
直接由合成執行緒處理的事件：不經過核心執行緒就能快速處理的輸入事件為手勢輸入事件（滑動、捏合）。
劃重點：最騷的來了，雖然手勢事件可以不在核心執行緒處理，但是手勢事件的產生還是離不開核心執行緒。
頁面卡頓的原因
手勢事件有個屬性 cancelable,作用是告訴瀏覽器該事件是否允許監聽器通過 preventDefault() 方法阻止，預設為true。如果在touch事件內部呼叫preventDefault()，事件預設行為被取消，頁面也就靜止不動了。但是瀏覽器並不知道touch事件內部是否呼叫了preventDefault()，瀏覽器只有等核心執行緒執行到事件監聽器對應的JavaScript程式碼時，才能知道內部是否會呼叫preventDefault函式來阻止事件的預設行為，所以瀏覽器本身無法優化這種場景。手勢輸入事件是由連續的普通輸入事件組成的，在這種場景下，無法快速產生，會導致頁面無法快速執行滑動邏輯，從而讓使用者感覺到頁面卡頓。
而Chrome團隊從統計資料中分析得出，註冊了mousewheel/touch相關事件監聽器的頁面中，80%的頁面內部都不會呼叫preventDefault函式來阻止事件的預設行為。對於這80%的頁面，即使監聽器內部什麼都沒有做，相對沒有註冊mousewheel/touch事件監聽器的頁面，在滑動流暢度上，有10%的頁面增加至少100ms的延遲，1%的頁面甚至增加500ms以上的延遲。Chrome團隊認為對於統計中的這80%的頁面來說，他們都是不希望因為註冊mousewheel/touch相關事件監聽器而導致滑動延遲增加的。
passive的誕生
所以，passive 監聽器誕生了，passive 的意思是“順從的”，表示它不會對事件的預設行為說 no，瀏覽器知道了一個監聽器是 passive 的，它就可以在兩個執行緒裡同時執行監聽器中的 JavaScript 程式碼和瀏覽器的預設行為了。
經過上面的分析，我們瞭解到了Passive Event Listeners特性實際上是為了解決瀏覽器頁面滑動流暢度而設計的，它通過擴充套件事件屬性passive讓Web開發者來告知瀏覽器監聽器是否會阻止事件的預設行為，從而讓瀏覽器可以更智慧地決策並優化，這其中涉及到了Chrome的多執行緒渲染框架、輸入事件處理等知識。
總結
參考自：
https://blog.csdn.net/dj0379/...
http://www.cnblogs.com/ziyunf...
本文主要是對上面提及兩篇文章的總結和整理，理順一下自己的思路。如果我寫得不夠明白可以去看看兩位大佬的文章。