jQuery live 方法有什么问题？答案

【问题标题】：What's wrong with the jQuery live method?jQuery live 方法有什么问题？
【发布时间】：2012-06-20 08:45:10
【问题描述】：

live() 方法在 jQuery 1.7 中已弃用。现在推荐 jQuery 文档

使用.on() 附加事件处理程序。旧版本 jQuery 的用户应该使用.delegate() 而不是.live()。

我了解on 和delegate 的工作原理，但我不明白为什么它们更好。 live() 更简单易用。

live 被弃用有什么原因吗？其他方法如何更好？如果我继续使用live，会有什么不好的事情发生吗？

【问题讨论】：

除了你的代码在他们停止支持时破坏？不多...尤其是如果您使用 jQuery 的本地副本...
下面的答案很好，但有一个实际的方面要弃用：工具包开发人员不再需要支持live。由于他们添加了on，并认为这是一个很好的解决方案，他们不再需要支持和维护live，所以他们已经弃用它，不管它是坏的还是好的。在这种情况下，有一些理由避免使用live，但在一般情况下，如果出于任何原因将方法添加到工具包中，开发人员可能会选择弃用执行类似操作的方法为了便于维护。

标签： jquery

【解决方案1】：

在这里查看一些解释：

~~http://www.ultimatewebtips.com/why-jquery-live-is-a-bad-option-to-use/~~（网站似乎已关闭）

引用：

您不能将.live() 用于可重复使用的小部件。
.stopPropagation() 不适用于直播。
.live() 更慢。
.live() 不可链接。

进一步.on()的美妙之处在于它很好地简化了所有事件：http://api.jquery.com/on/

你知道 api 链接，看看 .on() 是如何工作的 :)

引用：

.on() 方法将事件处理程序附加到当前选定的集合 jQuery 对象中的元素。从 jQuery 1.7 开始， .on() 方法提供附加事件处理程序所需的所有功能。为了帮助从旧的 jQuery 事件方法转换，请参阅 .bind()， .delegate() 和 .live()。要删除与 .on() 绑定的事件，请参阅。离开（）。附加仅运行一次然后删除的事件本身，见 .one()

【讨论】：

尽管.live() 在 jQuery 1.9 中被删除，但第 1、2 和 3 点需要严格限定，第 4 点完全是错误的。

【解决方案2】：

live() 效率低下有两个原因：

在构造$('selector').live() 中，jQuery 首先必须选择所有元素。但是，当调用live() 时，它只需要jQuery 对象的选择器（存储在.selector 中），实际上并不使用任何被选择的元素。因此，先选择所有匹配的元素然后不使用它们有点浪费。 on() 和delegate() 将目标选择器作为参数，这意味着没有预先选择目标元素，仅在触发事件时进行测试。
live() 默认绑定在 document 级别，因此所有事件都需要在整个 DOM 中冒泡。您可以通过使用$(selector, context).live() 指定上下文来缩小范围，但最好使用on() 或delegate()。

在编写新代码时，强烈建议使用最新最好的on()，而不是delegate()和已弃用的live()。但是，我认为对live() 的支持不会很快（如果有的话）被放弃，因为很多脚本都依赖它。此外，使用live() 而不是on() 并没有真正的缺点，因为在jQuery 源代码本身中live() 被定义为：

live: function( types, data, fn ) {
    jQuery( this.context ).on( types, this.selector, data, fn );
    return this;
}

【讨论】：

$(selector, context) 不会改变.context，所以它仍然是document。您必须传递 dom 元素，如 $($("body")[0]).find("span") 才能将 .context 更改为其他内容

【解决方案3】：

live 方法有两个主要问题：

它在文档级别附加所有事件处理程序，因此任何冒泡到文档的事件都必须与所有实时事件的事件类型和选择器相匹配。如果你有很多事件，页面会很慢。您应该使用delegate 或on 来限制您检查事件的范围。
对于选择器如何与库中的其他方法一起使用，该方法的用法并不典型。您只能在使用选择器创建的 jQuery 对象上使用它。 delegate 和 on 方法使这很自然，因为您将选择器提供给方法。

【讨论】：

【解决方案4】：

live() 将处理程序附加到文档，这基本上会导致拦截给定类型的所有事件，从而产生搜索匹配选择器的元素的成本。使用delegate() 和on()，建议您附加到更靠近预期目标的位置（如果可能，在其直接父级中），从而减少处理的事件数量，并分别搜索匹配的目标。

【讨论】：

【解决方案5】：

我很确定这是由于.live() 的性质造成的。这很方便，但这是一种不好的做法，因为它会迫使您的浏览器在大多数情况下搜索比需要更多的事件。

默认情况下搜索整个文档以查找某个事件，而不是搜索特定容器的数据效率更高。

live() 确实使用起来很方便，而且大多数 os uf 从未注意到使用它的任何缺陷。在我眼里，基本上是改进的bind()。

但在很多时候，我们必须适应并更清楚我们的代码需要执行什么。

这就像问自己为什么必须导入一些东西，以及为什么不是一开始就导入所有东西。

【讨论】：

我认为您可以通过选择字符串来限制搜索，即"#mydiv .edit" 而不是".edit"。
并非如此。 live() 将始终检查每次事件执行时整个文档中的#mydiv 中是否有.edit。找不到现有的#mydiv 并检查其子级。

【解决方案6】：

这是关于 live() 性能和限制的详细 article by Paul Irish。

如果您继续使用live，如果您升级项目中的 jQuery 库，您的代码迟早将无法工作。

【讨论】：

【解决方案7】：

$('some selector').live(' ... ', handler)

和

一样

$(document).on(' ... ', 'some selector', handler)

因此，当您使用live 时，您实际上将所有处理程序分配给您的 DOM 树的根。这样做有两个缺点：

将处理程序附加到 DOM 根会增加事件在冒泡时必须遍历的路径。这会严重影响性能。
增加了一些其他以 return false 结尾的处理程序会阻止 live 处理程序触发的风险。

【讨论】：