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