unity 脚本加载脚本_脚本编写，加载和讽刺

最新推荐文章于 2023-03-05 20:16:08 发布

dingshi7798

最新推荐文章于 2023-03-05 20:16:08 发布

阅读量101

点赞数

文章标签： java python javascript 编程语言人工智能 ViewUI

原文链接：https://www.sitepoint.com/scripting-loading-and-irony/

版权

unity 脚本加载脚本

在技术世界中，我们找到的解决方案与解决的问题一样好。我只是喜欢这里的讽刺意味。一天解决问题的方法实际上可能只是掩盖了更大并发症的症状。让我详细说明...

脚本和加载

当我在1999年左右开始对JavaScript进行编程时，没有人考虑组件加载时的同步。我们将所有脚本放入<head>部分，并将所有内容绑定到window.onload 。我们这样做是因为这是所接受的智慧，而所接受的智慧也没有考虑太多，因为这个问题从未出现过 。人们在使用JavaScript方面做得很少。哦，总是有例外，例如亚伦·布德曼（ Aaron Boodman）的全滑，全旋的站点；它使我们所有人都感到羞耻，并在Netscape 4中表现最佳。在大多数情况下，脚本仅用于打开弹出窗口，图像翻转效果以及偶尔的下拉菜单。但是随着时间的推移，页面越来越大并且脚本变得更加复杂-由于连接速度更快，人们使用了越来越多的图像-显然，在脚本能够运行之前等待所有内容加载现在是无法接受的延迟。在2005年左右，出现了各种解决方案。现在，这些方法中最方便，最直接的方法已成为标准方法，随处可见。当然，最值得注意的是浏览器直接提供的内容： DOMContentLoaded事件。

反讽

关于DOMContentLoaded的奇妙之处在于，它会在图像加载之前即DOM可用时触发。至少，这就是这个名字的含义。在现实中，这不是火灾时在all.It实际上明确时触发的DOM-并可能影响DOM-外部依赖性已经解决。实际上，这意味着该事件实际上并没有绕过依赖关系，而是仅绕过了图像。在 DOMContentLoaded触发之前，必须先加载和解析页面上的所有非延迟脚本和样式表。当我们首次开始使用DOMContentLoaded ，这并不明显。我只是开始认真考虑这个问题，因为我发现自己处于这样一种情况，我需要在<head>可用后立即执行脚本，然后才能解析脚本和样式表。（确切地说，它不一定要在之前，也不能在之后。）当DOMContentLoaded成为脚本编写的标准方法时，我们只是在考虑图像。但是图像不再是敌人。当您发现自己正在等待页面完成加载的永恒时，您通常在等待图像吗？还是从六个（不是特别强大的）广告服务器中创建六个广告联合脚本？在DOMContentLoaded启动之前，所有这些都必须解决，而且DOMContentLoaded越来越多，这比图像需要更长的等待时间。因为不是依赖项的大小导致延迟，所以它正在等待所有这些服务器的响应。

我做了一点研究，看看是否还有其他人在谈论这个问题，我发现关于DOMContentLoaded应该在样式表之前还是之后引发争论。（显然，Opera与其他浏览器不同，并且Firefox可能不一致。）就我个人而言，我可以看到这两种方法如何根据情况而有所帮助。这一切都让我想到了我在2005年开发的解决方案，作为对原始版本的贡献问题。称为domFunction ，它基于异步计时器，该计时器仅检查<body>元素的存在（以确保可以安全地引用和创建DOM中的内容），并在存在时立即触发回调。当时它从来没有真正流行过，也许是因为它不像其他方法那样简单或优雅。该解决方案还解决了我的新问题！关于依赖关系，它是真正不可知的，这就是我选择适应最新脚本的方式。（尽管原始解决方案仅每250ms循环一次，但我将其提高到20ms，因为我知道这只是对<head>的最小等待，并且实际上只需要进行一到两次迭代。）检查其他特定的依赖关系；这就是我接下来几周要考虑的问题。它可以检查<head> ， <body> ， styleSheets集合和/或CSS的渲染应用程序（通过computedStyle评估）；它可以检查是否存在特定元素或特定脚本对象，或者您需要等待什么。可能性很有趣。同样有趣的是DOM 2突变事件和/或通用对象监视程序提供的可能性。也许我们可以监视整个文档的状态，以了解特定节点是否处于脚本编写要使用的状态。或了解它们是否受到特定CSS应用程序的影响。这些都是好主意，所以我们拭目以待。 缩图： goldberg