AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

从Chrome源码看浏览器的事件机制

2017-08-16 1476
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：

在上一篇《从Chrome源码看浏览器如何构建DOM树》介绍了blink如何创建一棵DOM树，在这一篇将介绍事件机制。

上一篇还有一个地方未提及，那就是在构建完DOM之后，浏览器将会触发DOMContentLoaded事件，这个事件是在处理tokens的时候遇到EndOfFile标志符时触发的：


  
  
    

   
   
  1. if (it->type() == HTMLToken::EndOfFile) {  
    2. 

   
   
  2. // The EOF is assumed to be the last token of this bunch.  
    3. 

   
   
  3. ASSERT(it + 1 == tokens->end());  
    4. 

   
   
  4. // There should never be any chunks after the EOF.  
    5. 

   
   
  5. ASSERT(m_speculations.isEmpty());  
    6. 

   
   
  6. prepareToStopParsing();  
    7. 

   
   
  7. break;  
    8. 

   
   
  8. } 
    9.

上面代码第1行，遇到结尾的token时，将会在第6行停止解析。这是最后一个待处理的token，一般是跟在后面的一个\EOF标志符来的。

第6行的prepareToStopParsing，会在Document的finishedParseing里面生成一个事件，再调用dispatchEvent，进一步调用监听函数：


  
  
    

   
   
  1. void Document::finishedParsing() {  
    2. 

   
   
  2. dispatchEvent(Event::createBubble(EventTypeNames::DOMContentLoaded));  
    3. 

   
   
  3. } 
    4.

这个dispatchEvent是EventTarget这个类的成员函数。在上一篇描述DOM的结点数据结构时将Node作为根结点，其实Node上面还有一个类，就是EventTarget。我们先来看一下事件的数据结构是怎么样的：

1. 事件的数据结构

画出事件相关的类图：

从Chrome源码看浏览器的事件机制

在最顶层的EventTarget提供了三个函数，分别是添加监听add、删除监听remove、触发监听fire。一个典型的访问者模式我在《Effective前端5：减少前端代码耦合》提到了，这里重点看一下blink实际上是怎么实现的。

在Node类组合了一个EventTargetDataMap，这是一个哈希map，并且它是静态成员变量。它的key值是当前结点Node实例的指针，value值是事件名称和对应的listeners。如果画一个示例图，它的存储是这样的：

从Chrome源码看浏览器的事件机制

如上，按照正常的思维，存放事件名称和对应的访问者应该是用一个哈希map，但是blink却是用的向量vector + pair，这就导致在查找某个事件的访问者的时候，需要循环所有已添加的事件名称依次比较字符串值是否相等。为什么要用循环来做而不是map，这在它的源码注释做了说明：


  
  
    

   
   
  1. // We use HeapVector instead of HeapHashMap because  
    2. 

   
   
  2. // - HeapVector is much more space efficient than HeapHashMap.  
    3. 

   
   
  3. // - An EventTarget rarely has event listeners for many event types, and  
    4. 

   
   
  4. // HeapVector is faster in such cases.  
    5. 

   
   
  5. HeapVector>, 2> m_entries; 
    6.

意思是说使用vector比使用map更加节省空间，并且一个dom节点往往不太可能绑了太多的事件类型。这就启示我们写代码要根据实际情况灵活处理。

同时还有一个比较有趣的事情，就是webkit用了一个EventTargetDataMap存放所有节点绑定的事件，它是一个static静态成员变量，被所有Node的实例所共享，由于不同的实例的内存地址不一样，所以它的key不一样，就可以通过内存地址找到它绑的所有事件，即上面说的vector结构。为什么它要用一个类似于全局的变量?按照正常思维，每个Node结点绑的事件是独立的，那应该把绑的事件作为每个Node实例独立的数据，搞一个全局的还得用一个map作一个哈希映射。

一个可能的原因是EventTarget是作为所有DOM结点的事件目标的类，除了Node之外，还有FileReader、AudioNode等也会继承于EventTarget，它们有另外一个EventTargetData。把所有的事件都放一起了，应该会方便统一处理。

这个时候你可能会冒出另外一个问题，这个EventTargetDataMap是什么释放绑定的事件的，我把一个DOM结点删了，它会自动去释放绑定的的事件吗?换句话说，删除掉一个结点前需不需要先off掉它的事件?

2. DOM结点删除与事件解绑

