所有点击都要冒泡到 body 元素再处理，性能如何？
本问题摘自 C4 前端交流会的现场观众提问。
担忧
运行性能对于类库来说，是一个非常重要的指标。性能优劣往往会左右开发者对于类库的选择。
对 Action 的性能担忧主要在于以下两点：
body 元素要处理所有动作。- 点击事件触发后要等到冒泡到
body 元素时才会被处理。
前提
在分析性能问题之前，我们需要了解一个概念——“累积效应”。
很多性能测试都是利用大量重复来放大差异，比如分别把两个函数重复执行数万次，再比较两者的耗时长短。这种性能测试方式对数据处理的场景是合适的，因为此时程序的运行模式是同步的，且性能与执行次数（或数据的复杂度）正相关，存在“累积效应”。
举个例子。我写了一个性能不佳的数组 map() 方法，在处理小数组时可能察觉不到异常，但在处理大数组时，性能问题就会突显。在这种存在累积效应的场景下，单次执行的性能差异往往直接影响最终性能。
分析
好，接下来我们来分析上述两种对于性能的担忧。
第一个问题相对简单，实际上我们只会在 body 身上绑定一个事件监听器。这个事件监听器就像是一个中转站，它会根据事件源头来匹配需要执行的动作函数并执行。这意味着，不论页面上有多少个动作元素，事件监听器的数量都不会额外增加。
Action 的这种机制相对于 “对每个动作元素绑定一个事件监听器” 的方案，在资源消耗方面反而有明显优势——因为后者有累积效应。
再来看第二个担忧。
当动作元素被点击后，动作函数并不会 “立即触发”；只有当事件通过 DOM 向上冒泡到 body 元素时，才会查找动作函数并执行。由于 body 元素已经位于 DOM 的顶端了，这样一路冒泡上去，给人感觉似乎存在性能隐患。
从设计上来说，Action 只能选择 body 或 documentElemnt 这样较顶端的元素来注册统一的事件监听器。尽管如此，我们还是来看一下性能对比。
从绝对差异上来看，把事件监听器绑定在 body 上，肯定比绑定在动作元素自身或离它较近的祖先元素上要慢，但这个差异本身是微乎其微的。更重要的是，UI 交互这个场景不存在累积效率，单次性能差距并不会被放大。
由此可见，对于 “事件冒泡” 这个性能担忧点，事实上是不必要的。
所有点击都要冒泡到 body 元素再处理，性能如何？
担忧
运行性能对于类库来说，是一个非常重要的指标。性能优劣往往会左右开发者对于类库的选择。
对 Action 的性能担忧主要在于以下两点：
body元素要处理所有动作。body元素时才会被处理。前提
在分析性能问题之前，我们需要了解一个概念——“累积效应”。
很多性能测试都是利用大量重复来放大差异，比如分别把两个函数重复执行数万次，再比较两者的耗时长短。这种性能测试方式对数据处理的场景是合适的，因为此时程序的运行模式是同步的，且性能与执行次数（或数据的复杂度）正相关，存在“累积效应”。
举个例子。我写了一个性能不佳的数组
map()方法，在处理小数组时可能察觉不到异常，但在处理大数组时，性能问题就会突显。在这种存在累积效应的场景下，单次执行的性能差异往往直接影响最终性能。分析
好，接下来我们来分析上述两种对于性能的担忧。
第一个问题相对简单，实际上我们只会在
body身上绑定一个事件监听器。这个事件监听器就像是一个中转站，它会根据事件源头来匹配需要执行的动作函数并执行。这意味着，不论页面上有多少个动作元素，事件监听器的数量都不会额外增加。Action 的这种机制相对于 “对每个动作元素绑定一个事件监听器” 的方案，在资源消耗方面反而有明显优势——因为后者有累积效应。
再来看第二个担忧。
当动作元素被点击后，动作函数并不会 “立即触发”；只有当事件通过 DOM 向上冒泡到
body元素时，才会查找动作函数并执行。由于body元素已经位于 DOM 的顶端了，这样一路冒泡上去，给人感觉似乎存在性能隐患。从设计上来说，Action 只能选择
body或documentElemnt这样较顶端的元素来注册统一的事件监听器。尽管如此，我们还是来看一下性能对比。从绝对差异上来看，把事件监听器绑定在
body上，肯定比绑定在动作元素自身或离它较近的祖先元素上要慢，但这个差异本身是微乎其微的。更重要的是，UI 交互这个场景不存在累积效率，单次性能差距并不会被放大。由此可见，对于 “事件冒泡” 这个性能担忧点，事实上是不必要的。