Почему Flex использует единственную потоковую модель?
(Отредактированный для ясности.)
Лично, я думаю строгий, хорошо. Столько различных ситуаций требует различных правил вокруг расслабленного парсинга, невозможно действительно поместить это в общую библиотеку всесторонне.
Однако я был бы полностью рекомендовать Время Joda вместо встроенных классов даты/времени в целом. Их средства форматирования и синтаксические анализаторы ориентированы на многопотоковое исполнение и неизменны, который помогает также. Время Joda имеет некоторую поддержку расслабленного парсинга, как показано в другом ответе, но необходимо ожидать должными быть предоставлять некоторые правила сами.
7 ответов
Я видел очень интенсивные настольные типы приложений Flex для трейдеров, которые отлично работают в однопоточной модели Flex. Причина в том, что внутренние приложения Flex используют асинхронный сетевой ввод-вывод. Таким образом, пользовательский интерфейс не блокируется, когда вы делаете запросы. Вы можете столкнуться с ограничениями с BlazeDS и, возможно, вам следует подумать о том, что использует RTMP (например, LCDS). RTMP - более эффективный протокол для потоковой передачи больших объемов данных клиенту. Также есть способы оптимизировать код обработки событий и отрисовки на стороне клиента, чтобы не перегружать пользовательский интерфейс. У Кристофа Коэнраетса есть несколько хороших демонстраций того, как делать такие вещи: http://coenraets.org/blog/?s=trader+desktop
То, что вы пытаетесь сделать, безусловно, возможно с Flex, и есть люди, которые это успешно сделали. https://bugs.adobe.com/jira/browse/ASL-23
Не уверен, что вы это уже видели, но вы можете использовать PixelBender для эффективного получения многопоточного Flash-приложения. См. Использование Pixel Bender для выполнения тяжелых вычислений делает Flash Player многопоточным .
Удачи!
Хуан
If you're having issues with the stability of your UI it might very well be that you're not making appropriate use of the UIComponent model in Flex. It works based off an invalidation / validation model that allows for updates to be deferred until the UI thread is ready to repaint the screen. There's a great presentation on it here:
http://tv.adobe.com/#vi+f15384v1002
Even if your Flex app still had trouble handling 20-30 UI updates per second after those optimizations, what human can actually make sense out data changing at that rate? I would imagine that refreshing the UI once per second would be adequate as long as the full data set was available for calculations and analytics.
Я делаю нечто очень похожее на это, и ограничение касается не одного потока, а всех данных, которые отправляются обратно и пытаются обновить их в реальном времени. Дело в том, что вам не нужно реальное время, или, по крайней мере, вы можете изменить то, что на самом деле означает «реальное время».
На стороне сервера, вместо того, чтобы отправлять данные сразу после предыдущего нажатия, пусть он подождет секунду и увидит, поступят ли новые обновления. Если да, вы можете отправить эти обновленные данные. Нет причин немедленно возвращать данные «в реальном времени», если через миллисекунду вы собираетесь вернуть другое обновление. Мне неприятно говорить, что здесь можно пойти с опросом, потому что это не так, но псевдо-опрос или отложенный ответ - это путь. Дело в том, что поезд подъезжает к станции и пропускает только одного человека.
Отвечая на ваш вопрос о Silverlight, на самом деле он позволяет использовать несколько тем.
Почему abobe реализовать единый модель потока?
Adobe этого не сделала. Macromedia сделала. Однопоточная модель лежит в основе виртуальной машины. Им пришлось бы написать виртуальную машину Actionscript с нуля, чтобы внедрить поточную модель.
Если ваш пользовательский интерфейс блокируется во время отправки или получения сообщений pub / sub , скорее всего, это вызвано сообщением (де) / сериализацией данных. Уловка состоит в том, чтобы безжалостно ограничивать размеры полезной нагрузки. Вам действительно нужно каждое поле во всех объектах, которые вы только что отправили?
Точно так же старайтесь не отправлять объекты из Клиент -> Сервер, которые вам не нужны. Часто более эффективно отправить только ключ, идентифицирующий объект, а не весь объект целиком.
Кроме того, вы можете добиться повышения производительности, отправляя клиенту только те объекты данных (и их соответствующие поля), которые будут отображаться на экране, и откладывая расходы других до тех пор, пока они действительно не потребуются. (т. е. разбивка данных на страницы)
LCDS предоставляет это прямо из коробки, однако для BlazeDS вы можете использовать для этого либо dpHibernate, либо Gilead.
(Раскрытие информации: я в команде dpHibernate)