从源码可以看到，Node的析构函数并没有去释放当前Node绑定的事件，所以它是不是不会自动释放事件?为验证，我们在添加绑定一个事件后、删掉结点后分别打印这个map里面的数据，为此给Node添加一个打印的函数：


  
  
    

   
   
  1. void Node::printEventMap(){  
    2. 

   
   
  2. EventTargetDataMap::iterator it = eventTargetDataMap().begin();  
    3. 

   
   
  3. LOG (INFO) << "print event map: ";  
    4. 

   
   
  4. while(it != eventTargetDataMap().end()){  
    5. 

   
   
  5. LOG(INFO) << ((Element*)it->key.get())->tagName();  
    6. 

   
   
  6. ++it;  
    7. 

   
   
  7. }  
    8. 

   
   
  8. } 
    9.

在上面的第5行，循环打印出所有Node结点的标签名。

同时试验的html如下：


  
  
    

   
   
  1. <p id="text">hello, world</p> 
    2. 

   
   
  2. <script> 
    3. 

   
   
  3.     function clickHandle(){ 
    4. 

   
   
  4.         console.log("click"); 
    5. 

   
   
  5.     } 
    6. 

   
   
  6.     document.getElementById("text").addEventListener("click", clickHandle); 
    7. 

   
   
  7.     document.getElementById("text").remove(); 
    8. 

   
   
  8.     document.addEventListener("DOMContentLoaded", function(){ 
    9. 

   
   
  9.         console.log("loaded"); 
    10. 

   
   
  10.     });  
    11. 

   
   
  11. </script> 
    12.

打印的结果如下：


  
  
    

   
   
  1. [21755:775:0204/181452.402843:INFO:Node.cpp(1910)] print event map:  
    2. 

   
   
  2. [21755:775:0204/181452.403048:INFO:Node.cpp(1912)] “P”  
    3. 

   
   
  3. [21755:775:0204/181452.404114:INFO:Node.cpp(1910)] print event map:  
    4. 

   
   
  4. [21755:775:0204/181452.404287:INFO:Node.cpp(1912)] “P”  
    5. 

   
   
  5. [21755:775:0204/181452.404466:INFO:Node.cpp(1912)] “#document” 
    6.

可以看到remove了p结点之后，它的事件依然存在。

我们看一下blink在remove里面做了什么：


  
  
    

   
   
  1. void Node::remove(ExceptionState& exceptionState) {  
    2. 

   
   
  2. if (ContainerNode* parent = parentNode())  
    3. 

   
   
  3. parent->removeChild(this, exceptionState);  
    4. 

   
   
  4. } 
    5.

remove是后来W3C新加的api，所以在remove里面调的是老的removeChild，removeChild的关键代码如下：


  
  
    

   
   
  1. Node* previousChild = child->previousSibling();  
    2. 

   
   
  2. Node* nextChild = child->nextSibling();  
    3. 

   
   
  3. if (nextChild)  
    4. 

   
   
  4. nextChild->setPreviousSibling(previousChild);  
    5. 

   
   
  5. if (previousChild)  
    6. 

   
   
  6. previousChild->setNextSibling(nextChild);  
    7. 

   
   
  7. if (m_firstChild == &oldChild)  
    8. 

   
   
  8. setFirstChild(nextChild);  
    9. 

   
   
  9. if (m_lastChild == &oldChild)  
    10. 

   
   
  10. setLastChild(previousChild);  
    11. 

   
   
  11. oldChild.setPreviousSibling(nullptr); 
    12. 

   
   
  12. oldChild.setNextSibling(nullptr);  
    13. 

   
   
  13. oldChild.setParentOrShadowHostNode(nullptr); 
    14.

前面几行是重新设置DOM树的结点关系，比较好理解。最后面三行，把删除掉的结点的兄弟指针和父指针置为null，注意这里并没有把它delete掉，只是把它隔离开来。所以把它remove掉之后， 这个结点在内存里面依旧存在，你依然可以获取它的innerText，把它重新append到body里面(但是不推荐这么做)。同时事件依然存在那个map里面。

什么时候这个节点会被真正的析构呢?发生在GC回收的时候，GC回收的时候会把DOM结点的内存释放，并且会删掉map里面的数据。为验证，在启动Chrome的时候加上参数：


  
  
    

   
   
  1. chromium test.html --js-flags='--expose_gc' 
    2.

