Depuis la sortie de mon contrôle d'arborescence MzTreeView1.0, j'ai reçu de nombreux retours de nombreux internautes m'ont fait beaucoup de suggestions pertinentes et ont signalé de nombreux bugs et lacunes dans ce contrôle, j'envisage donc d'écrire une nouvelle version. Tree, intégrant les suggestions de chacun dans la mise en œuvre. J'écris une nouvelle version de l'arborescence ces jours-ci. La chose la plus importante à propos du contrôle de l'arborescence est l'efficacité. Surtout lorsque le nombre de nœuds est important, un mode légèrement moins efficace fera tomber le navigateur. l'arborescence, ma première priorité est d'améliorer l'efficacité, comme l'ajout de la prise en charge du chargement de données asynchrone, etc. De plus, j'ai également l'idée que les lignes verticales de la structure arborescente sont implémentées à l'aide d'une feuille de style (image d'arrière-plan). L'image d'arrière-plan de la feuille de style ne doit être chargée qu'une seule fois, et maintenant ce mode (en utilisant Bien que plusieurs images <img> aient un mécanisme de mise en cache, il est toujours possible de demander au serveur une fois pour chaque petite image, alors j'ai pensé à quel point c'était bon. serait d'utiliser une feuille de style pour y parvenir. Le code est simplifié, la structure est claire et l'effet est génial, mais après près d'une semaine de tests, mon idée a complètement échoué. la feuille de style est trop mauvaise. La nouvelle idée n’a pas pu être réalisée et je me suis senti un peu frustré, mais j’ai pensé que je devrais partager les résultats du test avec tout le monde.
Ici, je vais vous expliquer les lignes verticales en forme d'arbre. Il y a ┌ ├ └ │ sur le côté gauche de l'arbre. Dans ma version 1.0, j'ai utilisé de petites images empilées une par une. type d'utilisation La feuille de style est implémentée à l'aide d'un code tel que <div class="l2"></div>, et la feuille de style est responsable du remplissage de l'image d'arrière-plan.
#mtvroot div td{largeur:20px;hauteur:20px;}
#mtvroot .l0{background:url(line0.gif) centre sans répétition}
#mtvroot .l1{background:url(line1.gif) centre sans répétition}
#mtvroot .l2{background:url(line2.gif) centre sans répétition}
#mtvroot .l3{background:url(line3.gif) centre sans répétition}
#mtvroot .l4{background:url(line4.gif) centre sans répétition}
#mtvroot .ll{background:url(line5.gif) centre sans répétition}
#mtvroot .pm0{background:url(plus0.gif) centre sans répétition}
#mtvroot .pm1{background:url(plus1.gif) centre sans répétition}
#mtvroot .pm2{background:url(plus2.gif) centre sans répétition}
#mtvroot .pm3{background:url(plus3.gif) centre sans répétition}
#mtvroot .expand .pm0{background:url(minus0.gif) centre sans répétition}
#mtvroot .expand .pm1{background:url(minus1.gif) centre sans répétition}
#mtvroot .expand .pm2{background:url(minus2.gif) centre sans répétition}
#mtvroot .expand .pm3{background:url(minus3.gif) no-repeat center}
Le CSS ci-dessus est un fragment du style que j'ai généré dynamiquement dans le script que je l'ai publié pour faciliter l'explication plus tard. Après avoir utilisé la feuille de style, elle a été vraiment simplifiée et la génération de chaque nœud était assez rapide. Cependant, j'ai constaté que lorsque le nombre de nœuds de mon arborescence atteignait, par exemple, 300 à 500 nœuds, l'efficacité de la génération de nœuds n'avait aucun impact. , mais à chaque fois L'expansion/rétrécissement d'un nœud est très lente, prenant plus de quelques secondes voire 10 secondes, et l'utilisation du processeur pendant cette période est de 100 %. Pour expliquer, l'expansion/contraction de l'arborescence est obtenue en définissant style.display = none|block du nœud parent. La configuration de mon ordinateur est : Mémoire AMD2800+ 1GDDR400, la configuration n'est pas mauvaise.
Ma première réaction a été : l'utilisation d'un trop grand nombre de <table> affecte-t-elle l'efficacité ? Parce que j'utilise une <table> pour chaque nœud, mais j'ai remplacé la <table> par <div>, <span>, etc., mais il n'y a aucune amélioration de l'efficacité, ce qui signifie que le problème de l'utilisation à 100 % du processeur n'est pas un problème de balises HTML, alors le problème restant est l'utilisation des feuilles de style ici.
En prenant comme exemple le nombre de 500 nœuds, il y aura environ 2 000 petites images empilées sur le côté gauche dans la version 1.0. Dans ce cas, il y aura un gros problème lorsque le navigateur est configuré pour ne pas mettre en cache localement. Cela prend beaucoup de temps et de ressources serveur pour charger ces nombreuses petites images, j'ai donc cette nouvelle feuille de style à utiliser. la méthode des feuilles de style, ce qui signifie qu'il existe environ 2 000 endroits où des feuilles de style sont nécessaires pour restituer les images d'arrière-plan. J'ai testé diverses situations et je l'ai comparé avec le code de la version 1.0 et je suis arrivé à la conclusion que le taux d'utilisation du processeur est si élevé. La seule raison est le rendu fastidieux. La vérification est également très simple. J'ai supprimé la partie #mtvroot sur le côté gauche de la feuille de style ci-dessus, ce qui signifie supprimer la relation de dépendance de la feuille de style. Les résultats des tests ont révélé que l'efficacité s'est beaucoup améliorée, mais la consommation de temps. est encore considérable, 3-5 secondes.
De plus, j'ai changé de navigateur et les résultats des tests sont également différents. Le plus dégoûtant est dans IE. Par exemple, si j'ai 500 nœuds enfants sur un certain nœud, je le fermerai (CPU 100 %, attendez 3). -5 secondes), c'est-à-dire display="none". À ce moment, si je réduis le nœud parent de ce nœud (ce nœud n'a pas d'autres nœuds frères, c'est-à-dire que son nœud parent n'a qu'un seul nœud enfant comme lui) , il va de soi qu'il n'y a qu'un seul nœud, l'effondrement devrait être une chose immédiate, mais le résultat ne l'est pas. Le résultat est un processeur à 100 % pendant 3 à 5 secondes. Cela me rend fou et déprimé. l'objet HTML est masqué par display="none", son parent Lorsqu'une opération est effectuée au niveau, IE restituera ces objets cachés à l'aide de feuilles de style. Je ne comprends vraiment pas ce que pensaient les développeurs d'IE.
Je suis allé sur FIREFOX pour le tester à nouveau. Lorsqu'il est plié (affichage = aucun), je peux être sûr que FF ne consommera plus d'énergie lorsqu'il s'agira d'objets cachés. Bien sûr, tous les navigateurs sont identiques lors de l'expansion : 3 à 5 secondes de CPU à 100 %, mais FF est légèrement plus rapide.
Grâce aux phénomènes ci-dessus, je suis arrivé à la conclusion : les feuilles de style ne sont pas efficaces lors du rendu dynamique ; lorsque le conteneur parent détecte un changement d'état, les feuilles de style de tous ses objets descendants seront restituées ; FireFox traite display= ; Les objets noneHidden ne seront pas restitués mais IE le fera.
Alors pourquoi ce problème d’efficacité du rendu des feuilles de style n’a-t-il pas été découvert auparavant ? Hé, lorsque vous créez des pages Web, vous allez rarement à de tels extrêmes. Il y a des milliers d'images d'arrière-plan dans une page qui nécessitent des feuilles de style pour restituer les images d'arrière-plan. Habituellement, il n'y a que quelques endroits ou des dizaines d'endroits, vous ne pouvez donc pas ressentir l'efficacité du rendu, ni la différence entre les différents navigateurs à cet égard. Cependant, lors de la création de contrôles tels que des arbres, vous rencontrerez certainement divers problèmes extrêmes, tels que de grands tableaux de données, le nombre d'objets HTML générés, etc. La différence dans l'efficacité du rendu n'est que lorsque j'écris des scripts JS. Ce n'est qu'un des problèmes. rencontrés. Aujourd'hui, je partage ce résultat de test dans l'espoir qu'il sera utile à tout le monde lors de l'écriture de programmes à l'avenir et qu'il sera pris en compte lors de la conception.
Enfin, merci à tous pour votre affirmation et votre soutien au contrôle que j'ai écrit, merci !