MzTreeView1.0 ツリー コントロールのリリース以来、多くのネチズンから多くの適切な提案をいただき、このコントロールの多くのバグや欠点を指摘していただいたので、新しいバージョンを作成する予定です。ツリー、みんなの提案を実装に統合します。最近、ツリー コントロールで最も重要なことは効率です。特にノードの数が多い場合、新しいバージョンでは効率が若干低下します。ツリーに関しては、非同期データロードのサポートなどを追加するなど、効率を高めることを最優先に考えています。また、ツリー構造の縦線をスタイルシート (背景画像) を使用して実装するというアイデアもあります。スタイルシートの背景画像は 1 回ロードするだけで済みます。このモード (複数の <img> を使用する) 画像にはキャッシュ メカニズムが備わっていますが、小さな画像ごとにサーバーに 1 回リクエストすることも可能です。これを実現するには、スタイル シートを使用する必要があります。コードは合理化され、構造は明確で、効果は優れていますが、1 週間近くテストした結果、私の考えは完全に失敗しました。スタイルシートが悪すぎます。新しいアイデアは実現できず、少し悔しい思いをしましたが、テスト結果を皆さんに共有しておこうと思いました。
ここでツリー形状の縦線について説明します。 ツリーの左側にある ┌ § │ が、私のバージョン 1.0 では、小さな画像を 1 つずつ重ねて表示していました。使用の種類 スタイル シートは <div class="l2"></div> のようなコードを使用して実装され、スタイル シートは背景画像を埋める役割を果たします。
#mtvroot div td{幅:20px;高さ:20px;}
#mtvroot .l0{background:url(line0.gif) ノーリピートセンター}
#mtvroot .l1{background:url(line1.gif) ノーリピートセンター}
#mtvroot .l2{background:url(line2.gif) ノーリピートセンター}
#mtvroot .l3{background:url(line3.gif) ノーリピートセンター}
#mtvroot .l4{background:url(line4.gif) ノーリピートセンター}
#mtvroot .ll{background:url(line5.gif) ノーリピートセンター}
#mtvroot .pm0{background:url(plus0.gif) ノーリピートセンター}
#mtvroot .pm1{background:url(plus1.gif) ノーリピートセンター}
#mtvroot .pm2{background:url(plus2.gif) ノーリピート センター}
#mtvroot .pm3{background:url(plus3.gif) ノーリピートセンター}
#mtvroot .expand .pm0{background:url(minus0.gif) ノーリピートセンター}
#mtvroot .expand .pm1{background:url(minus1.gif) ノーリピートセンター}
#mtvroot .expand .pm2{background:url(minus2.gif) ノーリピート センター}
#mtvroot .expand .pm3{background:url(minus3.gif) no-repeat center}
上記の CSS は、スクリプト内で動的に生成したスタイルの一部であり、後の説明を助けるために投稿しました。スタイル シートを使用した後は、非常に合理化され、各ノードの生成が十分に高速になりました。しかし、ツリー ノードの数が、たとえば 300 ～ 500 ノードに達すると、ノード生成の効率が影響を受けなくなることがわかりました。ただし、毎回 ノードの拡張/縮小は非常に遅く、数秒、場合によっては 10 秒以上かかり、この間の CPU 使用率は 100% になります。説明すると、ツリーの拡大/縮小は、親ノードの style.display = none|block を設定することで実現されます。私のコンピュータの構成は次のとおりです: AMD2800+ 1GDDR400 メモリ、構成は悪くありません。
私の最初の反応は、「<table> の使用が多すぎると効率に影響が出るのでしょうか?」というものでした。各ノードに <table> を使用しているため、<table> を <div>、<span> などに置き換えましたが、効率は向上しません。つまり、CPU 使用率 100% の問題は発生しません。 HTML タグの問題、そして残りの問題はここでのスタイルシートの使用です。
500 ノードの量を例に取ると、1.0 では左側に約 2,000 枚の小さな画像が積み上げられます。この場合、ブラウザがローカルにキャッシュしないように設定されていると、これらの多数の小さな画像を読み込むのに多くの時間とサーバー リソースが必要になるため、この新しいスタイル シートを使用することで大きな問題が発生します。これは、背景画像をレンダリングするためにスタイル シートが必要な場所が約 2,000 個あることを意味します。さまざまな状況をテストし、バージョン 1.0 のコードと比較した結果、CPU 使用率が非常に高いのはレンダリングに時間がかかるだけであるという結論に達しました。検証も非常に簡単で、上記のスタイルシートの左側にある #mtvroot の部分を削除しました。これは、スタイルシートの依存関係を削除することを意味します。テストの結果、効率は大幅に向上しましたが、時間がかかりました。まだかなりの、3〜5秒です。
さらに、別のブラウザに変更すると、テスト結果も異なります。たとえば、特定のノードに 500 個の子ノードがある場合、それを閉じます (CPU 100%、待機 3)。 -5 秒)、つまり、display = "none"ノードが 1 つしかないのは当然ですが、崩壊はすぐに起こるはずですが、結果はそうではなく、3 ～ 5 秒間 CPU が 100% になるということです。つまり、たとえそうであったとしてもです。 HTML オブジェクトはその親である display="none" によって隠されています。そのレベルで何らかの操作が実行されると、IE はスタイル シートを使用してこれらの非表示のオブジェクトを再レンダリングします。IE の開発者が何を考えていたのか、本当に理解できません。
FIREFOX に行って再度テストしてみましたが、折りたたむと (display=none)、隠れたオブジェクトを処理するときに FF がエネルギーを消費しなくなることがわかりました。もちろん、拡張時はどのブラウザも同じで、CPU 100% で 3 ～ 5 秒ですが、FF の方がわずかに高速です。
上記の現象を通じて、私は次の結論に達しました。動的にレンダリングする場合、スタイル シートは効率的ではありません。親コンテナが状態の変化を検出すると、そのすべての子孫オブジェクトのスタイル シートが再レンダリングされます。 noneHidden オブジェクトは再レンダリングされませんが、IE では再レンダリングされます。
では、なぜこのスタイルシートのレンダリング効率の問題がこれまで発見されなかったのでしょうか? Web ページを作成する場合、そのような極端な作業を行うことはほとんどありません。ページには、背景画像をレンダリングするためにスタイル シートを必要とする背景画像が何千もあります。通常、数か所または数十か所しかないため、レンダリングの効率を感じることができず、この点でのブラウザ間の違いも感じられません。ただし、ツリーなどのコントロールを作成すると、データ配列が大きくなったり、生成される HTML オブジェクトの数が増えたりするなど、さまざまな極端な問題が必ず発生します。レンダリング効率の違いは、JS スクリプトを作成する場合にのみ発生します。遭遇した。今日は皆さんが今後プログラムを書く際、また設計をする際の参考になればと思い、このテスト結果をシェアさせていただきます。
最後に、私が書いたコントロールを肯定し、サポートしてくださった皆様に感謝します。ありがとう!