#apache-flex #module
#apache-гибкий #модуль
Вопрос:
Мы создаем гибкий проект и хотели бы, чтобы он отображался быстрее. У нас действительно бывают ситуации, когда мы ссылаемся на свойства размера родительского модуля для определения размера текущих контейнеров модуля, а также на свойства текущего размера модуля для множества атрибутов, включая размер шрифта и положения элементов и размеры.
Поможет ли это создать временные переменные для a) pcw = parentcontainer.width, pch= parentcontainer.height b) ccw= currentcontainer.width, cch= currentcontainer.height
и ссылка на pcw, pch, ccw и cch при выполнении позиционирования. Поможет ли это?
Также, учитывая, что основная часть позиционирования будет выполняться в mxml, позволит ли установка этих промежуточных переменных в функции инициализации использовать их в mxml таким образом, чтобы они изменялись по мере изменения размера браузера. Спасибо за подсказки
Ответ №1:
Я не уверен, используете ли вы термин «Модуль» как общий термин для обозначения компонента, или вы явно ссылаетесь на классы класса Module.
Это нарушает инкапсуляцию, если контейнеру известно о его родителях. В Flex родительский элемент всегда отвечает за определение размера своих дочерних элементов; и дочерний элемент никогда не должен определять размер самого себя.
У вас был подобный код для доступа к высоте и ширине родительского элемента:
pcw=parentcontainer.width
parentcontainer.height
Я не могу представить, как сохранение родительских значений высоты и ширины могло бы ускорить что-либо.
Мне также трудно представить ситуацию, когда полезно знать ширину и высоту родительского контейнера. Часто контейнер имеет более одного дочернего элемента. Важно знать, какой размер имеет компонент для размещения своих дочерних элементов, а не сколько места занимает родительский компонент.
Подходящий способ определения размера и положения дочерних компонентов — переопределить функцию updateDisplayList(). Функция updateDisplayList() имеет два параметра: unscaledWidth и unscaledHeight ; то есть, по сути, высоту и ширину компонента. Вы должны определять размер и позиционировать дочерние компоненты на основе этих двух значений.
Конечно, при этом часто используется ActionScript, а не MXML.
Ваш основной вопрос, похоже, хотел повысить производительность. Существует множество факторов, влияющих на производительность приложения. Использование ActionScript для компоновки вместо MXML может быть одним из факторов, который может помочь повысить производительность. Минимизировать использование при привязке — это еще одна вещь, которая иногда может повысить производительность.
Вы использовали профилировщик Flex? Вы прошли через код? Помогает ли выполнение этих действий вам определить, в чем именно заключается проблема с производительностью?
Комментарии:
1. Спасибо — немного почитаю. Мне дали поверить, что ссылка на родительские контейнеры либо в классе модуля, либо при относительном определении размера / местоположения ссылка на родительские размеры снижала производительность — позвольте мне немного почитать, на что вы указываете. Спасибо
2. @rg1967 Я был бы очень удивлен, если бы доступ к родительскому контейнеру приводил к снижению производительности. Это определенно не инкапсуляция; но я сомневаюсь, что это как-то влияет на производительность. Однако, если вы пытаетесь определить размер дочернего элемента на основе размера его родительского элемента; и у родительского элемента есть логика компоновки для определения размера дочернего элемента, вы можете вызвать бесконечный цикл, который, безусловно, снизит производительность.
Ответ №2:
Если ваше приложение сильно не изменит свою форму, не должно возникнуть никаких проблем с использованием Flex, если вы используете надлежащие стандарты оформления / компонентов / компоновки.
Большая часть проблемы связана не с Flex, а с кодом, который большинство людей добавляют в свои собственные приложения, что замедляет работу всей системы. Убедитесь, что вы ознакомились с улучшениями производительности Flash (такими как структуры данных, ограничивающая привязка, правильная архитектура, жизненный цикл объекта и т.д.).