Lassen Sie uns über JavaScript-Threads_Javascript-Fähigkeiten sprechen

Kodex-Urteil 1:

<div id="div">
  click me
</div>

<script>
  var div=document.getElementById("div");
  div.addEventListener('click',function(){
   alert('You have clicked me!');
  });
  for(var i =0; i<999999999;i++){
   console.log(i);
  }
</script>

Bei der Ausführung frieren alle Browser ein, wenn nichts anderes passiert, da oben zu viele for-Schleifen vorhanden sind, die viele CPU-Ressourcen verbrauchen. Aufgrund der Tatsache, dass JavaScript Single-Threaded ist, wird das Rendern der Browser-Benutzeroberfläche angehalten verursacht eine unterbrochene Animation.

Jetzt kommt die Frage: Ich möchte nur den obigen Code implementieren. Was soll ich tun?

Concurrent.Thread.js
​ ​ ​ Diese Klassenbibliothek verwendet im Wesentlichen setTimeout, um ein „falsches Multithreading“ zu implementieren. War eine gute Wahl, bevor HTML5 WebWorker herauskam. Wenn wir beispielsweise das obige „Code-Snippet 1“ implementieren möchten, können wir es so schreiben (klicken Sie auf mich, um die Klassenbibliothek herunterzuladen):

Codeausschnitt 2:

<div id="div">
  click me
</div>
<script src="Concurrent.Thread.js"></script>
<script>
  Concurrent.Thread.create(function(){
    var div=document.getElementById("div");
    div.addEventListener('click',function(){
     alert('You have clicked me!');
    });
    for(var i =0; i<9999999;i++){
     console.log(i);
    }
  });
</script>

Ein „neuer Thread“ kann über die von dieser Klassenbibliothek bereitgestellte Methode „create“ erstellt werden. Darüber hinaus kann auch das Festlegen des Typattributs des Skript-Tags auf text/x-script.multithreaded-js den gleichen Effekt erzielen:

Codefragment drei:

<div id="div">
  click me
</div>
<script src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
    var div=document.getElementById("div");
    div.addEventListener('click',function(){
     alert('You have clicked me!');
    });
    for(var i =0; i<9999999;i++){
     console.log(i);
    }
</script>

WebWorker
Wie kann HTML5 die schlechte Benutzererfahrung ignorieren, wenn die oben genannten Browser hängen bleiben?

Als nächstes verwenden wir die klassische Fibonacci-Folge zum Testen:

Codefragment vier:

Hauptseite:

<div id="div"></div>
<script>
  window.onload=function(){
     var div=document.getElementById("div");
     if(typeof(Worker)!=="undefined"){//在创建WebWorker之前，先判断浏览器是否支持
　　　　　　　 console.log("Start calculating....");
       var time1= new Date()*1;//获得当前时间戳
       var worker=new Worker("fibonacci.js");//创建WebWorker对象，并传递在新线程中将要执行的脚本的路径
       worker.onmessage=function(e){ //监听从新线程发送过来的数据
         div.innerHTML=e.data;
         var time2=new Date()*1;
         console.log("time spend:"+(time2-time1)+"ms");
       }
　　　　　　　　
       worker.postMessage(36);//向新线程发送数据
     }else{
       alert("Your browser do not support WebWoker");
     }
  }
</script>

fibonacci.js：
var fibonacci=function (n){
  return n<3&#63;n:(arguments.callee(n-1)+arguments.callee(n-2));
}
onmessage=function(e){
  var num=parseInt(e.data,10);
  postMessage(fibonacci(num));//向主页面发送数据
}

Die grundlegende Verwendung wurde im Code kommentiert. Wenn Sie sich die Konsole ansehen, können Sie sehen, dass die Ausführungszeit bald ausgedruckt wird. Daher kamen wir zu dem Schluss, dass WebWorker für die Durchführung komplexer und umfangreicher Berechnungen im Frontend geeignet ist. Es ist zu beachten, dass WebWorker keine domänenübergreifenden Tests unterstützt. Verwenden Sie weiterhin das Dateiprotokoll. Andernfalls kann das Worker-Objekt nicht erstellt werden und es wird ein Skriptfehler gemeldet.

Wenn wir mehrere postMessage-Vorgänge kontinuierlich ausführen müssen, ist es am besten, work.postMessage nicht ständig zu schreiben, wie folgt:

    worker.postMessage(36);

    worker.postMessage(36);

    worker.postMessage(36);

Da derzeit nur eine WebWorker-Instanz vorhanden ist, wird postMessage sequentiell statt asynchron ausgeführt, sodass seine Leistung nicht vollständig genutzt werden kann. Daten können durch die Erstellung mehrerer WebWorker-Instanzen gesendet werden.

Ein paar Dinge, die Sie beachten sollten:

1. Wir haben beobachtet, dass WebWorker einen Worker erstellt, indem es eine URL akzeptiert, und das Implementierungsprinzip von jsonp darin besteht, Daten durch dynamisches Einfügen von Skript-Tags zu laden. Wäre es nicht besser, wenn wir versuchen würden, WebWorker zu verwenden, um dasselbe zu erreichen? ? Wäre es nicht schön, weil WebWorker multithreaded ist und keine Blockierung aufweist? Tatsächlich stellten wir jedoch nach Experimenten fest, dass die Leistung von WebWorker nicht zufriedenstellend war. Darin ist es also nicht gut, wir sollten es nicht die Oberhand gewinnen lassen.

2. Wenn WebWorker Informationen aus anderen Quellen akzeptiert, birgt dies tatsächlich versteckte Gefahren für die Sicherheit der Website. Wenn es Skriptinformationen aus unbekannten Quellen erhält, kann dies zu XSS-Injection-Angriffen führen. Daher ist die Verwendung von innerHTML in unserem Beispiel oben tatsächlich unsicher. Sie können stattdessen innerText oder textContent verwenden, die von modernen Browsern bereitgestellt werden, um HTML-Tags herauszufiltern.

Ich bin heute ziemlich müde und möchte schlafen, deshalb schreibe ich erst einmal so viel.