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...

本文主要是對上面說起兩篇文章的總結和整理，理順一下本身的思路。若是我寫得不夠明白能夠去看看兩位大佬的文章。