毫無疑問，nodeJS改變了整個前端開發生態。本文通過分析nodeJS當中events模組原始碼，由淺入深，動手實現了屬於自己的ES6事件觀察者系統。千萬不要被nodeJS的外表嚇到，不管你是寫nodeJS已經輕車熟路的老司機，還是初入前端的小菜鳥，都不妨礙對這篇文章的閱讀和理解。
事件驅動設計理念
nodeJS官方介紹中，第二句話便是：
"Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient"。
由此，“事件驅動（event-driven）”理念對nodeJS設計的重要性可見一斑。比如，我們對於檔案的讀取，任務佇列的執行等，都需要這樣一個觀察者模式來保障。
那個最熟悉的陌生人
同時，作為前端開發人員，我們對於所謂的“事件驅動”理念——即“事件釋出訂閱模式（Pub/Sub模式）”一定再熟悉不過了。這種模式在js裡面有與生俱來的基因。我們可以認為JS本身就是事件驅動型語言：
比如，頁面上有一個button, 點選一下就會觸發上面的click事件。這是因為此時有特定程式正在監聽這個事件，隨之觸發了相關的處理程式。
這個模式最大的一個好處在於能夠解耦，實現“高內聚、低耦合”的理念。那麼這樣一個“熟悉的”模式應該怎麼實現呢？
其實社群上已經有不少前輩的實現了，但是都不能算特別完美，或者不能完全符合特定的場景需求。
本文通過解析nodeJS原始碼中的events模組，提取其精華，一步步打造了一個基於ES6的eventEmitter系統。
讀者有任何想法，歡迎與我交流。同時希望各路大神給予斧正。
背景簡介
為了方便大家理解，我從一個很簡單的頁面例項說起。
百度某產品頁面中，存在兩處不同的收藏元件：
- 一處在頁面頂部；
- 一處在頁面詳情側欄。
第一次點選一個收藏元件按鈕，傳送非同步請求，進行收藏，同時請求成功的回撥函式裡，需要將頁面中所有“收藏”按鈕轉換狀態為“已收藏”。以達到“當前文章”收藏狀態的全域性同步。
完成這樣的設計很簡單，我們大可在業務程式碼中進行混亂的操作處理，比如初學者常見的做法是：點選第一處收藏，非同步請求之後的回撥邏輯裡，修改頁面當中所有收藏按鈕狀態。
這樣做的問題在於耦合混亂，不僅僅是一個收藏元件，試想當程式碼中所有元件全都是這樣的“隨意”操作，後期維護成本便一發不可收。
我的Github倉庫中，也有對於這麼一個頁面例項的分析，讀者若想自己玩一下，可以訪問這裡。
當然，更優雅的做法就是使用事件訂閱釋出系統。
我們先來看看nodeJS是怎麼做的吧！
nodeJS方案
讀者可以自己去nodeJS倉庫查詢原始碼，不過更推薦參考我的Github-事件釋出訂閱研究專案，裡面不僅有自己實現的多套基於ES6的事件釋出訂閱系統，也“附贈”了nodeJS實現原始碼。同時我對原始碼加上了漢語註釋，方便大家理解。
在nodeJS中，引入eventEmitter的方式和例項化方法如下：
// 引入 events 模組
var events = require('events');
// 建立 eventEmitter 物件
var eventEmitter = new events.EventEmitter();複製程式碼我們要研究的，當然就是這個eventEmitter例項。先不急於深入原始碼，我們需要在使用層面先有一個清晰的理解和認知。不然盲目閱讀原始碼，便極易成為一隻“無頭蒼蠅”。
一個eventEmitter例項，自身包含有四個屬性：
_events：
這是一個object，其實相當於一個雜湊map。他用來儲存一個eventEmitter例項中所有的註冊事件和事件所對應的處理函式。以鍵值對方式儲存，key為事件名；value分為兩種情況，噹噹前註冊事件只有一個註冊的監聽函式時，value為這個監聽函式；如果此事件有多個註冊的監聽函式時，value值為一個陣列，陣列每一項順序儲存了對應此事件的註冊函式。
需要說明的是，理解value值的這兩種情況，對於後面的原始碼分析非常重要。我認為nodeJS之所以有這樣的設計，是出於效能上的考慮。因為很多情況（單一監聽函式情況）並不需要在記憶體上新建一個額外陣列。_eventsCount：整型，表示此eventEmitter例項中註冊的事件個數。
_maxListeners：整型，表示此eventEmitter例項中，一個事件最多所能承載的監聽函式個數。
domain：在node v0.8+版本的時候，釋出了一個模組：domain。這個模組做的是捕捉非同步回撥中出現的異常。這裡與主題無關，不做展開。
同樣，eventEmitter例項的建構函式原型上，包含了一些更為重要的屬性和方法，包括但不限於：
- addListener(event, listener)：
為指定事件新增一個註冊函式（以下稱監聽器）到監聽器陣列的尾部。他存在一個別名alias：on。 - once(event, listener)：
為指定事件註冊一個單次監聽器，即監聽器最多隻會觸發一次，觸發後立刻解除該監聽器。 - removeListener(event, listener)：
移除指定事件的某個監聽器，監聽器必須是該事件已經註冊過的監聽器。 - removeAllListeners([event])：
移除所有事件的所有監聽器。如果指定事件，則移除指定事件的所有監聽器。 - setMaxListeners(n)：
預設情況下，如果你新增的監聽器超過10個就會輸出警告資訊。setMaxListeners 函式用於提高監聽器的預設限制的數量。 - listeners(event)：返回指定事件的監聽器陣列。
- emit(event, [arg1], [arg2], [...])：
按引數的順序執行每個監聽器，如果事件有註冊監聽器返回true，否則返回false。
nodeJS設計之美
上一段其實簡要介紹了nodeJS中eventEmitter的使用方法。下面，我們要做的就是深入nodeJS events模組原始碼，瞭解並學習他的設計之美。
如何建立空物件？
我們已經瞭解到，_events是要來儲存監聽事件(key)、監聽器陣列(value)的map。那麼，他的初始值一定是一個空物件。直觀上，我們可以這樣建立一個空物件：
this._events = {};複製程式碼但是nodeJS原始碼中的實現方式卻是這樣：
function EventHandlers() {};
EventHandlers.prototype = Object.create(null);
this._events = new EventHandlers();複製程式碼官方稱，這麼做的原因是出於效能上的考慮，經過jsperf比較，在v8 v4.9版本中，後者效能有超出2倍的表現。
對此，作為一個“吹毛求疵”有態度的程式設計師，我寫了一個benchmark，對一個物件進行一千次取值操作，求平均時間進行驗證：
_events = {};
_events.test='test'
for (let i = 0; i < 1000; i++) {
window.performance.mark('test empty object start');
console.log(_events.test);
window.performance.mark('test empty object end');
window.performance.measure('test empty object','test empty object start','test empty object end');
}
let sum1 = 0
for (let k = 0; k < 1000; k++) {
sum1 +=window.performance.getEntriesByName('test empty object')[k].duration
}
let averge1 = sum1/1000;
console.log(averge1*1000);
function EventHandlers() {};
EventHandlers.prototype = Object.create(null);
_events = new EventHandlers();_events.test='test';
for (let i = 0; i < 1000; i++) {
window.performance.mark('test empty object start');
console.log(_events.test);
window.performance.mark('test empty object end');
window.performance.measure('test empty object','test empty object start','test empty object end');
}
let sum1 = 0
for (let k = 0; k < 1000; k++) {
sum1 +=window.performance.getEntriesByName('test empty object')[k].duration
}
let averge1 = sum1/1000;
console.log(averge1*1000);複製程式碼- 第一段執行時間：111.86000000001695；
- 第二段執行時間：108.37000000001353;
多執行幾次會發現，第一段也存在時間上短於第二段執行時間的情況。總體來看，第二段時間上更短，但兩次時間比較相近。
我自己的想法是，使用nodeJS原始碼中這樣建立空物件的方式，在對物件屬性的讀取上能夠節省原型鏈查詢的時間。但是，如果一個屬性直接在該物件上，即hasOwnProperty()為true，是否還有節省查詢時間，效能優化的空間呢？
另外，不同瀏覽器引擎的處理可能也存在差別，即使是流行的V8引擎，處理機制也“深不可測”。同時，benchmark中都是對同一屬性的讀取，一般來講瀏覽器引擎對同樣的操作行為應該會有一個“cache”機制：據我瞭解JIT(just-in-time)實時彙編，會將重複執行的"hot code"編譯為本地機器碼，極大增加效率。所以benchmark實現的purity也有被一定程度的干擾。不過好在測試例項都是在相同環境下執行。
所以原始碼中，此處效能優化上的2倍數值，我持一定的保留態度。
addListener實現
經過整理，適當刪減後的原始碼點選這裡檢視，保留了我的註釋。我們來一步一步解讀下原始碼。
判斷新增的監聽器是否為函式型別，使用了typeof進行驗證：
if (typeof listener !== 'function') {
throw new TypeError('"listener" argument must be a function');
}複製程式碼接下來，要分為幾種情況。
case1:
判斷_events表是否已經存在，如果不存在，則說明是第一次為eventEmitter例項新增事件和監聽器，需要新建立_events：
if (!events) {
events = target._events = new EventHandlers();
target._eventsCount = 0;
} 複製程式碼還記得EventHandlers是什麼嗎？忘記了把螢幕往上滾動再看一下吧。
同時，新增指定的事件和此事件對應的監聽器：
existing = events[type] = listener;
++target._eventsCount;複製程式碼注意第一次建立時，為了節省記憶體，提高效能，events[type]值是一個監聽器函式。如果再次為相同的events[type]新增監聽器時（下面case2），events[type]對應的值需要變成一個陣列來儲存。
case2:
又囉嗦一遍：如果_events已存在，在為相關事件新增監聽器時，需要判斷events[type]是函式型別（只存在一個監聽函式）還是已經成為了一個陣列型別（已經存在一個以上監聽函式）。
並且根據相關引數prepend，分為監聽器陣列頭部插入和尾部插入兩種情況，以保證監聽器的順序執行：
if (typeof existing === 'function') {
existing = events[type] = prepend ? [listener, existing] :
[existing, listener];
}
else {
if (prepend) {
existing.unshift(listener);
}
else {
existing.push(listener);
}
}複製程式碼case3:
在閱讀原始碼時，我還發現了一個很“詭異”的邏輯：
if (events.newListener) {
target.emit('newListener', type,
listener.listener ? listener.listener : listener);
events = target._events;
}
existing = events[type];複製程式碼仔細分析，他的目的是因為nodeJS預設：當所有的eventEmitter物件在新增新的監聽函式時，都會發出newListener事件。這其實也並不奇怪，我個人認為這麼設計還是非常合理的。
cae4:
之前介紹了我們可以設定一個事件對應的最大監聽器個數，nodeJS原始碼中通過這樣的程式碼來實現：
EventEmitter.prototype.setMaxListeners = function setMaxListeners(n) {
if (typeof n !== 'number' || n < 0 || isNaN(n)) {
throw new TypeError('"n" argument must be a positive number');
}
this._maxListeners = n;
return this;
};複製程式碼當對這個值進行了設定之後，如果超過此閾值，將會進行報警：
if (!existing.warned) {
m = $getMaxListeners(target);
if (m && m > 0 && existing.length > m) {
existing.warned = true;
const w = new Error('Possible EventEmitter memory leak detected. ' +
`${existing.length} ${String(type)} listeners ` +
'added. Use emitter.setMaxListeners() to ' +
'increase limit');
w.name = 'MaxListenersExceededWarning';
w.emitter = target;
w.type = type;
w.count = existing.length;
process.emitWarning(w);
}
}複製程式碼emit發射器實現
有了之前的註冊監聽器過程，那麼我們再來看看監聽器是如何被觸發的。其實觸發過程直觀上並不難理解，核心思想就是將監聽器陣列中的每一項，即監聽函式逐個執行就好了。
經過整理，適當刪減後的原始碼同樣可以這裡找到。原始碼中，包含了較多的錯誤資訊處理內容，忽略不表。下面我挑出一些“出神入化”的細節來分析。
首先，有了上面的分析，我們現在可以清晰的意識到某個事件的監聽處理可能是一個函式型別，表示該事件只有一個事件處理程式；也可能是個陣列，表示該事件有多個事件處理程式，儲存在監聽器陣列中。（我又囉嗦了一遍，因為理解這個太重要了，不然你會看暈的）
同時，emit方法可以接受多個引數。第一個引數為事件型別：type，下面兩行程式碼用於獲取某個事件的監聽處理型別。用isFn布林值來表示。
handler = events[type];
var isFn = typeof handler === 'function';複製程式碼isFn為true，表示該事件只有一個監聽函式。否則，存在多個，儲存在陣列中。
原始碼中對於emit引數個數有判斷，並進行了switch分支處理：
switch (len) {
case 1:
emitNone(handler, isFn, this);
break;
case 2:
emitOne(handler, isFn, this, arguments[1]);
break;
case 3:
emitTwo(handler, isFn, this, arguments[1], arguments[2]);
break;
case 4:
emitThree(handler, isFn, this, arguments[1], arguments[2], arguments[3]);
break;
// slower
default:
args = new Array(len - 1);
for (i = 1; i < len; i++) {
args[i - 1] = arguments[i];
}
emitMany(handler, isFn, this, args);
}複製程式碼我們挑一個相對最複雜的看一下——預設模式呼叫的emitMany：
function emitMany(handler, isFn, self, args) {
if (isFn) {
handler.apply(self, args);
}
else {
var len = handler.length;
var listeners = arrayClone(handler, len);
for (var i = 0; i < len; ++i) {
listeners[i].apply(self, args);
}
}
}複製程式碼對於只有一個事件處理程式的情況（isFn為true），直接執行：
handler.apply(self, args);複製程式碼否則，便使用for迴圈，逐個呼叫：
listeners[i].apply(self, args);複製程式碼非常有意思的一個細節在於：
var listeners = arrayClone(handler, len);複製程式碼這裡需要讀者細心體會。
原始碼讀到這裡，我不禁要感嘆設計的嚴謹精妙之處。上面程式碼處理的意義在於：防止在一個事件監聽器中監聽同一個事件，從而導致死迴圈的出現。
如果您不理解，且看我這個例子：
let emitter = new eventEmitter;
emitter.on('message1', function test () {
// some codes here
// ...
emitter.on('message1', test}
});
emit('message1');複製程式碼講道理，正常來講，不經過任何處理，上述程式碼在事件處理程式內部又新增了對於同一個事件的監聽，這必然會帶來死迴圈問題。
因為在emit執行處理程式的時候，我們又向監聽器佇列新增了一項。這一項執行時，又會“子子孫孫無窮匱也”的向監聽器陣列尾部新增。
原始碼中對於這個問題的解決方案是：在執行emit方法時，使用arrayClone方法拷貝出另一個一模一樣的陣列，進而執行它。這樣一來，當我們在監聽器內監聽同一個事件時，的確給原監聽器陣列新增了新的監聽函式，但並沒有影響到當前這個被拷貝出來的副本陣列。在迴圈中，我們執行的也是這個副本函式。
單次監聽器once實現
once(event, listener)是為指定事件註冊一個單次事件處理程式，即監聽器最多隻會觸發一次，觸發後立刻解除該監聽器。
實現方式主要是在進行監聽器繫結時，對於監聽函式進行一層包裝。該包裝方式在原有函式上新增一個flag標識位，並在觸發監聽函式前就呼叫removeListener()方法，除掉此監聽函式。我理解，這是一種“雙保險”的體現。
程式碼裡，我們可以抽絲剝繭（已進行刪減）學習一下：
EventEmitter.prototype.once = function once(type, listener) {
this.on(type, _onceWrap(this, type, listener));
return this;
};複製程式碼once方法呼叫on方法（即addListener方法，on為別名），第二個引數即監聽程式進行_onceWrap化包裝，包裝過程為：
this.target.removeListener(this.type, this.wrapFn);
if (!this.fired) {
this.fired = true;
this.listener.apply(this.target, arguments);
}複製程式碼_onceWrap化的主要思想是將once第二個引數listener的執行，包上了一次判斷，並在執行前進行removeListener刪除該監聽程式。：
this.listener.apply(this.target, arguments);複製程式碼removeListener的驚鴻一瞥
removeListener(type, listener)移除指定事件的某個監聽器。其實這個實現思路也比較容易理解，我們已經知道events[type]可能是函式型別，也可能是陣列型別。如果是陣列型別，只需要進行遍歷，找到相關的監聽器進行刪除就可以了。
不過關鍵問題就在於對陣列項的刪除。
平時開發，我們常用splice進行陣列中某一項的刪除，99％的case都會想到這個方法。可是nodeJS相關原始碼中，對於刪除進行了優化。自己封裝了一個spliceOne方法，用於刪除陣列中指定角標。並且號稱這個方法比使用splice要快1.5倍。我們就來看一下他是如何實現的：
function spliceOne(list, index) {
for (var i = index, k = i + 1, n = list.length; k < n; i += 1, k += 1) {
list[i] = list[k];
}
list.pop();
}複製程式碼傳統刪除方法：
list.splice(index, 1);複製程式碼究竟是否計算更快，我也實現了一個benchmark，產生長度為1000的陣列，刪除其第52項。反覆執行1000次求平均耗時:
let arr = Array.from(Array(100).keys());
for (let i = 0; i < 1000; i++) {
window.performance.mark('test splice start');
arr.splice(52, 1);
window.performance.mark('test splice end');
window.performance.measure('test splice','test splice start','test splice end');
}
let sum1 = 0
for (let k = 0; k < 1000; k++) {
sum1 +=window.performance.getEntriesByName('test splice')[k].duration
}
let averge1 = sum1/1000;
console.log(averge1*1000); // 1.7749999999869034
let arr = Array.from(Array(100).keys());
for (let i = 0; i < 1000; i++) {
window.performance.mark('test splice start');
spliceOne(arr, 52);
window.performance.mark('test splice end');
window.performance.measure('test splice','test splice start','test splice end');
}
let sum1 = 0
for (let k = 0; k < 1000; k++) {
sum1 +=window.performance.getEntriesByName('test splice')[k].duration
}
let averge1 = sum1/1000;
console.log(averge1*1000); // 1.5350000000089494複製程式碼- 第一段執行時間：1.7749999999869034；
- 第二段執行時間：1.5350000000089494;
明顯使用spliceOne方法更快，時間上縮短了13.5%，不過依然沒有達到官方的1.5，需要說明的是我採用最新版本的Chrome進行測試。
自己造輪子
前文我們感受了nodeJS中的eventEmitter實現方式。我也對於其中的核心方法，在原始碼層面進行了剖析。學習到了“精華”之後，更重要的要學以致用，自己實現一個基於ES6的事件釋出訂閱系統。
我的實現版本中充分利用了ES6語法特性，並且相對於nodeJS實現減少了一些“不必要的”優化和判斷。
因為nodeJS的實現中，很多api在前端瀏覽器環境開發中並用不到。所以我對對外暴露的方法進行了精簡。最終實現上，除去註釋部分，只用了不到40行程式碼。如果您有興趣，可以去程式碼倉庫訪問，整個邏輯還是很簡單的。
裡面同時附贈了我同事@顏海鏡大神基於zepto實現版本，以及nodeJS events模組原始碼，方便讀者進行對比。
整個過程編寫時間倉促，其中必然不乏疏漏之處，還請您斧正並與我討論。
總結
對於nodeJS原始碼events模組的閱讀，令我受益匪淺。設計層面上，優秀的包裝和抽象思路對我一定的啟發；實現層面上，很多“意想不到”的case處理，讓我“歎為觀止”。
雖然業務上暫時使用不到nodeJS，但是對於每一個前端開發人員來說，這樣的學習我認為是有必要的。今後，我會整理出文章，總結對nodeJS原始碼更多模組的分析，希望同讀者能夠保持交流和探討。
整篇文章裡面列出的benchmark，我認為並不完美。同時，對於瀏覽器引擎處理上，我存在知識盲點和漏洞，希望有大神給與斧正。
PS：百度知識搜尋部大前端繼續招兵買馬，有意向者火速聯絡。。。