Почему Flex использует однопоточную модель?

Question

За последние несколько недель я создавал прототип приложения, используя интерфейс Flex, подключенный к интерфейсу J2EE, с помощью blazeDS.

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

Во время некоторых легких тестов производительности стало очевидно, что мне нужно использовать несколько потоков, чтобы гарантировать стабильность интерфейса при получении большого количества обновлений с сервера. Все шло хорошо, пока я не обнаружил, что у flex есть однопоточная модель программирования!

Из быстрого Google выглядит так, как будто существует множество хаков для реализации потокового поведения.

Я уверен, что многие люди сталкивались с подобной проблемой. Могут ли люди дать мне знать:

• Есть ли какие-нибудь хорошие потоки, которые хорошо поддерживаются и т. Д.
• У других технологий RIA, таких как silverlight, такие же проблемы.
• Почему abobe реализовал модель с одним потоком?
• Существуют ли другие приемы, которые я могу использовать для обеспечения стабильности моего интерфейса.

Answer 1

Я видел очень интенсивные типы приложений Flex для настольных компьютеров, которые отлично работают в однопоточной модели Flex. Причина в том, что внутри приложения Flex используют асинхронный сетевой ввод-вывод. Таким образом, пользовательский интерфейс не блокируется, когда вы делаете запросы. Вы можете столкнуться с ограничениями с BlazeDS и, возможно, следует рассмотреть что-то, что использует RTMP (например, LCDS). RTMP - более эффективный протокол для потоковой передачи больших объемов данных клиенту. Также есть способы оптимизировать обработку событий и рендеринг кода на стороне клиента, чтобы не перегружать пользовательский интерфейс. Christophe Coenraets имеет несколько хороших демо-версий таких вещей: http://coenraets.org/blog/?s=trader+desktop

То, что вы пытаетесь сделать, безусловно, возможно с Flex, и есть люди, которые успешно это сделали.

Однако на bugs.adobe.com есть запрос на открытую функцию: https://bugs.adobe.com/jira/browse/ASL-23

Answer 2

Чтобы ответить на ваш вопрос о Silverlight, он на самом деле допускает несколько тад.

Answer 3

Я делаю что-то очень похожее на это, и ограничение не в одном потоке, а в действительности со всеми данными, которые отправляются обратно и пытаются обновить это в режиме реального времени. Дело в том, что вам не нужно в реальном времени, или, по крайней мере, вы можете согнуть то, что на самом деле означает «в реальном времени».

На стороне сервера вместо того, чтобы отправлять данные сразу после предыдущего нажатия, подождите секунду и посмотрите, появятся ли новые обновления. Если это так, вы можете отправить эти обновленные данные. Нет причин немедленно возвращать данные в режиме реального времени, если через миллисекунду вы собираетесь возвращать другое обновление. Я не хочу сказать, что опрос - это путь, который нужно пройти, потому что это не так, но псевдо-опрос или задержанный ответ - это путь. Это похоже на поезд, подъезжающий к станции и просто впускающий одного человека. Гораздо эффективнее остановиться и подождать немного, а потом - 50.

Answer 4

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

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

Даже если ваше приложение Flex по-прежнему испытывало проблемы с обработкой 20–30 обновлений пользовательского интерфейса в секунду после этих оптимизаций, какой человек может иметь смысл изменять данные с такой скоростью? Я полагаю, что обновление интерфейса пользователя один раз в секунду будет достаточным, если полный набор данных будет доступен для расчетов и аналитики.

Answer 5

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

Аналогичным образом, постарайтесь не отправлять объекты с Client -> Server, которые вам не нужны. Часто более эффективно посылать только ключ, который идентифицирует объект, а не сам объект целиком.

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

LCDS обеспечивает это из коробки, однако для BlazeDS вы можете использовать для этого либо dpHibernate, либо Gilead.

(Раскрытие информации: я в команде dpHibernate)

Answer 6

Почему Abobe реализовал один модель потока?

Adobe не сделала. Макромедия сделала. Однопоточная модель находится в самом центре виртуальной машины. Им нужно было написать виртуальную машину Actionscript с нуля, чтобы представить многопоточную модель.

Answer 7

Не уверен, что вы уже видели это, но вы можете использовать PixelBender, чтобы эффективно получить многопоточное приложение Flash. См. Использование Pixel Bender для выполнения тяжелых работ, делает Flash Player многопоточным .

Удачи!

Juan