Parlons des compétences JavaScript threads_javascript

Code Jugement 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>

Une fois exécutés, tous les navigateurs se bloqueront si rien d'autre ne se produit, car il y a trop de boucles for ci-dessus, ce qui consomme beaucoup de ressources CPU. Étant donné que JavaScript est monothread, le rendu de l'interface utilisateur du navigateur est suspendu et. provoque une animation suspendue.

Maintenant la question se pose, je veux juste implémenter le code ci-dessus, que dois-je faire ?

Concurrent.Thread.js
​ ​ ​ Cette bibliothèque de classes utilise essentiellement setTimeout pour implémenter un "faux multi-threading". C'était un bon choix avant la sortie de HTML5 WebWorker. Par exemple, si nous voulons implémenter "l'extrait de code 1" ci-dessus, nous pouvons l'écrire comme ceci (cliquez sur moi pour télécharger la bibliothèque de classes) :

Extrait de code 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>

Un "nouveau fil" peut être créé via la méthode create fournie par cette bibliothèque de classes. De plus, définir l'attribut type de la balise script sur text/x-script.multithreaded-js peut également obtenir le même effet :

Fragment de code trois :

<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
Comment HTML5 peut-il fermer les yeux sur la mauvaise expérience utilisateur des navigateurs ci-dessus bloqués ?

Ensuite, nous utilisons la séquence classique de Fibonacci pour tester :

Fragment de code quatre :

Page principale :

<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));//向主页面发送数据
}

L'utilisation de base a été commentée dans le code. En regardant la console, vous pouvez voir que le temps d'exécution sera bientôt imprimé. Nous sommes donc arrivés à la conclusion que WebWorker est adapté pour effectuer des calculs complexes et à grande échelle en amont. Il convient de noter que WebWorker ne prend pas en charge le cross-domain. Les tests locaux doivent toujours utiliser le protocole http. Sinon, l'objet Worker ne pourra pas être créé et une erreur de script sera signalée.

Si nous devons effectuer plusieurs opérations postMessage en continu, il est préférable de ne pas écrire work.postMessage tout le temps, comme ceci :

    worker.postMessage(36);

    worker.postMessage(36);

    worker.postMessage(36);

Puisqu'il n'y a qu'une seule instance WebWorker pour le moment, postMessage sera exécuté de manière séquentielle plutôt qu'asynchrone, ses performances ne peuvent donc pas être pleinement utilisées. Les données peuvent être envoyées en créant plusieurs instances WebWorker.

Quelques points à noter :

1. Nous avons observé que WebWorker crée un travailleur en acceptant une URL, et le principe d'implémentation de jsonp est de charger des données en insérant dynamiquement des balises de script. Ne serait-il pas préférable d'essayer d'utiliser WebWorker pour réaliser la même chose. ? Parce que WebWorker est multithread et n'a aucun blocage, ne serait-il pas beau ? Mais en fait, après expérimentations, nous avons constaté que les performances de WebWorker n'étaient pas satisfaisantes. Ce n’est donc pas pour cela qu’il est bon, nous ne devrions pas le laisser prendre le dessus.

2. Lorsque WebWorker accepte des informations provenant d'autres sources, cela entraîne en fait des dangers cachés pour la sécurité du site. S'il reçoit des informations de script provenant de sources inconnues, cela peut conduire à des attaques par injection XSS. Il faut donc se prémunir contre cela. En fait, il est dangereux d'utiliser innerHTML dans notre exemple ci-dessus. Vous pouvez plutôt utiliser innerText ou textContent fourni par les navigateurs modernes pour filtrer les balises HTML.

Je suis assez fatigué aujourd'hui et j'ai envie de dormir, alors je vais écrire ceci pour le moment.