Une brève analyse du mécanisme de thread setTimeou

Lorsque je lisais le livre High Performance JavaScript, j'ai vu cette phrase :

Placer les scripts en haut de la page de cette manière entraîne généralement un retard notable, souvent sous la forme d'un blanc vide page, avant même que l'utilisateur puisse commencer à lire ou à interagir avec la page

s'explique comme suit :

Placer le script dans l'en-tête entraînera un retard important, généralement comme suit : la page s'ouvre vide et l'utilisateur ne peut pas la lire ni interagir avec elle.

Ma compréhension est la suivante : en plaçant js dans la tête, le chargement et l'exécution de js entraînent un retard dans le rendu des pages. Si js est placé à la fin, puisque le rendu de la page précède le chargement ou l'exécution de js, il peut être présenté à l'utilisateur en premier sans être affecté par le blocage de js.

Afin de vérifier, l'expérience suivante a été réalisée :

<p>hello world</p><script type="text/javascript">　　
    function f() {　　　　
    var t = +new Date();

　　　　//运行5秒　　　　while(true) {
　　　　　　if(+new Date() - t > 5) {
　　　　　　　　break;
　　　　　　}
　　　　}
　　}
　　f();　　// ①</script>

Les résultats expérimentaux sont intéressants : hello world a attendu 5 secondes avant de sortir.

Vérification approfondie : introduisez le script ci-dessus sous forme de lien externe js ou chargez-le dynamiquement. Le résultat est toujours sorti après 5 secondes d'attente.

Cela signifie que le rendu de la page doit avoir lieu une fois que tous les js sont chargés et exécutés. Il y a quelque chose qui ne va pas dans le paragraphe ci-dessus.

Est-ce à dire que tant que js n'implique pas d'opérations DOM, le placer en tête et en queue aura le même effet ? Bien sûr que non. Par exemple, lorsqu'il y a des images ou d'autres ressources dans le code HTML, si js est placé en tête, le téléchargement de l'image doit attendre que js soit terminé avant de démarrer. Cependant, si js est placé en queue, puisque le code HTML contient des images ou d'autres ressources. Le téléchargement de l'image ne bloque pas l'exécution de js, vous pouvez réaliser un téléchargement parallèle d'images et l'exécution de js.

Est-ce la fin du problème ? Bien sûr que non. Une partie très importante du travail front-end est l'optimisation des performances. Comment optimiser les js ci-dessus ? J'ai donc pensé à setTimeout.

setTimeout est utilisé pour retarder l'exécution du code js. Il a l'avantage de ne pas bloquer l'exécution de js derrière lui. Je suppose donc que setTimeout ne bloquera pas non plus le rendu de la page.

Option 1 : Remplacez la partie ① ci-dessus par :

 setTimeout(f,0);

Du coup, hello world doit encore attendre 5 secondes avant de sortir. Mais si vous faites attention, vous constaterez que le symbole de chargement sur l'étiquette du navigateur est manquant.

Continuez à deviner, 0 est trop petit, ce qui fait que le navigateur découvre qu'il n'y a pas de code js derrière setTimeout et exécute immédiatement le contenu dans setTimeout, c'est-à-dire la fonction f. Alors changez le temps à 100 ms.

Option 2 : Remplacez la partie ① ci-dessus par :

setTimeout(f, 100);

En conséquence, bonjour tout le monde apparaît instantanément. Un peu excité. Les étudiants intéressés peuvent continuer les tests. À ce stade, vous constaterez qu'il y aura une valeur critique (différents navigateurs ont des valeurs critiques différentes). Sinon, hello world apparaîtra instantanément. , vous devez attendre. Il apparaîtra une fois la fonction à l'intérieur terminée.

C'est incroyable, pourquoi cela arrive-t-il ? Pour répondre à cette question, il faut étudier le mécanisme de threading du navigateur.

Nous savons qu'il y a au moins deux threads à l'intérieur du navigateur : le thread qui analyse js et le thread qui restitue l'interface. Ici, nous les appelons temporairement thread JS et thread UI.

Puisque js peut manipuler le DOM, si vous modifiez les attributs de ces éléments lors du rendu de l'interface (c'est-à-dire que le thread JS et le thread UI s'exécutent en même temps), les données de l'élément obtenues avant et après le fil de rendu peut être incohérent. Par conséquent, afin d'éviter des résultats de rendu imprévisibles, le navigateur contrôle le thread JS et le thread UI pour qu'ils s'exécutent de manière synchrone dans une file d'attente.

Retour à la question ci-dessus, lorsque setTimeout est exécuté, un nouveau thread de minuterie sera ouvert. C'est exactement à ce moment-là que le thread JS est en cours d'exécution. Lorsque le thread JS est terminé, il s'avère que setTimeout commence à s'exécuter. immédiatement (c'est-à-dire que le temps est inférieur à la valeur critique ci-dessus), afin d'éviter la mauvaise expérience causée par le retard important de setTimeout causé par le thread d'interface utilisateur qui s'exécute trop longtemps, le navigateur choisit d'attendre l'expiration de setTimeout, et puis exécute le js à l'intérieur. S'il s'avère que setTimeout mettra beaucoup de temps à expirer, afin d'éviter de perdre du temps, le navigateur choisit de passer immédiatement au fil de l'interface utilisateur.

Conclusion : setTimeout peut être utilisé pour traiter du code js chronophage, mais veillez à ne pas définir le deuxième paramètre trop petit, sinon vous verrez la même page blanche. Il est recommandé d'être aux alentours de 100 ms, ce qui peut satisfaire tous les navigateurs. Bien sûr, si vous ne pouvez pas être compatible avec IE, abandonnez setTimeout et les Web Workers seront un bon choix.

En HTML4, les programmes créés par js sont monothread. Les Web Workers sont nouveaux en HTML5 et sont une technologie utilisée pour implémenter le traitement en arrière-plan dans les applications Web. Il est très simple de créer des threads s'exécutant en arrière-plan à l'aide de cette API :

var worker = new Worker('*.js');// 后台线程是不能访问页面或窗口对象的// 但可通过发送消息和接受消息与后台线程传递数据worker.onmessage = function (e) {};
worker.postMessage = function (e) {};

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!