Desde o lançamento do meu controle de árvore MzTreeView1.0, recebi muitos comentários. Muitos internautas me deram muitas sugestões pertinentes e apontaram muitos bugs e deficiências nesse controle, por isso estou planejando escrever uma nova versão. Árvore, integrando as sugestões de todos na implementação. Tenho escrito uma nova versão da árvore atualmente. A coisa mais importante sobre o controle da árvore é a eficiência. Especialmente quando o número de nós é grande, um modo um pouco menos eficiente derrubará o navegador. a árvore, minha primeira prioridade é melhorar a eficiência, como adicionar suporte para carregamento assíncrono de dados, etc. Além disso, também tenho a ideia de que as linhas verticais da estrutura da árvore são implementadas usando uma folha de estilo (imagem de fundo). A imagem de fundo da folha de estilo só precisa ser carregada uma vez, e agora este modo (usando embora várias imagens <img>) tenham um mecanismo de cache, ainda é possível solicitar ao servidor uma vez para cada imagem pequena, então pensei em como seria bom seria usar uma folha de estilo para conseguir isso. O código é simplificado, a estrutura é clara e o efeito é ótimo, mas depois de quase uma semana de testes, minha ideia falhou completamente. a folha de estilo é muito pobre. A nova ideia não pôde ser concretizada e fiquei um pouco frustrado, mas achei que deveria compartilhar os resultados do teste com todos.
Aqui vou explicar as linhas verticais na forma da árvore. Existem ┌ ├ └ │ no lado esquerdo da árvore. Essas linhas verticais representam os níveis da árvore. tipo de uso A folha de estilo é implementada usando código como <div class="l2"></div>, e a folha de estilo é responsável por preencher a imagem de fundo.
#mtvroot div td{largura:20px;altura:20px;}
#mtvroot .l0{background:url(line0.gif) centro sem repetição}
#mtvroot .l1{background:url(line1.gif) centro sem repetição}
#mtvroot .l2{background:url(line2.gif) centro sem repetição}
#mtvroot .l3{background:url(line3.gif) centro sem repetição}
#mtvroot .l4{background:url(line4.gif) centro sem repetição}
#mtvroot .ll{background:url(line5.gif) centro sem repetição}
#mtvroot .pm0{background:url(plus0.gif) centro sem repetição}
#mtvroot .pm1{background:url(plus1.gif) centro sem repetição}
#mtvroot .pm2{background:url(plus2.gif) centro sem repetição}
#mtvroot .pm3{background:url(plus3.gif) centro sem repetição}
#mtvroot .expand .pm0{background:url(minus0.gif) centro sem repetição}
#mtvroot .expand .pm1{background:url(minus1.gif) centro sem repetição}
#mtvroot .expand .pm2{background:url(minus2.gif) centro sem repetição}
#mtvroot .expand .pm3{background:url(minus3.gif) no-repeat center}
O CSS acima é um fragmento do estilo que gerei dinamicamente no script que publiquei para ajudar na explicação mais tarde. Depois de usar a folha de estilo, ela ficou realmente simplificada e a geração de cada nó foi rápida o suficiente. No entanto, descobri que quando o número de nós da minha árvore atingiu, por exemplo, 300-500 nós, a eficiência da geração de nós não teve impacto. , mas sempre A expansão/redução de um nó é muito lenta, demorando mais do que alguns segundos ou até 10 segundos, e o uso da CPU durante esse período é de 100%. Para explicar, a expansão/contração da árvore é obtida definindo style.display = none|block do nó pai. A configuração do meu computador é: memória AMD2800+ 1GDDR400, a configuração não é ruim.
Minha primeira reação foi: Usar muitos <table>s afetou a eficiência? Porque eu uso uma <table> para cada nó, mas substituí a <table> por <div>, <span>, etc., mas não há melhoria na eficiência, o que significa que o problema de 100% de uso da CPU não é um problema de tags HTML, então o problema restante é o uso de folhas de estilo aqui.
Tomando como exemplo a quantidade de 500 nós, haverá cerca de 2.000 pequenas imagens empilhadas no lado esquerdo do 1.0. Nesse caso, haverá um grande problema quando o navegador estiver configurado para não armazenar em cache localmente. É preciso muito tempo e recursos do servidor para carregar essas muitas imagens pequenas, então tenho esta nova folha de estilos. A solução agora é usar. o método da folha de estilo, o que significa que existem cerca de 2.000 locais onde as folhas de estilo são necessárias para renderizar imagens de fundo. Testei várias situações e comparei com o código da versão 1.0 e cheguei à conclusão que a taxa de uso da CPU é muito alta. O único motivo é a demorada renderização. A verificação também é muito simples. Removi a parte #mtvroot no lado esquerdo da folha de estilos acima, o que significa remover a relação de dependência da folha de estilos. Os resultados do teste descobriram que a eficiência melhorou muito, mas o consumo de tempo. ainda é considerável, 3-5 segundos.
Além disso, mudei para navegadores diferentes e os resultados do teste também são diferentes. O mais nojento é no IE. Por exemplo, se eu tiver 500 nós filhos em um determinado nó, irei fechá-lo (CPU 100%, espere 3. -5 segundos), ou seja, display="none". Neste momento, se eu recolher o nó pai deste nó (este nó não tem outros nós irmãos, ou seja, seu nó pai tem apenas um nó filho como este) , é lógico que há apenas um nó, o colapso deveria ser algo imediato, mas o resultado não é. O resultado é CPU 100% por 3-5 segundos. o objeto HTML está oculto por display = "none", seu pai. Quando qualquer operação é executada no nível, o IE irá renderizar novamente esses objetos ocultos usando folhas de estilo. Eu realmente não entendo o que os desenvolvedores do IE estavam pensando.
Fui ao FIREFOX para testá-lo novamente. Quando estiver dobrado (display=none), posso ter certeza que o FF não consumirá mais energia ao lidar com objetos ocultos. Claro, todos os navegadores são iguais quando expandidos: 3-5 segundos de CPU 100%, mas o FF é um pouco mais rápido.
Através dos fenômenos acima, cheguei à conclusão: as folhas de estilo não são eficientes ao renderizar dinamicamente quando o contêiner pai detecta uma mudança de estado, isso fará com que as folhas de estilo de todos os seus objetos descendentes sejam renderizadas novamente; Os objetos noneHidden não serão renderizados novamente, mas o IE sim.
Então, por que esse problema de eficiência de renderização de folhas de estilo não foi descoberto antes? Ei, quando você cria páginas da web, raramente chega a tais extremos. Existem milhares de imagens de fundo em uma página que requerem folhas de estilo para renderizar imagens de fundo. Normalmente, existem apenas alguns lugares ou dezenas de lugares, então você não pode sentir a eficiência da renderização, nem a diferença entre os diferentes navegadores nesse aspecto. No entanto, ao criar controles como árvores, você definitivamente encontrará vários problemas extremos, como grandes matrizes de dados, o número de objetos HTML gerados, etc. A diferença na eficiência de renderização é apenas quando escrevo scripts JS. encontrado. Hoje estou compartilhando o resultado deste teste na esperança de que seja útil para todos ao escrever programas no futuro e para considerá-lo ao fazer o design.
Por fim, obrigado a todos pela afirmação e apoio ao controle que escrevi, obrigado!