Quand il s'agit de HTML5, les gens en parlent toujours. Il y a tellement de fonctionnalités et d'API intéressantes qui sont rafraîchissantes. Cependant, de nombreuses chaussures pour enfants restent encore au stade sémantique et ignorent la puissance du HTML5.
Dans cette section, nous discuterons du Web-Worker multithread.
1. Expliquez clairement que JavaScript est monothreadUne caractéristique majeure du langage JavaScript est qu’il est monothread, ce qui signifie qu’il ne peut faire qu’une seule chose à la fois.
Cela semble bizarre, pourquoi ne pas le concevoir avec du multi-thread pour améliorer l'efficacité ? Nous pouvons supposer un scénario :
Supposons que JavaScript ait deux threads en même temps. Un thread ajoute du contenu à un certain nœud DOM et l'autre thread supprime le nœud. Dans ce cas, quel thread le navigateur doit-il utiliser ?
En tant que langage de script de navigateur, l'objectif principal de JavaScript est d'interagir avec les utilisateurs et de manipuler DOM .
Cela détermine qu'il ne peut être qu'un seul thread, sinon cela entraînera des problèmes de synchronisation très complexes. Afin d'éviter toute complexité, JavaScript est monothread depuis sa création. Cela est devenu une fonctionnalité essentielle du langage et devrait être difficile à modifier à court terme.
Le threading unique a toujours été un problème. Afin de tirer parti de la puissance de calcul des CPU multicœurs, HTML5 propose le standard Web Worker , qui permet aux scripts JavaScript de créer plusieurs threads. Cependant, le thread enfant est entièrement contrôlé par le thread principal et ne doit pas faire fonctionner DOM .
Par conséquent, cette nouvelle norme ne modifie pas la nature monothread de JavaScript .
Web Workers est une solution JavaScript multi-thread fournie par les navigateurs modernes. On peut trouver de nombreux scénarios d'utilisation :
1. Nous pouvons utiliser Web Worker pour effectuer certaines opérations gourmandes en calcul ;
2. Un sondage peut être mis en œuvre et certains états peuvent être modifiés ;
3. Mise à jour de l'état du message d'en-tête, telle que la notification du nombre de messages dans l'en-tête de la page ;
4. Interaction utilisateur à haute fréquence, vérification orthographique, par exemple : aider les utilisateurs à compléter les fonctions de correction des erreurs de saisie et de correction en fonction des habitudes de saisie de l'utilisateur, des enregistrements historiques, du cache et d'autres informations.
5. Chiffrement : Le chiffrement peut parfois prendre beaucoup de temps, surtout si vous devez chiffrer fréquemment de nombreuses données (par exemple, chiffrer les données avant de les envoyer au serveur).
6. Prérécupérer les données : afin d'optimiser votre site Web ou votre application Web et d'améliorer le temps de chargement des données, vous pouvez utiliser Workers
pour charger certaines données à l'avance au cas où vous en auriez besoin.
Le chiffrement est un excellent scénario pour l'utilisation Web Worker car il ne nécessite pas d'accès DOM ou à une autre magie, il utilise simplement des algorithmes pour effectuer des calculs. Alors que le public accorde une attention croissante aux données personnelles sensibles, la sécurité et le chiffrement des informations sont devenus des priorités absolues. Cela peut être reflété dans le récent incident de fuite de données utilisateur 12306.
Une fois le calcul effectué dans Worker, il est transparent pour l’utilisateur et n’affecte pas l’expérience utilisateur.
3. Compatibilité 4. Notions de base1. N'oubliez pas d'abord de juger s'il est pris en charge
si (fenêtre.Worker) { ...} 2. Créer un nouveau worker est facile
const monWorker = new Worker('worker.js');La méthode postMessage() et le gestionnaire d'événements onmessage sont la magie noire de Workers.
3. postMessage est utilisé pour envoyer des messages et onmessage est utilisé pour écouter les messages.
const worker = new Worker('src/worker.js');worker.onmessage = e => { console.log(e.data);};worker.postMessage('Comment vas-tu !'); Lorsqu'ils sont utilisés dans le thread principal, onmessage et postMessage() doivent être accrochés à l'objet worker , mais cela n'est pas obligatoire lorsqu'ils sont utilisés dans worker . La raison en est que, à l’intérieur worker , worker représente effectivement la portée globale.
4.Gestion des exceptions :
work.onerror = function(error) { console.log(error.message); throw error;}; 5. Licencier worker
travailleur.terminate();
Le thread worker est tué immédiatement, sans aucune chance de terminer ses opérations ou de nettoyer.
6. Dans le thread worker , workers peuvent également appeler leur propre méthode close pour fermer :
fermer();5. Démarrage rapide
Afin de comprendre rapidement, faisons un petit exemple : la structure du projet est la suivante
├── index.html└── src ├── main.js └── travailleur.js
HTML
<html><head> <title>Démo Web Work</title> <meta charset=UTF-8 /></head><body> <div id=app> Bonjour Jartto </div> <script src=src /main.js></script></body></html>
main.js
const worker = new Worker('src/worker.js');worker.onmessage = e => { const message = e.data; console.log(`[From Worker] : ${message}`); ('app').innerHTML = message;};worker.postMessage('Bien écrit !');Travail.js
onmessage = e => { const message = e.data; console.log(`[De Main] : ${message}`); if(message.indexOf('Good') > -1) { postMessage('Merci pour votre soutien '); }};Le code est très simple. Le fil principal envoie : "C'est tellement bien écrit !"
Le travailleur Web a reçu le message et a constaté que le contenu contenait le mot « bien » et l'a renvoyé au fil de discussion principal : « Merci pour votre soutien ».
6. Limites 1. Au sein worker , les nœuds DOM ne peuvent pas être directement manipulés et les méthodes et propriétés par défaut de l'objet window ne peuvent pas être utilisées. Cependant, nous pouvons utiliser un grand nombre d'éléments sous l'objet window , y compris des mécanismes de stockage de données tels que WebSockets , IndexedDB et Data Store API spécifique FireFox OS .
Voici un exemple, on modifie main.js :
const worker = new Worker('src/worker.js');worker.onmessage = e => { const message = e.data; console.log(`[From Worker] : ${message}`); ("app").innerHTML = message;};+ travailleur.onerror = fonction (erreur) {+ console.log (erreur);+ travailleur.terminate ();+ };worker.postMessage('Bien écrit !'); Modifions à nouveau work.js
+ alert('jartto');onmessage = e => { const message = e.data; console.log(`[De Main] : ${message}`); if(message.indexOf('good') > - 1) { postMessage('Merci pour votre soutien' }};À ce moment-là, l'exécution signalera :
En effet : le contexte dans lequel worker.js est exécuté est différent du contexte dans lequel HTML de la page principale est exécuté. L'objet de niveau supérieur n'est pas Window , le contexte global d'exécution woker.js , mais WorkerGlobalScope . Expliquons-nous en détail.
2. Le transfert de données entre workers et le thread principal s'effectue via un tel mécanisme de message : les deux parties utilisent la méthode postMessage() pour envoyer leurs propres messages et utilisent le gestionnaire d'événements onmessage pour répondre au message (le message est inclus dans l'attribut data de l'événement Message ).
Dans ce processus, les données ne sont pas partagées mais copiées.
3. Même restriction d'origine
Le fichier script affecté Worker doit avoir la même origine que le fichier script du thread principal.
4. Restrictions de fichiers
Le thread Worker ne peut pas lire les fichiers locaux, c'est-à-dire qu'il ne peut pas ouvrir le système de fichiers local （file://） . Le script qu'il charge doit provenir du serveur.
5. Fichiers locaux non autorisés
Erreur de sécurité non interceptée : échec de la création d'un travailleur :
script sur '(chemin)/worker.js'
n'est pas accessible depuis l'origine 'null'.
Chrome ne vous permet pas de charger des Web Workers lors de l'exécution de scripts à partir d'un fichier local.
Alors comment le résoudre ? Nous pouvons démarrer un serveur local. Il est recommandé d'utiliser http-server , qui est simple et facile à utiliser.
6. Politique de sécurité du contenu
worker possède son propre contexte d'exécution, distinct de l'objet document qui l'a créé. De manière générale, worker n'est pas limité par la politique de sécurité du contenu document (ou worker parent) qui l'a créé.
Prenons un exemple, en supposant qu'un document possède la déclaration d'en-tête suivante :
Politique de sécurité du contenu : script-src 'self'
Une partie du but de cette déclaration est d'interdire au code de script qu'elle contient d'utiliser la méthode eval() . Cependant, si le code du script crée un worker , le code exécuté dans le contexte worker peut utiliser eval() .
Afin de spécifier un CSP pour un travailleur, la demande d'envoi du code du travailleur doit elle-même être accompagnée d'un CSP.
La seule exception est que si la source du script worker est un identifiant globalement unique (par exemple, son URL spécifie un schéma de données ou blob ), worker héritera document ou du CSP worker qui l'a créé.
A propos, on peut trouver la documentation sur MDN :
1. self :
Nous pouvons utiliser la propriété self de WorkerGlobalScope pour obtenir une référence à l'objet lui-même.
2. location :
L'attribut location renvoie WorkerLocation associé au thread lors de sa création. Il représente l' URL absolue de la ressource de script utilisée pour initialiser le thread de travail. Cet emplacement de ressource URL ne changera pas même si la page est redirigée plusieurs fois.
3. close :
Fermez le fil de discussion actuel, comme pour terminate .
4. caches :
Le contexte actuel dispose CacheStorage pour garantir la disponibilité hors ligne et la réponse à la demande peut être personnalisée.
5. console :
Prise en charge de la syntaxe console .
6. importScripts
Nous pouvons charger des fonctions de bibliothèque dans worker via url via importScripts() .
7. XMLHttpRequest
Avec lui, des requêtes Ajax peuvent être effectuées.
8. Vous pouvez utiliser :
Il existe de nombreuses API qui peuvent être utilisées, je ne donnerai donc pas d’exemples un par un ici.
Lorsqu'un worker rencontre une erreur en cours d'exécution, son gestionnaire d'événements onerror sera appelé. Il recevra un événement nommé error qui étend l’interface ErrorEvent . L'événement ne bouillonne pas et peut être annulé.
Pour empêcher le déclenchement de l'action par défaut, le travailleur peut appeler la méthode PreventDefault() de l'événement d'erreur.
Nous utilisons généralement les trois informations clés suivantes pour les événements d'erreur :
work.onerror = function(error) { console.log(error.message); throw error;};Ce qui précède représente l’intégralité du contenu de cet article. J’espère qu’il sera utile à l’étude de chacun. J’espère également que tout le monde soutiendra le réseau VeVb Wulin.