.on() 和 .click() 哪个更快？
如果我有一个带有删除记录链接的表，那么连接单击事件的最佳方法是什么？这些在幕后的评价是否相同？
$("#table").on("click", ".delete", function(){
//do stuff
});
或者
$("#table .delete").click(function(){
//do stuff
});
If I have a table with links to delete a record, which is the best way to wire up the click event? Do these evaluate the same under the hood?
$("#table").on("click", ".delete", function(){
//do stuff
});
or
$("#table .delete").click(function(){
//do stuff
});
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，他们没有。
按照您使用它们的方式...
.on()您使用它的方式（委托），将为您节省附件和内存的周期，因为它实际上并没有在那一刻附加事件，因为它提供了一个动态元素，其中事件也应用于未来的元素。.click()将节省执行时的周期，因为它会及时将事件显式附加到每个匹配的元素，但实际上，这将是我寻找的最后一个地方瓶颈。在此处阅读一些事件委托测试...
附加事件处理程序的性能测试...
No, they don't.
In the way you are using them...
.on()The way you are using it (delegation), will save you cycles at attachment as well as memory, because it doesn't actually attach the events in that moment, as it provides a dynamic element where the event is applied to future elements as well..click()will save you cycles at execution, as it explicitly attaches an event to every matching element at that moment in time, but in reality, this would be the last place I'd look for a bottleneck.Read some testing with event delegation here...
Performance testing of attaching event handlers...
这就像问
C#中int和string哪个更快。每种类型都有其用途...问题不在于哪个更快，而在于何时使用什么。
on允许您将事件附加到动态添加的元素，而click则不然。如果您没有“动态添加元素”，请使用 click，否则使用
on。It's like asking what is faster
intorstringinC#. Each type has it's uses...It's not about which is faster, it's about what to use when.
onallows you to attach event to dynamically added elements whileclickdoes not.if you don't have "dynamically added elements" use click, otherwise use
on.click比on更快，因为它将事件直接附加到元素上，而on则将事件附加到#table 并查找.delete元素来触发事件，因此在触发click事件之前会执行一些代码。尽管您不会看到任何差异，但差异可以忽略不计。
如果您使用
on，则仅有一个事件处理程序就足以处理#table内任意数量的.delete元素，其中>click将附加到每个.delete元素，以便在内存利用率方面更好地on。clickis faster thatonbecause it attaches the event directly on the element where asonis attaching the event on#tableand looking for.deleteelement to trigger the event so there is some code execution involved before theclickevent is triggered.The difference is negligible though you will not see any difference.
If you use
onthe only one event handler is enough to take care of any number of.deleteelements inside the#tablewhere asclickwill be attached to each of the.deleteelements soonbetter in terms of memory utilization.在这种特殊情况下，
.click(...)将（可能）变慢，因为它将需要迭代与选择器匹配的每一行和每个单元格，并将处理函数附加到每一个。在这种特殊情况下，on(...)可能会更快，因为它将处理程序附加到表，而不是每个具有.delete的元素> 类。话虽如此，在这两者之间进行选择时，您需要考虑一些事情：
$('#rootItem').on('click', '.foo .bar.baz .bum', function() { /* do stuff*/ })，则此操作本质上会比$('#rootItem').on('click', '.foo', function() { /* do stuff*/ })慢，因为选择器在以下方面更复杂前一种情况。在这种情况下，支付附件费用并使用click(...)来节省评估#rootItem< 内每次点击的运行时成本可能更有意义。 /code> 来查看它是否与选择器'.foo .bar.baz .bum'匹配。像您这样的简单单类选择器（'.delete'）将表现得很好。click(...)。只要您的“外部”选择器（在本例中为'#table'）不指向，on(...)函数就可以更好地处理这个问题at 将动态添加的元素。将'#table'替换为'.table'，并动态添加一个新的表，其类为table，新添加的表将'在您最初调用on(...)时，不会附加事件处理程序。In this particular scenario, the
.click(...)will (likely) be slower, because it will need to iterate through each row and each cell that matches the selector, and attach the handler function to each one. Theon(...), in this particular case, is likely to be faster, because it attaches the handler to the table, not to each element that has the.deleteclass.That being said, you need to consider a few things when choosing between these two:
$('#rootItem').on('click', '.foo .bar.baz .bum', function() { /* do stuff*/ }), this will be inherently slower than$('#rootItem').on('click', '.foo', function() { /* do stuff*/ })because the selector is more complex in the former case. In this kind of scenario, it might make more sense to pay the price on attachment and useclick(...)to save the run-time cost of evaluating every click within#rootItemto see if it matches the selector'.foo .bar.baz .bum'. A simple single-class selector like you have ('.delete') will perform just fine.click(...)on each dynamically-added item. Theon(...)function can handle this a little better, as long as your "outside" selector ('#table'in this case) doesn't point at elements that will be dynamically added. Replace'#table'with'.table', and dynamically add a new table with classtable, and the newly-added table won't have event handlers attached to it from your initial call toon(...).