最近我遇到了网络工作者，这是让你的脚本并行运行的一种方法。让您的脚本在后台运行而不会冻结＆＃34;用户界面。当我发现这一点时，我想我已经找到了一种新的技术来实现我的离子应用程序，这应该会带来显着的用户体验性能提升。
但经过一番搜索后，我几乎找不到任何关于离线网络工作者的文章。由于网络工作者不是一个非常新的东西，为什么在离子或甚至Angular中几乎没有提到它？离子是不适合实施的？或者，这是我忽视的其他事情？
答案 0 :(得分：10)
网络工作者会对离子应用程序有益吗？
这完全取决于您是否有一些可以卸载给Web工作人员的繁重处理。
由于网络工作者不是很新的东西，为什么在离子甚至Angular中几乎没有提到它？
因为Web工作者与UI框架无关，因为Web工作者中的代码无法直接操作浏览器的UI（例如，无法操纵DOM，或者执行alert s，播放音频等）。因此，Web工作者代码对UI框架库几乎没有用处，因为该库的工作主要是做Web工作者无法做的事情。相反，有一个主UI线程（页面的默认JavaScript线程）允许使用DOM等，因此有理由使用UI框架库。
详细说明：
最初，Web浏览器中的JavaScript在单个线程上运行，该线程也更新了UI。这使得一个非常简单的模型没有并发问题，并且非常简单和成功。但它也有限制：随着JavaScript开始习惯越来越多的东西，一个UI线程在处理中陷入困境，浏览器必须实现启发式来做“慢脚本”警告等等所以用户不认为浏览器已冻结了。
介绍Web工作者是为了让我们在浏览器托管的JavaScript中拥有线程，同时保持单个UI线程的强大简单性而不会出现并发问题（这也是他们不与其他线程共享全局数据区域的原因） ）。他们让我们在其他线程中进行繁重的处理，但不允许我们更新这些线程中的UI。
该工作可以间接与UI相关。例如，在现代浏览器上，可以从主UI代码向Web worker代码发送称为transferrable objects的某些类型的对象。 IIRC，画布是可转让的。我们解决了并发问题，因为一旦您将可转移对象从一个线程发布到另一个线程，它只能在目标中访问，而不能在源中访问。因此允许直接与UI交互的主UI线程可以采取某些东西（如画布）并将其传递给Web工作者以对其执行某些操作（可能是转换），然后将其发回。但由于该工作不涉及直接操纵浏览器UI（DOM等），因此不太可能需要使用UI框架库。