С момента выпуска моего элемента управления деревом MzTreeView1.0 я получил много отзывов. Многие пользователи сети дали мне много подходящих предложений и указали на множество ошибок и недостатков в этом элементе управления, поэтому я планирую написать новую версию. Дерево, объединяющее предложения каждого в реализацию. Сейчас я пишу новую версию дерева. Самое главное в управлении деревом — это эффективность. Особенно, когда количество узлов велико, немного менее эффективный режим приведет к сбою браузера. дерева, моей первоочередной задачей является повышение эффективности, например, добавление поддержки асинхронной загрузки данных и т. д. Кроме того, у меня также есть идея, что вертикальные линии древовидной структуры реализуются с помощью таблицы стилей (фонового изображения). Фоновое изображение таблицы стилей необходимо загрузить только один раз, и теперь в этом режиме (с использованием нескольких изображений <img>) есть механизм кэширования, все же можно запросить сервер один раз для каждого небольшого изображения, поэтому я подумал, насколько это хорошо Для этого можно было бы использовать таблицу стилей. Код оптимизирован, структура понятна, а эффект отличный, но после почти недели тестирования моя идея полностью провалилась. таблица стилей слишком бедна. Новую идею реализовать не удалось, и я немного расстроился, но подумал, что должен поделиться со всеми результатами испытаний.
Здесь я объясню вертикальные линии в форме дерева. С левой стороны дерева есть ┌ ├ └ │. Эти вертикальные линии обозначают уровни дерева. В моей версии 1.0 я использовал небольшие картинки, сложенные одна за другой. вид использования Таблица стилей реализована с использованием кода типа <div class="l2"></div>, и таблица стилей отвечает за заполнение фонового изображения.
#mtvroot div td {ширина: 20 пикселей; высота: 20 пикселей;}
#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 секунд, а загрузка ЦП в этот период составляет 100%. Поясним: расширение/сжатие дерева достигается установкой style.display = none|block родительского узла. Конфигурация моего компьютера: память AMD2800+1GDDR400, конфигурация неплохая.
Моя первая реакция была: не влияет ли использование слишком большого количества <table> на эффективность? Потому что я использую <table> для каждого узла, но я заменил <table> на <div>, <span> и т. д., но улучшения эффективности нет, а значит, проблема 100% загрузки ЦП не решена. проблема HTML-тегов, то оставшаяся проблема — это использование здесь таблиц стилей.
Если взять в качестве примера количество узлов в 500, то в версии 1.0 слева будет скоплено около 2000 маленьких изображений. В этом случае возникнет большая проблема, если в браузере отключено локальное кэширование. Для загрузки такого количества маленьких изображений требуется много времени и ресурсов сервера, поэтому у меня есть новая таблица стилей. Теперь я могу использовать эту новую таблицу стилей. метод таблицы стилей, что означает, что существует около 2000 мест, где таблицы стилей необходимы для рендеринга фоновых изображений. Я протестировал различные ситуации и сравнил его с кодом версии 1.0 и пришел к выводу, что загрузка процессора настолько высока. Единственная причина — трудоемкий рендеринг. Проверка также очень проста. Я удалил часть #mtvroot в левой части приведенной выше таблицы стилей, что означает удаление зависимости зависимости таблицы стилей. Результаты теста показали, что эффективность значительно улучшилась, но затраты времени. это еще немало, 3-5 секунд.
Кроме того, я перешел на разные браузеры, и результаты тестов тоже разные. Самый отвратительный — в IE. Например, если у меня на определенном узле 500 дочерних узлов, я его закрою (ЦП 100%, ожидание 3). -5 секунд), то есть display="none". В этот момент, если я сверну родительский узел этого узла (у этого узла нет других дочерних узлов, то есть у его родительского узла есть только один такой же дочерний узел) Понятно, что узел всего один, Коллапс должен быть немедленный, но результата нет. Результат - загрузка процессора на 100% в течение 3-5 секунд. Другими словами, даже если это меня сводит с ума. объект HTML скрыт с помощью display="none", его родителя. Когда на уровне выполняется какая-либо операция, IE будет повторно отображать эти скрытые объекты с помощью таблиц стилей. Я действительно не понимаю, о чем думали разработчики IE.
Я зашел в FIREFOX, чтобы проверить его еще раз. Когда он сложен (display=none), я могу быть уверен, что FF больше не будет потреблять энергию при работе со скрытыми объектами. Конечно, все браузеры при расширении одинаковы: 3-5 секунд загрузки ЦП 100%, но FF немного быстрее.
Благодаря вышеупомянутым явлениям я пришел к выводу: таблицы стилей неэффективны при динамическом рендеринге; когда родительский контейнер обнаруживает изменение состояния, это приводит к повторной визуализации таблиц стилей всех его дочерних объектов; Объекты noneHidden не будут повторно отображаться, но IE будет.
Так почему же эта проблема эффективности рендеринга таблиц стилей не была обнаружена раньше? Эй, когда вы создаете веб-страницы, вы редко доходите до таких крайностей. На странице есть тысячи фоновых изображений, для отображения которых требуются таблицы стилей. Обычно мест всего несколько или десятки, поэтому вы не можете ощутить эффективность рендеринга, как и не ощутите разницу между разными браузерами в этом плане. Однако при создании элементов управления типа деревьев вы обязательно столкнетесь с различными экстремальными проблемами, такими как большие массивы данных, количество генерируемых HTML-объектов и т. д. Разница в эффективности рендеринга есть только тогда, когда я пишу JS-скрипты. Это лишь одна из проблем. столкнулся. Сегодня я делюсь этим результатом теста в надежде, что он будет полезен всем при написании программ в будущем и учтет его при проектировании.
Наконец, спасибо всем за ваше одобрение и поддержку написанного мной контроля, спасибо!