这样可以调用window.gc触发gc回收，然后在上面的js demo代码后面加上：


  
  
    

   
   
  1. setTimeout(function(){  
    2. 

   
   
  2. //添加这个事件是为了触发Chrome源码里面添加的打印log  
    3. 

   
   
  3. document.addEventListener("DOMContentLoaded", function(){});  
    4. 

   
   
  4. setTimeout(function(){  
    5. 

   
   
  5. window.gc();  
    6. 

   
   
  6. document.addEventListener("DOMContentLoaded", function(){});  
    7. 

   
   
  7. }, 3000);  
    8. 

   
   
  8. }, 3000); 
    9.

打印的结果：


  
  
    

   
   
  1. [Node.cpp(1912)] print event map:  
    2. 

   
   
  2. [Node.cpp(1914)] “P”  
    3. 

   
   
  3. [Node.cpp(1914)] “#document”  
    4. 

   
   
  4. [Element.cpp(186)] destroy element “p”  
    5. 

   
   
  5. [Node.cpp(1912)] print event map:  
    6. 

   
   
  6. [Node.cpp(1914)] “#document” 
    7.

后面三行是执行了GC回收后的结果——析构p标签并更新存放事件的数据结构。

所以说删掉一个DOM结点，并不需要手动去释放它的事件。

需要注意的是DOM结点一旦存在一个引用，即使你把它remove掉了，GC也不会去回收，如下：


  
  
    

   
   
  1. <script> 
    2. 

   
   
  2.     var p = document.getElementById("text"); 
    3. 

   
   
  3.     p.remove(); 
    4. 

   
   
  4.     window.gc(); 
    5. 

   
   
  5. </script> 
    6.

执行了window.gc之后并不会去回收p的内存空间以及它的事件。因为还存在一个p的变量指向它，而如果将p置为null，如下：


  
  
    

   
   
  1. <script> 
    2. 

   
   
  2.     var p = document.getElementById("text"); 
    3. 

   
   
  3.     p.remove(); 
    4. 

   
   
  4.     p = null; 
    5. 

   
   
  5.     window.gc(); 
    6. 

   
   
  6. </script> 
    7.

最后的GC就管用了，或者p离开了作用域：


  
  
    

   
   
  1. <script> 
    2. 

   
   
  2. !function(){ 
    3. 

   
   
  3.     var p = document.getElementById("text"); 
    4. 

   
   
  4.     p.remove(); 
    5. 

   
   
  5. }() 
    6. 

   
   
  6. window.gc(); 
    7. 

   
   
  7. </script> 
    8.

自动销毁，p结点没有人引用了，能够自动GC回收。

还有一个问题一直困扰着我，那就是监听X按钮的click，然后把它的父容器如弹框给删了，这样它自已本身也删了，但是监听函数还可以继续执行，实体都没有了，为什么绑在它身上的函数还可以继续执行呢?通过上面的分析，应该可以找到答案：删掉之后GC并不会立刻回收和释放事件，因为在执行监听函数的时候，里面有个this指针指向了该节点，并且this是只读的，你不能把它置成null。所以只有执行完了回调函数，离开了作用域，this才会销毁，才有可能被GC回收。

还有一种绑事件的方式，没有讨论：

3. DOM Level 0事件

就是使用dom结点的onclick、onfocus等属性，添加事件，由于这个提得比较早，所以它的兼容性最好。如下：


  
  
    

   
   
  1. function clickHandle(){  
    2. 

   
   
  2. console.log("addEventListener click");  
    3. 

   
   
  3. }  
    4. 

   
   
  4. var p = document.getElementById("text");  
    5. 

   
   
  5. p.addEventListener("click", clickHandle);  
    6. 

   
   
  6. p.onclick = function(){  
    7. 

   
   
  7. console.log("onclick trigger");  
    8. 

   
   
  8. }; 
    9.

如果点击p标签，将会触发两次，一次是addEventListener绑定的，另一次是onclick绑定的。onclick是如何绑定的呢：


  
  
    

   
   
  1. bool EventTarget::setAttributeEventListener(const AtomicString& eventType,  
    2. 

   
   
  2. EventListener* listener) {  
    3. 

   
   
  3. clearAttributeEventListener(eventType);  
    4. 

   
   
  4. if (!listener)  
    5. 

   
   
  5. return false;  
    6. 

   
   
  6. return addEventListener(eventType, listener, false);  
    7. 

   
   
  7. } 
    8.

