flex: относительный размер и производительность - PullRequest
0 голосов
/ 11 мая 2011

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

Поможет ли это создать временные переменные для а) pcw = parentcontainer.width, pch = parentcontainer.height б) ccw = currentcontainer.width, cch = currentcontainer.height

и ссылки на pcw, pch, ccw и cch при позиционировании. Это поможет?

Также, учитывая, что основная часть позиционирования будет выполняться в mxml, установит эти временные переменные в функции инициализации, разрешит их использование в mxml таким образом, что они изменят размер при изменении размера браузера. Спасибо за указатели

Ответы [ 2 ]

1 голос
/ 11 мая 2011

Я не уверен, используете ли вы термин «модуль» как общий термин для обозначения компонента, или если вы явно ссылаетесь на классы Module класса.

Он нарушает инкапсуляцию, если контейнер знает о своих родителях.Во Flex родитель всегда отвечает за размер своих детей;и ребенок никогда не должен измерять себя.

У вас был такой код для доступа к высоте и ширине родителя:

pcw=parentcontainer.width
parentcontainer.height

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

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

Подходящим способом для определения размера и расположения дочерних элементов компонента является переопределение updateDisplayList () .updateDisplayList () имеет два параметра: unscaledWidth и unscaledHeight;по сути, это высота и ширина компонента.Вы должны определить размер и расположение дочерних элементов компонента на основе этих двух значений.

Конечно, это часто зависит от ActionScript;не MXML.

Ваш основной вопрос, казалось, хотел улучшить производительность.Есть много факторов, влияющих на производительность приложения.Использование ActionScript для макета вместо MXML может быть одним из факторов, который может помочь повысить производительность.Минимизация использования привязки - это еще одна вещь, которая иногда может повысить производительность.

Вы использовали Flex Profiler?Вы прошли через код?Помогают ли эти вещи определить, что именно является проблемой производительности?

1 голос
/ 11 мая 2011

Если ваше приложение не изменит свою форму много , с Flex не должно возникнуть никаких проблем при раскладке, если вы используете надлежащие стандарты оформления / компонентов / макета.

Большая часть проблемы не в Flex, а в коде, который большинство людей добавляют в свое собственное приложение, которое делает всю систему медленной.Обязательно ознакомьтесь с улучшениями производительности Flash (такими как структуры данных, ограничение привязки, правильная архитектура, жизненный цикл объекта и т. Д.).

...