Некоторые обновления:
Мы не делаем в приложении ничего, кроме прослушивания событий и использования привязок ... то есть никаких ChangeWatchers, ручного опроса ... просто ожидание событий. Мы все время подключаемся к FMS, поэтому есть некоторые накладные расходы, но они минимальны. Привязки не являются суперэффективными во Flex, и мы обнаружили, что нецелесообразно добавлять ключевое слово метаданных [Bindable] непосредственно в классы (в больших объемах, с большим количеством классов). Мы этого не делаем, но это один из способов повысить производительность вашего приложения. Если вы используете [Bindable (event = "usersUpdated")], тогда у вас есть контроль над привязкой, и она будет срабатывать только тогда, когда вы отправляете событие (new Event ("usersUpdated")) из функции в классе, т.е. сеттер для «пользователей».
Любой, кто использовал System.gc () в Flex или AIR, скажет вам, что сборка мусора в Flex - это шутка. Это частично реализованная функция, и никто не доверяет ей. Для этого тоже есть свои приемы ... позвоните дважды, подождите кадр, позвоните снова. Это может очистить ваши старые объекты, но не скрещивать пальцы ... Flex делает то, что хочет.
Также используйте временные объекты, чтобы уменьшить количество привязок. Вместо ...
myUser.location = new Location ();
myUser.location.state = "CO";
myUser.location.city = "Денвер";
сделать ...
var tempLoc: Location = new Location ();
tempLoc.state = "CO";
tempLoc.city = "Денвер";
myUser.location = tempLoc;
Первый запускает 3 привязки ко всему, что привязано к локации. *, В то время как последний должен запускать только 1 привязку (на самом деле она обычно дополнительная из-за способа, которым Flex ее обрабатывает).
Привязки не убьют ваше приложение, пока их не будет много в визуально насыщенном приложении ... кажется, что связывание и рендеринг - самые медленные задания Flex.
Еще одна интересная вещь: создайте новое приложение Flex3 в Flex Builder и запустите его в браузере. Наши тесты показали, что на MacBookPro процессор остается на уровне 8-10% (когда приложение бездействует, а окно браузера скрыто). Наше приложение теперь стабильно работает на уровне ~ 20%, и, хотя оно достигает пика для обработки изменений вида и т. П., Оно всегда возвращается к уровню, близкому к 20%. Наша первоначальная забота заключалась в том, что произошла утечка памяти или что-то еще, что приводило к очень высокой загрузке ЦП и оставлению зависания примерно на 40-50% (опять же, на MBP ... все относительно этой машины). Мы удалили все ссылки на Degrafa и, хотя мы заметили значительное повышение производительности, это не объясняло всего. Хотя пустое приложение Flex было поучительным - само Flex постоянно загружает 8-10% ЦП, даже в режиме ожидания.
Еще одна находка ... при использовании Mate будьте осторожны, как вы справляетесь с переключением видов. Легко иметь доступные ресурсы и просто скрывать и отключать их, когда они не используются, с помощью инжектора и привязки в MXML, но Flex не очень умен, когда дело доходит до сокрытия / отключения вещей. Лучше всего создавать представления на лету и уничтожать их, когда они будут готовы. Несмотря на то, что первоначальное создание может занять больше времени и будет больше времени ожидания между представлениями, используйте некоторую магию отображения (индикатор выполнения, вращающийся диск и т. Д.), Чтобы указать, что представление переключается, подождите, пока creationComplete в представлении, а затем исчезнуть в нем.
Кроме того, держитесь подальше от ViewStack для визуально насыщенных приложений. Управляйте своим собственным стеком.
До сих пор в этой теме обсуждались основные проблемы с производительностью, характерные для любого языка, но во многих отношениях Flex - особенный маленький мальчик («особенный» не всегда считается положительным моментом). Есть бесчисленное количество подводных камней, потому что оно построено на очень визуальной платформе, но построено для RIA, поэтому, хотя Flash Player может оптимизировать видео, анимацию и т. Д., Он не оптимизирует приложение Flex. Не ожидайте, что приложения Flex будут работать так же, как приложения Flash. Существует также большая разница между AVM (виртуальной машиной ActionScript) для AS2 и AS3.
Это просто поверхностное представление о проблемах с производительностью и потенциальном выигрыше в приложениях Flex. Это темное искусство, и легко понять, почему.
Код включен, ниндзя.