可以看到，最后还是调的上面的addEventListener，只是在此之前要先clear掉上一次绑的属性事件：


  
  
    

   
   
  1. bool EventTarget::clearAttributeEventListener(const AtomicString& eventType) {  
    2. 

   
   
  2. EventListener* listener = getAttributeEventListener(eventType);  
    3. 

   
   
  3. if (!listener)  
    4. 

   
   
  4. return false;  
    5. 

   
   
  5. return removeEventListener(eventType, listener, false);  
    6. 

   
   
  6. } 
    7.

在clear函数里面会去获取上一次的listener，然后调removeEventListener，关键在于它怎么根据事件名称eventType获取上次listener呢：


  
  
    

   
   
  1. EventListener* EventTarget::getAttributeEventListener(  
    2. 

   
   
  2. const AtomicString& eventType) {  
    3. 

   
   
  3. EventListenerVector* listenerVector = getEventListeners(eventType);  
    4. 

   
   
  4. if (!listenerVector)  
    5. 

   
   
  5. return nullptr;  
    6. 

   
   
  6. for (auto& eventListener : *listenerVector) {  
    7. 

   
   
  7. EventListener* listener = eventListener.listener();  
    8. 

   
   
  8. if (listener->isAttribute() /* && ... */)  
    9. 

   
   
  9. return listener;  
    10. 

   
   
  10. }  
    11. 

   
   
  11. return nullptr;  
    12. 

   
   
  12. } 
    13.

在代码上看很容易理解，首先获取该DOM结点该事件名称的所有listener做个循环，然后判断这个listener是否为属性事件。判断成立，则返回。怎么判断是否为属性事件?那个是实例化事件的时候封装好的了。

从上面的源代码可以很清楚地看到onclick等属性事件只能绑一次，并且和addEventListener的事件不冲突。

关于事件，还有一个很重要的概念，那就是事件的捕获和冒泡。

4. 事件的捕获和冒泡

用以下html做试验：


  
  
    

   
   
  1. <div id="div-1"> 
    2. 

   
   
  2.     <div id="div-2"> 
    3. 

   
   
  3.         <div id="div-3">hello, world</div> 
    4. 

   
   
  4.     </div> 
    5. 

   
   
  5. </div> 
    6.
js绑事件如下： 

  
  
    

   
   
  1. var div1 = document.getElementById("div-1"),  
    2. 

   
   
  2. div2 = document.getElementById("div-2"),  
    3. 

   
   
  3. div3 = document.getElementById("div-3");  
    4. 

   
   
  4. function printInfo(event){  
    5. 

   
   
  5. console.log(“eventPhase=“ + ””event.eventPhase + " " + this.id);  
    6. 

   
   
  6. }  
    7. 

   
   
  7. div1.addEventListener("click", printInfo, true);  
    8. 

   
   
  8. div2.addEventListener("click", printInfo, true);  
    9. 

   
   
  9. div3.addEventListener("click", printInfo, true); 
    10. 

   
   
  10. div1.addEventListener("click", printInfo);  
    11. 

   
   
  11. div2.addEventListener("click", printInfo);  
    12. 

   
   
  12. div3.addEventListener("click", printInfo); 
    13.

第三个参数为true，表示监听在捕获阶段，点击p标签之后控制台打印出：


  
  
    

   
   
  1. [CONSOLE] “eventPhase=1 div-1”  
    2. 

   
   
  2. [CONSOLE] “eventPhase=1 div-2”  
    3. 

   
   
  3. [CONSOLE] “eventPhase=2 div-3”  
    4. 

   
   
  4. [CONSOLE] “eventPhase=2 div-3”  
    5. 

   
   
  5. [CONSOLE] “eventPhase=3 div-2”  
    6. 

   
   
  6. [CONSOLE] “eventPhase=3 div-1” 
    7.

在Event类定义里面可以找到关到eventPhase的定义：


  
  
    

   
   
  1. enum PhaseType {  
    2. 

   
   
  2. kNone = 0,  
    3. 

   
   
  3. kCapturingPhase = 1,  
    4. 

   
   
  4. kAtTarget = 2,  
    5. 

   
   
  5. kBubblingPhase = 3  
    6. 

   
   
  6. }; 
    7.

