Desde el lanzamiento de mi control de árbol MzTreeView1.0, he recibido muchos comentarios y muchos internautas me han dado muchas sugerencias pertinentes y han señalado muchos errores y deficiencias en este control, por lo que planeo escribir una nueva versión. Árbol, integrando las sugerencias de todos en la implementación. He estado escribiendo una nueva versión del árbol estos días. Lo más importante del control del árbol es la eficiencia, especialmente cuando la cantidad de nodos es grande, un modo ligeramente menos eficiente hará que el navegador se caiga. En el árbol, mi primera prioridad es mejorar la eficiencia, como agregar soporte para la carga de datos asincrónica, etc. Además, también tengo la idea de que las líneas verticales de la estructura del árbol se implementan mediante una hoja de estilo (imagen de fondo). La imagen de fondo de la hoja de estilo solo necesita cargarse una vez, y ahora este modo (usando Aunque múltiples <img>) imágenes tienen un mecanismo de almacenamiento en caché, todavía es posible solicitar al servidor una vez para cada imagen pequeña, así que pensé en lo bueno que es. Sería usar una hoja de estilo para lograr esto. El código está optimizado, la estructura es clara y el efecto es excelente, pero después de casi una semana de pruebas, mi idea falló por completo. la hoja de estilo es demasiado pobre. La nueva idea no se pudo realizar y me sentí un poco frustrado, pero pensé que debería compartir los resultados de la prueba con todos.
Aquí explicaré las líneas verticales en la forma del árbol. Hay ┌ ├ └ │ en el lado izquierdo del árbol. Estas líneas verticales representan los niveles del árbol. En mi versión 1.0, usé imágenes pequeñas apiladas una por una. tipo de uso La hoja de estilo se implementa usando código como <div class="l2"></div>, y la hoja de estilo es responsable de completar la imagen de fondo.
#mtvroot div td{ancho:20px;alto:20px;}
#mtvroot .l0{fondo:url(line0.gif) centro sin repetición}
#mtvroot .l1{fondo:url(line1.gif) centro sin repetición}
#mtvroot .l2{fondo:url(line2.gif) centro sin repetición}
#mtvroot .l3{fondo:url(line3.gif) centro sin repetición}
#mtvroot .l4{fondo:url(line4.gif) centro sin repetición}
#mtvroot .ll{fondo:url(line5.gif) centro sin repetición}
#mtvroot .pm0{fondo:url(plus0.gif) centro sin repetición}
#mtvroot .pm1{fondo:url(plus1.gif) centro sin repetición}
#mtvroot .pm2{fondo:url(plus2.gif) centro sin repetición}
#mtvroot .pm3{fondo:url(plus3.gif) centro sin repetición}
#mtvroot .expand .pm0{fondo:url(minus0.gif) centro sin repetición}
#mtvroot .expand .pm1{fondo:url(minus1.gif) centro sin repetición}
#mtvroot .expand .pm2{fondo:url(minus2.gif) centro sin repetición}
#mtvroot .expand .pm3{fondo:url(minus3.gif) centro sin repetición}
El CSS anterior es un fragmento del estilo que generé dinámicamente en el script y lo publiqué para ayudar con la explicación más adelante. Después de usar la hoja de estilo, se simplificó mucho y la generación de cada nodo fue lo suficientemente rápida. Sin embargo, descubrí que cuando el número de nodos de mi árbol alcanzó, por ejemplo, 300-500 nodos, la eficiencia de la generación de nodos no tuvo ningún impacto. , pero cada vez La expansión / reducción de un nodo es muy lenta, toma más de unos pocos segundos o incluso 10 segundos, y el uso de la CPU durante este período es del 100%. Para explicar, la expansión/contracción del árbol se logra configurando style.display = none|block del nodo principal. La configuración de mi computadora es: memoria AMD2800+ 1GDDR400, la configuración no está mal.
Mi primera reacción fue: ¿El uso de demasiadas <table> afectó la eficiencia? Porque uso una <table> para cada nodo, pero reemplacé la <table> con <div>, <span>, etc., pero no hay mejora en la eficiencia, lo que significa que el problema del uso del 100% de la CPU no es un problema de etiquetas HTML, entonces el problema restante es el uso de hojas de estilo aquí.
Tomando la cantidad de 500 nodos como ejemplo, habrá alrededor de 2000 imágenes pequeñas apiladas en el lado izquierdo en 1.0. En este caso, habrá un gran problema cuando el navegador esté configurado para no almacenar en caché localmente. Se necesita mucho tiempo y recursos del servidor para cargar tantas imágenes pequeñas, por lo que ahora tengo esta nueva hoja de estilo. el método de la hoja de estilo, lo que significa que hay alrededor de 2000 lugares donde se necesitan hojas de estilo para representar imágenes de fondo. Probé varias situaciones y lo comparé con el código de la versión 1.0 y llegué a la conclusión de que la tasa de uso de la CPU es muy alta. La única razón es el procesamiento que requiere mucho tiempo. La verificación también es muy simple. Eliminé la parte #mtvroot en el lado izquierdo de la hoja de estilo anterior, lo que significa eliminar la relación de dependencia de la hoja de estilo. Los resultados de la prueba encontraron que la eficiencia ha mejorado mucho, pero el consumo de tiempo. Todavía es considerable, 3-5 segundos.
Además, cambié a diferentes navegadores y los resultados de las pruebas también son diferentes. El más desagradable es en IE. Por ejemplo, si tengo 500 nodos secundarios en un determinado nodo, lo cerraré (CPU 100%, espere 3). -5 segundos), es decir, display="none". En este momento, si colapso el nodo principal de este nodo (este nodo no tiene otros nodos hermanos, es decir, su nodo principal solo tiene un nodo secundario similar) Es lógico que solo haya un nodo. El colapso debería ser algo inmediato, pero el resultado no es que la CPU esté al 100% durante 3 a 5 segundos. el objeto HTML está oculto por display="none", su padre. Cuando se realiza cualquier operación en el nivel, IE volverá a representar estos objetos ocultos usando hojas de estilo. Realmente no entiendo qué estaban pensando los desarrolladores de IE.
Fui a FIREFOX para probarlo nuevamente. Cuando está plegado (display=none), puedo estar seguro de que FF ya no consumirá energía al tratar con objetos ocultos. Por supuesto, todos los navegadores son iguales al expandirse: 3-5 segundos de CPU al 100%, pero FF es un poco más rápido.
A través del fenómeno anterior, llegué a la conclusión: las hojas de estilo no son eficientes cuando se renderizan dinámicamente; cuando el contenedor principal detecta un cambio de estado, hará que las hojas de estilo de todos sus objetos descendientes se vuelvan a renderizar; noneLos objetos ocultos no se volverán a representar, pero IE sí.
Entonces, ¿por qué no se ha descubierto antes este problema de eficiencia de representación de hojas de estilo? Oye, cuando creas páginas web, rara vez llegas a tales extremos. Hay miles de imágenes de fondo en una página que requieren hojas de estilo para representar las imágenes de fondo. Por lo general, solo hay unos pocos lugares o docenas de lugares, por lo que no puede sentir la eficiencia del renderizado ni la diferencia entre diferentes navegadores a este respecto. Sin embargo, al crear controles como árboles, definitivamente encontrará varios problemas extremos, como grandes matrices de datos, la cantidad de objetos HTML generados, etc. La diferencia en la eficiencia de representación es solo uno de los problemas cuando escribo scripts JS. encontrado. Hoy comparto el resultado de esta prueba con la esperanza de que sea útil para todos cuando escriban programas en el futuro y lo consideren al diseñar.
Finalmente, gracias a todos por su afirmación y apoyo al control que escribí, ¡gracias!