Производительность Flex Rendering

Question

Недавно я обнаружил, что есть несколько вещей, которые можно сделать для массового замедления приложения Flex. Одной из таких вещей является использование множества вложенных контейнеров макетов. Другая вещь, которая очень проблематична - это использование партий относительного позиционирования и размеров.

Я понимаю, что для отображения элементов макета необходимо выполнить очень большое количество вычислений. Я не понимаю, почему рендеринг выполняется постоянно. При определенной сложности в вашей компоновке ваша загрузка ЦП постоянно составляет 100%, даже если в компоновке нет никаких изменений.

Почему это? И что я могу с этим сделать (не переделывая весь макет)?

Большое спасибо!

Answer 1

Это правда, что вложенные контейнеры замедляют работу, но я пока не смог довести загрузку процессора до 100%. Фреймворк должен пересчитывать макет компонента только после вызова его invalidateDisplayList (). Вызов этого планирует расписание updateDisplayList, в котором рассчитывается макет контейнера. Следовательно, списки отображения дочерних элементов компонента также становятся недействительными.

Помимо самостоятельного выполнения, displayList может быть аннулирован платформой по ряду причин. Например, он всегда становится недействительным после invalidateProperties (). Может случиться так, что у вас есть что-то, что постоянно делает недействительным список отображения какого-либо высокоуровневого контейнера, передавая его потом его потомкам.

Есть ли у вас код для обмена? А какую систему вы используете?

Answer 2

Любое другое решение, кроме рефакторинга вашего макета и не использования большого количества вложенных элементов, означает изменение способа работы Adobe Framework, и вы не хотите этого делать! Хотя мое предложение может быть болезненным, измените компоненты представления, по возможности используйте абсолютный размер и расположение, не вкладывайте слишком много элементов. Причина «бутылочного горлышка» с вложенными компонентами заключается в том, что недействительные функции идут 2 путями: сначала по дереву от измененного компонента к корню, а затем от корня ко всем его вложенным элементам, что и занимает ваш процессор.

Answer 3

Наконец я выяснил, в чем именно проблема с нашим приложением!

Проблема была не в том, что мы использовали много вложенных контейнеров макетов. Я обнаружил, что существует сторонний компонент, который мы используем, который присоединяет прослушиватель событий к событию ENTER_FRAME-Event. К сожалению, этот компонент не закрывается должным образом, поэтому слушатель событий никогда не удаляется. Единственное, что вызывает это событие, - это вызов invalidateDisplayList (). Я обнаружил, что событие ENTER_FRAME-Event происходит очень часто (я до сих пор не знаю, почему именно это происходит), и из-за этого весь макет пересчитывается снова и снова. Из-за вложенной структуры наших макетов это очень трудоемкий процесс, и поэтому процессор сильно загружен!

Я мог бы решить эту проблему, добавив дополнительный компонент в компонент, который должным образом удаляет прослушиватели событий, если они больше не нужны. Результатом этого стало то, что приложению теперь не требуется питания процессора в режиме ожидания. Ура !!