1表示捕获取阶段，2表示在当前目标，3表示冒泡阶段。把上面的phase转化成文字，并把html/body/document也绑上事件，同时at-target只绑一次，那么整一个过程将是这样的：


  
  
    

   
   
  1. “capture document”  
    2. 

   
   
  2. “capture HTML”  
    3. 

   
   
  3. “capture BODY”  
    4. 

   
   
  4. “capture DIV#div-1”,  
    5. 

   
   
  5. “capture DIV#div-2”,  
    6. 

   
   
  6. “at-target DIV#div-3”,  
    7. 

   
   
  7. “bubbling DIV#div-2”,  
    8. 

   
   
  8. “bubbling DIV#div-1”,  
    9. 

   
   
  9. “bubbling BODY”  
    10. 

   
   
  10. “bubbling HTML”  
    11. 

   
   
  11. “bubbling document” 
    12.

从document一直捕获到目标div3，然后再一直冒泡到document，如果在某个阶段执行了：


  
  
    

   
   
  1. event.stopPropagation() 
    2.

那么后续的过程将不会继续，例如在document的capture阶段的click事件里面执行了上面的阻止传播函数，那么控制台只会打印出上面输出的第一行。

在研究blink是如何实现之前，我们先来看一下事件是怎么触发和封装的

5. 事件的触发和封装

以click事件为例，Blink在RenderViewImpl里面收到了外面的进程的消息：


  
  
    

   
   
  1. // IPC::Listener implementation ----------------------------------------------  
    2. 

   
   
  2. bool RenderViewImpl::OnMessageReceived(const IPC::Message& message) {  
    3. 

   
   
  3. // Have the super handle all other messages.  
    4. 

   
   
  4. IPC_MESSAGE_UNHANDLED(handled = RenderWidget::OnMessageReceived(message))  
    5. 

   
   
  5. } 
    6.

上文已提到，RenderViewImpl是页面最基础的一个类，当它收到IPC发来的消息时，根据消息的类型，调用相应的处理函数，由于这是一个input消息，所以它会调：


  
  
    

   
   
  1. IPC_MESSAGE_HANDLER(InputMsg_HandleInputEvent, OnHandleInputEvent) 
    2.

上面的IPC_MESSAGE_HANDLER其实是Blink定义的一个宏，这个宏其实就是一个switch-case里面的case。

这个处理函数又会调：


  
  
    

   
   
  1. WebInputEventResult WebViewImpl::handleInputEvent(  
    2. 

   
   
  2. const WebInputEvent& inputEvent) {  
    3. 

   
   
  3. switch (inputEvent.type) {  
    4. 

   
   
  4. case WebInputEvent::MouseUp:  
    5. 

   
   
  5. eventType = EventTypeNames::mouseup;  
    6. 

   
   
  6. gestureIndicator = WTF::wrapUnique(  
    7. 

   
   
  7. new UserGestureIndicator(m_mouseCaptureGestureToken.release()));  
    8. 

   
   
  8. break;  
    9. 

   
   
  9. }  
    10. 

   
   
  10. } 
    11.

它里面会根据输入事件的类型如mouseup、touchstart、keybord事件等类型去调不同的函数。click是在mouseup里面处理的，接着在MouseEventManager里面创建一个MouseEvent，并调度事件，即捕获和冒泡：


  
  
    

   
   
  1. WebInputEventResult MouseEventManager::dispatchMouseEvent(EventTarget* target, const AtomicString& mouseEventType, const PlatformMouseEvent& mouseEvent, EventTarget* relatedTarget, bool checkForListener) { 
    2. 

   
   
  2. MouseEvent* event = MouseEvent::create( mouseEventType, targetNode->document().domWindow(), mouseEvent/*...*/);  
    3. 

   
   
  3. DispatchEventResult dispatchResult = target->dispatchEvent(event);  
    4. 

   
   
  4. return EventHandlingUtil::toWebInputEventResult(dispatchResult);  
    5. 

   
   
  5. } 
    6.

上面代码第2行创建MouseEvent，第3行dispatch。我们来看一下这个事件是如何层层封装成一个MouseEvent的：

从Chrome源码看浏览器的事件机制

上图展示了从原始的msg转化成了W3C标准的MouseEvent的过程。Blink的消息处理引擎把msg转化成了WebInputEvent，这个event能够直接静态转化成可读的WebMouseEvent，也就是事件在底层的时候已经被封装成带有相关数据且可读的事件了，上层再把它这些数据转化成W3C规定格式的MouseEvent。

