最近我遇到了网络工作者，这是一种让您的脚本并行运行的方法。让您的脚本在后台运行而不“冻结”用户界面。当我发现这一点时，我想我已经找到了一种可以在我的 ionic 应用程序中实施的新技术，它应该会带来显着的 UX 性能改进。
但是经过一番搜索，我几乎找不到任何关于 ionic 中的 web workers 的文章。由于 web worker 并不是什么新鲜事物，为什么在 ionic 甚至 Angular 中几乎没有提及它？离子不适合实施吗？或者，这是我忽略的其他东西？
【问题讨论】：
标签： javascript angularjs performance ionic-framework web-worker
网络工作者是否会对 ionic 应用程序有益？
这完全取决于您是否有一些繁重的处理可以卸载给网络工作者。
由于 web worker 并不是什么新鲜事物，为什么在 ionic 甚至 Angular 中几乎没有提及它？
因为webworkers与UI框架无关，因为webworkers中的代码不能直接操作浏览器的UI（比如不能操作DOM，或者做alerts，播放音频等.)。因此，Web Worker 代码对于 UI 框架库几乎没有用处，因为该库的工作主要是完成 Web Worker 无法做到的事情。相反，有一个主 UI 线程（页面的默认 JavaScript 线程）允许使用 DOM 等，因此有理由使用 UI 框架库。
详情：
最初，Web 浏览器中的 JavaScript 在单个线程上运行，这也更新了 UI。这使得模型非常简单，没有并发问题，并且非常简单和成功。但它也有局限性：随着 JavaScript 开始被用于越来越多的事情，一个 UI 线程在处理中陷入困境，浏览器必须实施启发式算法来执行“慢速脚本”警告等，因此用户不会认为浏览器已经结冰了。
引入 Web Worker 是为了让我们在浏览器托管的 JavaScript 中拥有线程，同时保持单个 UI 线程的强大简单性而不会出现并发问题（这也是它们不与其他线程共享全局数据区域的原因）。它们让我们在其他线程中进行繁重的处理，但不允许让我们在这些线程中更新 UI。
这项工作可能与用户界面间接相关。例如，在现代浏览器上，可以将某些类型的对象（称为transferrable objects）从主 UI 代码发送到 Web Worker 代码。 IIRC，画布是可转让的。我们解决了并发问题，因为一旦您将可传输对象从一个线程发布到另一个线程，它就只能在目标中访问，而不再在源中访问。因此，允许直接与 UI 交互的主 UI 线程可以获取一些东西（如画布）并将其传输给 Web Worker 对其执行某些操作（可能是转换），然后将其发送回来。但由于该工作不涉及直接操作浏览器 UI（DOM 等），因此不太可能调用 UI 框架库。
【讨论】：