Заметное повышение производительности Flex 3 с использованием Canvas против VBox / HBox?

Question

Мне сказали, что при использовании Canvas и HBox или VBox при раскладе положения детей наблюдается увеличение производительности. В результате ряд наших компонентов был переведен на использование Canvas. Однако теперь добавлен код для вычисления положения x и y некоторых дочерних элементов на основе ширины и высоты других дочерних элементов. Стоит ли использовать Canvas для повышения производительности, если необходимо добавить код для определения координат / позиций дочерних элементов? Есть ли лучший метод или метод, который следует практиковать, кроме минимизации количества добавленных компонентов пользовательского интерфейса и определения абсолютного позиционирования?

Answer 1

Существует ряд технологий среднего уровня, одним из которых является использование компонентов типа рендеринга, таких как TileGrid или ItemRenderers, если ваш макет соответствует определенной формуле. Если вы используете формы, попробуйте использовать компонент макета Form вместо пользовательского макета.

Если вам нужно использовать механизм разметки во Flex, способ оптимизировать использование - помнить, что платформа использует определенные методы для увеличения нагрузки на производительность, неукоснительно следуя приведенному ниже списку, последний из которых является наиболее интенсивным по производительности. :

1. абсолютное позиционирование (<Canvas>)
2. относительное положение (<VBox>)
3. позиционирование на основе ограничений (right=0)
4. расширенное позиционирование на основе ограничений (<constraintColumns>)

Использование относительного позиционирования обычно не так уж интенсивно. Если вы обнаружите, что это так, возможно, вы используете слишком много вложенных контейнеров. Посмотрите на свою архитектуру компоновки и постарайтесь выяснить, каким образом ваши объекты могут быть «разложены», и упростите их. Хорошим инструментом для этого является FlexSpy, который позволяет вам анализировать расположение объектов во время выполнения.

Еще одним распространенным узким местом в производительности является то, что ваше приложение пытается выполнить некоторое сокращение числа в то же время, когда ваш графический пользовательский интерфейс пытается ответить на взаимодействие с пользователем. Несмотря на то, что в настоящее время не существует платформ с зелеными потоками, которые бы позволяли вам запускать пользовательский интерфейс и логику в отдельных «потоках», вы можете использовать хорошую архитектурную платформу, такую ​​как Cairngorm или Mate (их много), которая использует Commands вместо прямых методов, поэтому выполнение этой функциональности, которое может занимать циклы обработки, ожидает, пока пользовательский интерфейс не завершит отвечать пользователю.

Answer 2

Несколько вещей, которые вы должны иметь в виду при оптимизации Flex UI:

1. Предотвращение чрезмерного вложения контейнеров. Подумайте об использовании Canvas с абсолютным или основанным на ограничениях позиционированием над множеством элементов HBox / VBox. Однако это не означает, что вы НИКОГДА не должны использовать VBox / HBox. Вы можете смешивать и сочетать, например, используя Canvas в качестве основного контейнера и размещая дочерние блоки внутри них по мере необходимости, просто стараясь избежать слишком большого количества вложений.

2. Правильное использование модели UIComponent в пользовательских компонентах. В частности, используя invalidateProperties (), invalidateSize () и invalidateDisplayList (), чтобы их сопутствующие функции (commitProperties (), measure () и updateDisplayList ()) вызывались в оптимальное время для проигрывателя Flash Player. Дипа отлично говорит об этом здесь:

http://tv.adobe.com/#vi+f15384v1002

Она объясняет, как интенсивное использование схемы аннулирования позволяет Flash Player выполнять ваш код в идеальное время, т. Е. Не в середине обновления экрана. Эти принципы используются всеми компонентами Flex и могут / должны использоваться независимо от используемой платформы.

Answer 3

Чтобы убедиться, что я понимаю:

• Вы слышали, что Canvas может позиционировать детей быстрее, чем [VH] Box
• Canvas делает только абсолютное позиционирование
• Некоторые (многие?) Ваши компоненты имеют абсолютную позицию, поэтому вы переключились на использование Canvas
• Но некоторые из ваших компонентов имеют относительную позицию, поэтому вам нужно написать код для их позиционирования

Это правильно?

В любом случае, предполагая, что я прав (а это может быть не так), первое, что вы хотите сделать, это выбрать работающий интерфейс, который требует наименьшего количества строк кода, а затем решить, достаточно ли он хорош. Вам нужен код с наименьшим количеством строк кода, потому что исследования показали, что существует корреляция между строками кода и количеством ошибок (и вы не хотите ошибок). Вы хотите посмотреть, достаточно ли он хорош, потому что, если он достаточно хорош, вам не нужно ничего делать (если вы делаете , пытаетесь сделать это быстрее, вы совершаете Преждевременная оптимизация ).

Но это, вероятно, не то, что вы хотели услышать:)

Поэтому я также предлагаю, чтобы, если вы хотите придерживаться макета на основе Canvas, вы пытаетесь вставить весь относительно позиционированный контент внутри [VH] Boxes, которые затем абсолютно позиционируются внутри Canvas. Существует большая вероятность, что код, написанный Adobe, работает быстрее, чем код, поэтому вы должны попытаться использовать его в своих интересах.

Но единственный способ узнать наверняка - это попробовать и профилировать .