我们重点看下MouseEvent的create函数：


  
  
    

   
   
  1. MouseEvent* MouseEvent::create(const AtomicString& eventType, AbstractView* view, const PlatformMouseEvent& event, Node* relatedTarget) {  
    2. 

   
   
  2. bool isMouseEnterOrLeave = eventType == EventTypeNames::mouseenter ||  
    3. 

   
   
  3. eventType == EventTypeNames::mouseleave;  
    4. 

   
   
  4. bool isCancelable = !isMouseEnterOrLeave;  
    5. 

   
   
  5. bool isBubbling = !isMouseEnterOrLeave;  
    6. 

   
   
  6. return MouseEvent::create(  
    7. 

   
   
  7. eventType, isBubbling, isCancelable, view, event.position().x()  
    8. 

   
   
  8. /*.../*, &event);  
    9. 

   
   
  9. } 
    10.

从代码第五行可以看到鼠标事件的mouseenter和mouseleave是不会冒泡的。

另外，每个Event都有一个EventPath，记录它冒泡的路径：

从Chrome源码看浏览器的事件机制

在dispatchEvent的时候，会初始化EventPath：


  
  
    

   
   
  1. void EventPath::initialize() {  
    2. 

   
   
  2. if (eventPathShouldBeEmptyFor(*m_node, m_event))  
    3. 

   
   
  3. return;  
    4. 

   
   
  4. calculatePath();  
    5. 

   
   
  5. calculateAdjustedTargets();  
    6. 

   
   
  6. calculateTreeOrderAndSetNearestAncestorClosedTree();  
    7. 

   
   
  7. } 
    8.

第五行会去计算Path，而这个计算Path的核心逻辑非常简单：


  
  
    

   
   
  1. void EventPath::calculatePath() {  
    2. 

   
   
  2. // For performance and memory usage reasons we want to store the  
    3. 

   
   
  3. // path using as few bytes as possible and with as few allocations  
    4. 

   
   
  4. // as possible which is why we gather the data on the stack before  
    5. 

   
   
  5. // storing it in a perfectly sized m_nodeEventContexts Vector.  
    6. 

   
   
  6. HeapVector, 64> nodesInPath;  
    7. 

   
   
  7. Node* current = m_node;  
    8. 

   
   
  8. nodesInPath.push_back(current);  
    9. 

   
   
  9. while (current) {  
    10. 

   
   
  10. current = current->parentNode();  
    11. 

   
   
  11. if (current)  
    12. 

   
   
  12. nodesInPath.push_back(current);  
    13. 

   
   
  13. }  
    14. 

   
   
  14. m_nodeEventContexts.reserveCapacity(nodesInPath.size());  
    15. 

   
   
  15. for (Node* nodeInPath : nodesInPath) {  
    16. 

   
   
  16. m_nodeEventContexts.push_back(NodeEventContext(  
    17. 

   
   
  17. nodeInPath, eventTargetRespectingTargetRules(*nodeInPath)));  
    18. 

   
   
  18. }  
    19. 

   
   
  19. } 
    20.

第9行的while循环不断地获取当前node的父节点并把它push到一个vector里面，直到null即没有父节点为止。最后再把这个vector push到真正用来存储成员变量。这段代码我们又发现一个有趣的注释，它说明了为什么不直接push到成员变量里面——因为vector变量会自动扩展本身大小，当push的时候容量不足时，会不断地开辟内存，blink的实现是开辟一个单位元素的空间，刚好存放一个元素：


  
  
    

   
   
  1. ptr = expandCapacity(size() + 1, ptr); 
    2.

所以如果直接push_back到成员变量，会不断地开辟新内存。于是它一开始就初始化了一个size为64的栈变量来存放，减少开辟内存的操作。另外有些vector自动扩充容量的实现，可能是size * 1.5或者size + 10，而不是size + 1，这种情况就会导致有多余的空间没用到。

通过这样的手段，就有了记录事件冒泡路径的EventPath。

6. 事件捕获和冒泡的实现

上面第5点提到的MouseEventManager会调dispatchEvent，这个函数会先创建一个dispatcher，这个dispatcher实例化的时候就会去初始化上面的EventPath，然后再进行dispatch/事件调度：


  
  
    

   
   
  1. EventDispatcher dispatcher(node, &mediator->event());  
    2. 

   
   
  2. DispatchEventResult dispatchResult = dispatcher.dispatch(); 
    3.

所以核心函数就是第2行调的dispatch，而这个函数最核心的3行代码为：


  
  
    

   
   
  1. if (dispatchEventAtCapturing() == ContinueDispatching) {  
    2. 

   
   
  2. if (dispatchEventAtTarget() == ContinueDispatching)  
    3. 

   
   
  3. dispatchEventAtBubbling();  
    4. 

   
   
  4. } 
    5.

(1)先执行Capturing，然后再执行AtTarget，最后再Bubbling，我们来看一下Capturing函数：


  
  
    

   
   
  1. inline EventDispatchContinuation EventDispatcher::dispatchEventAtCapturing() { 
    2. 

   
   
  2.  // Trigger capturing event handlers, starting at the top and working our way  
    3. 

   
   
  3. // down.  
    4. 

   
   
  4. //改变event的阶段为冒泡  
    5. 

   
   
  5. m_event->setEventPhase(Event::kCapturingPhase);  
    6. 

   
   
  6. //先处理绑在window上的事件，并且如果event的m_propagationStopped被设置为true  
    7. 

   
   
  7. //则返回done状态，不再继续传播  
    8. 

   
   
  8. if (m_event->eventPath().windowEventContext().handleLocalEvents(*m_event) &&  
    9. 

   
   
  9. m_event->propagationStopped())  
    10. 

   
   
  10. return DoneDispatching; 
    11.

上面做了一些初始化的工作后，循环EventPath依次触发响应函数：


  
  
    

   
   
  1. //从EventPath最后一个元素，即最顶层的父结点开始下滤  
    2. 

   
   
  2. for (size_t i = m_event->eventPath().size() - 1; i > 0; --i) { 
    3. 

   
   
  3. const NodeEventContext& eventContext = m_event->eventPath()[i];  
    4. 

   
   
  4. //触发事件响应函数  
    5. 

   
   
  5. eventContext.handleLocalEvents(*m_event);  
    6. 

   
   
  6. //如果响应函数设置了stopPropagation，则返回done  
    7. 

   
   
  7. if (m_event->propagationStopped())  
    8. 

   
   
  8. return DoneDispatching;  
    9. 

   
   
  9. }  
    10. 

   
   
  10. return ContinueDispatching;  
    11. 

   
   
  11. } 
    12.

注意上面的for循环终止条件的i是大于0，i为0则为currentTarget。而总的size为6，与我们上面demo控制台打印一致。

(2)at-target的处理就很简单了，取i为0的那个Node并触发它的listeners：


  
  
    

   
   
  1. inline EventDispatchContinuation EventDispatcher::dispatchEventAtTarget() {  
    2. 

   
   
  2. m_event->setEventPhase(Event::kAtTarget);  
    3. 

   
   
  3. m_event->eventPath()[0].handleLocalEvents(*m_event);  
    4. 

   
   
  4. return m_event->propagationStopped() ? DoneDispatching : ContinueDispatching;  
    5. 

   
   
  5. } 
    6.

(3)bubbling的处理稍复杂，因为它还要处理cancleBubble的情况，不过总体的逻辑是类似的，核心代码如下：


  
  
    

   
   
  1. inline void EventDispatcher::dispatchEventAtBubbling() {  
    2. 

   
   
  2. // Trigger bubbling event handlers, starting at the bottom and working our way  
    3. 

   
   
  3. // up.  
    4. 

   
   
  4. size_t size = m_event->eventPath().size();  
    5. 

   
   
  5. for (size_t i = 1; i < size; ++i) {  
    6. 

   
   
  6. const NodeEventContext& eventContext = m_event->eventPath()[i];  
    7. 

   
   
  7. if (m_event->bubbles() && !m_event->cancelBubble()) {  
    8. 

   
   
  8. m_event->setEventPhase(Event::kBubblingPhase);  
    9. 

   
   
  9. }  
    10. 

   
   
  10. eventContext.handleLocalEvents(*m_event);  
    11. 

   
   
  11. if (m_event->propagationStopped())  
    12. 

   
   
  12. return;  
    13. 

   
   
  13. }  
    14. 

   
   
  14. } 
    15.

可以看到bubbling的for循环是从i = 1开始，和capturing相反。因为bubble是三个阶段最后处理的，所以它不用再返回一个标志了。

上面介绍完了事件的捕获和冒泡，我们注意到一个细节，所有的事件都会先在capture阶段在windows上触发。

综合以上，本文从源码角度介绍了事件的数据结构，从一个侧面解绑事件介绍事件和DOM节点的联系，然后重点分析了事件的捕获及冒泡过程。相信看完本文，对事件的本质会有一个更透彻的理解。





本文作者：佚名
来源：51CTO
文章标签：
Web App开发
JavaScript
Java
流计算
关键词：
Chrome浏览器
浏览器事件
浏览器事件机制
浏览器机制
浏览器源码
玄学酱
目录
相关文章
小王老师呀
|
1天前
|
Web App开发 缓存 安全
WIN11 Chrome 双击打不开闪退及Chrome浏览器不能拖拽文件crx
【11月更文挑战第6天】本文介绍了 WIN11 系统中 Chrome 浏览器双击打不开闪退及不能拖拽文件 crx 的原因和解决方法。包括浏览器版本过旧、扩展程序冲突、硬件加速问题、缓存过多、安全软件冲突、系统文件损坏、用户配置文件损坏等问题的解决方案，以及 crx 文件的屏蔽、权限问题和文件格式问题的处理方法。
小王老师呀
11 2
小王老师呀
|
3天前
|
Web App开发 Linux iOS开发
Chrome浏览器如何导出所有书签并导入书签
【11月更文挑战第4天】本文介绍了如何在 Chrome 浏览器中导出和导入书签。导出时，打开书签管理器，点击“整理”按钮选择“导出书签”，保存为 HTML 文件。导入时，同样打开书签管理器，点击“整理”按钮选择“导入书签”，选择之前导出的 HTML 文件即可。其他主流浏览器也支持导入这种格式的书签文件。
小王老师呀
8 2
mao29955
|
10天前
|
Web App开发 JavaScript 前端开发
使用 Chrome 浏览器的内存分析工具来检测 JavaScript 中的内存泄漏
【10月更文挑战第25天】利用 Chrome 浏览器的内存分析工具，可以较为准确地检测 JavaScript 中的内存泄漏问题，并帮助我们找出潜在的泄漏点，以便采取相应的解决措施。
mao29955
84 9
大树营养快线
|
27天前
|
Web App开发 开发者
使用 Chrome 浏览器的 DevTools 检测内存泄漏
【10月更文挑战第8天】
大树营养快线
397 1
我是快乐的嘟嘟
|
29天前
|
Web App开发 JSON 安全
Chrome浏览器的跨域问题
【10月更文挑战第6天】
我是快乐的嘟嘟
314 2
邹荣乐
|
23天前
|
JavaScript API
深入解析JS中的visibilitychange事件：监听浏览器标签间切换的利器
深入解析JS中的visibilitychange事件：监听浏览器标签间切换的利器
邹荣乐
63 0
游客6zpnw4ohuini4
|
1月前
|
Web App开发 缓存 安全
Chrome浏览器启动参数大全
这是一组用于定制浏览器行为的命令行参数，包括但不限于：不停用过期插件、放行非安全内容、允许应用中心脚本、停用GPU加速视频、禁用桌面通知、禁用拓展及各类API、调整缓存设置、启用打印预览、隐身模式启动、设定语言、使用代理服务器、无头模式运行等。通过这些参数，用户可以根据需求灵活调整浏览器功能与性能。
游客6zpnw4ohuini4
227 0
我是快乐的嘟嘟
|
2月前
|
Web App开发 存储 前端开发
Chrome浏览器的跨域问题
Chrome浏览器的跨域问题
我是快乐的嘟嘟
272 2
奔跑的数据
|
2月前
|
Web App开发 数据采集 存储
WebDriver与Chrome DevTools Protocol：如何在浏览器自动化中提升效率
本文探讨了如何利用Chrome DevTools Protocol (CDP) 与 Selenium WebDriver 提升浏览器自动化效率，结合代理IP技术高效采集微博数据。通过CDP，开发者可直接操作浏览器底层功能，如网络拦截、性能分析等，增强控制精度。示例代码展示了如何设置代理IP、cookie及user-agent来模拟真实用户行为，提高数据抓取成功率与稳定性。适用于需要频繁抓取互联网数据的应用场景。
奔跑的数据
402 3
WebDriver与Chrome DevTools Protocol：如何在浏览器自动化中提升效率
。思索
|
3月前
|
Web App开发
Chrome——谷歌浏览器chrome如何模拟其他客户端
Chrome——谷歌浏览器chrome如何模拟其他客户端
。思索
102 1
Chrome——谷歌浏览器chrome如何模拟其他客户端