網絡工作者會對離子應用有益嗎？

Question

最近我遇到了Web工作者，這是讓腳本並行運行的一種方法。 使腳本在后台運行而不會“凍結”用戶界面。 當我發現這一點時，我想我已經找到了一種新的技術來實現我的離子應用程序，這應該會帶來顯着的用戶體驗性能提升。

但經過一番搜索后，我幾乎找不到任何關於離線網絡工作者的文章。 由於網絡工作者不是一個非常新的東西，為什么在離子或甚至Angular中幾乎沒有提到它？ 離子是不適合實施的？ 或者，這是我忽視的其他事情？

Answer 1

網絡工作者會對離子應用有益嗎？

這完全取決於您是否有一些可以卸載給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框架庫。