#java #apache-flex #actionscript-3 #flex4 #adobe
#java #apache-flex #actionscript-3 #flex4 #adobe
Вопрос:
Какое лучшее решение для многопоточности в flex, я замечаю, что если я проигрываю mp3 в flex и делаю что-то еще одновременно, что-то заканчивается выдачей, либо песня перестает воспроизводиться, либо пользовательский интерфейс зависает примерно на долю секунды. У него нет того плавного отклика, которого я стремлюсь достичь. Если возможно, я хотел бы вызвать многопоточный класс java для выполнения некоторой серверной обработки на стороне клиента. Я просто не знаю, возможно ли это. Любая информация была бы с благодарностью принята, я застрял на этом.
-Фил
Ответ №1:
Одни только Flex / Flash не поддерживают многопоточность — Adobe продолжает утверждать, что многопоточность не является необходимой для большинства потенциальных приложений flex и только слишком усложнит работу среднего разработчика flex.
В поисках решений я сам нашел только фрагменты, в которых задача, выполняемая одновременно, логически разбивается на более мелкие части, затем вы запускаете их по частям, позволяя пользовательскому интерфейсу получать временные интервалы между ними. Для некоторых это может сработать, но не является решением вашей проблемы.
Теперь перейдем к Java — использование встроенного process api может заставить его работать. Java-процесс возьмет на себя некоторую часть обработки, и вы будете контролировать его рабочую запись в потоки ввода / вывода и чтение из них, которые подключаются между java-процессом и приложением flex. Другой возможностью может быть обмен данными между процессными сокетами (делал это сам до появления native process api — работает!)
Ответ №2:
Если пользовательский интерфейс зависает, у вас есть другая проблема. Мне кажется, что вы перебираете какие-то данные, чтобы вызвать это «отставание». Что вы можете сделать, так это лучше отформатировать данные, чтобы не столкнуться с этим. Или посмотрите на свой процесс, который вы запускаете, когда происходит зависание, и оптимизируйте его лучше.
Ответ №3:
Flex / Flash не имеет методов блокировки и поэтому не нуждается в обработке потоков, просто вызовите функцию по таймеру или enterframe и убедитесь, что она выдает результат менее чем за 25 мс или около того. Что касается скорости, Java (работающая в виртуальной машине Android ‘Dalvik’) не намного лучше… C — единственный вариант для максимальной скорости.
Комментарии:
1. Внутренне он, конечно, использует потоки — рендеринг экрана будет разделен поровну между ядрами. Однако на стороне actionscript асинхронные методы означают, что технически не существует варианта использования, требующего потоков… за исключением, я полагаю, использования нескольких ядер для выполнения actionscript — однако, по моему опыту, выполнение скрипта очень редко является узким местом в приложениях flash. Хотя это хороший момент. Я полагаю, что я имел в виду, что API разработан с учетом того факта, что доступных потоков нет,
Ответ №4:
Вот довольно полная библиотека Greean Thread — http://blog.generalrelativity.org/actionscript-30/green-threads
Я нашел это полезным, поскольку, независимо от взглядов Тома, потоковая передача, безусловно, часто является необходимой вещью, которая не поддерживается должным образом (пока??)
Ответ №5:
Также имейте в виду, что проигрыватель отладки ведет себя совсем не так, как стандартный проигрыватель, и (отдельная проблема) что во время сеанса отладки могут наблюдаться значительные замедления в коде, критичном к производительности… Верьте только плагину браузера, не отладочной версии, запущенному в браузере, а не отладке. Это единственный надежный тест. Я наблюдал ускорение в 25-30 раз, просто перейдя на release Player (в крайнем случае). Думал, что у меня серьезная проблема с производительностью, но на самом деле это не так 🙂