网络工作者会对离子应用程序有所帮​​助吗？

Question

最近我遇到了网络工作者，这是让脚本平行运行的一种方式。让脚本在后台运行而不会“冻结”用户界面。当我发现这一点时，我想我已经找到了一种新技术来实现我的离子应用程序，这应该会带来显着的用户体验性能提升。

但经过一番搜索，我几乎没有发现任何文章谈论离子网络工作者。由于网络工作者并不是什么新鲜事物，为什么在离子甚至是Angular中几乎没有提到它呢？离子不适合实施？或者，我忽略了其他的东西？

Answer 1

网络工作者会对离子应用程序有利吗？

这完全取决于您是否有一些可以卸载到网络工作者的繁重处理。

由于网络工作者并不是什么新鲜事物，为什么在离子甚至是Angular中几乎没有提到它呢？

由于网络工作者都无关的UI框架，因为在网络工作者的代码不能直接操纵浏览器的UI（如，不能处理DOM，或做alert S，播放音频，等等。）。因此，Web工作者代码对于UI框架库几乎没有任何用处，因为该库的工作主要是处理web工作者无法做的事情。相反，有一个主UI线程（该页面的默认JavaScript线程）允许使用DOM等，因此有理由使用UI框架库。

详情：

原来，在JavaScript的Web浏览器运行在单个线程，这也更新了UI。这为非简单模型提供了无并发问题，并且非常简单和成功。但它也是限制性的：随着JavaScript开始越来越多地被用于越来越多的事情，一个UI线程在处理中陷入困境，浏览器不得不实施启发式操作来执行“慢速脚本”警告等，因此用户不会认为浏览器已经冻结。

为了让我们在浏览器驻留的JavaScript中有线程，同时保持单个UI线程的强大的简单性而没有并发问题（这也是为什么他们不与其他人共享全局数据区域线程）。他们让我们在其他线程中执行大量处理，但是而不是允许我们更新这些线程中的UI。

那个工作可以是间接与UI有关。例如，在现代浏览器中，可以将主要UI代码中的某些类型的对象（称为transferrable objects）发送到Web Worker代码。 IIRC，画布可以转让。我们解决了并发问题，因为一旦将可传输对象从一个线程发布到另一个线程，它只能在目标中访问，而不能在源中访问。因此，允许直接与UI进行交互的主UI线程可以将某些内容（如画布）转移给Web工作人员，以便对其执行某些操作（可能是转换），然后将其发回。但由于该工作不涉及直接操纵浏览器UI（DOM等），因此不太可能使用UI框架库。