Почему большинство фреймворков UI являются однопоточными? - PullRequest
57 голосов
/ 05 апреля 2011

Например, Java Swing и Android UI оба используют однопотоковую модель, где один поток UI отвечает за обновление всего UI.Что заставило проектировщиков фреймворков выбрать одну модель потока вместо другой?

Разве модель многопоточного пользовательского интерфейса потенциально не могла бы дать вам больше производительности, хотя и ценой большей сложности?Я понимаю, что последнее имеет большое значение, потому что связанные с потоками ошибки неприятны , но мне интересно, есть ли какие-либо другие преимущества для однопоточной модели, кроме простоты?

Ответы [ 5 ]

39 голосов
/ 05 апреля 2011

Что заставило дизайнеров рамок выбрать одну модель нитки над другой?

Из пасть лошади :

AWT былизначально выставлялся как обычная многопоточная библиотека Java.Но когда команда Java изучила опыт работы с AWT, а также с тупиками и гонками, с которыми столкнулись люди, мы начали понимать, что даем обещание, которое не можем сдержать.

Этот анализ завершился одним изобзоры дизайна Swing в 1997 году, когда мы рассмотрели состояние игры в AWT и общий опыт работы в отрасли и приняли рекомендацию команды Swing о том, что Swing должна поддерживать только очень ограниченную многопоточность.

(Прочитайте всю статью, в ней подробно объясняется решение и говорится, что те же самые проблемы и возможный переход к однопоточной модели даже произошли ранее в Xerox PARC - месте, где почти все, что мы считаем передовым, современным в CSбыл изобретен 30 лет назад)

Разве модель многопоточного пользовательского интерфейса не могла бы дать вам больше производительности, хотя и ценой большей сложности?

Абсолютно нет, потому что рисованиеGUI и обработка действий пользователя (что являетсячто-то, что нужно сделать потоку пользовательского интерфейса) не станет узким местом в любом нормальном 2D-приложении.

10 голосов
/ 05 апреля 2011

Разве модель с многопоточным пользовательским интерфейсом потенциально не даст вам большей производительности, хотя и за счет большей сложности?

Не в большинстве случаев, и эта дополнительная сложность принесет больше вреда, чем пользы, в подавляющем большинстве случаев. Вы также должны понимать, что инфраструктура пользовательского интерфейса также должна работать с базовой моделью ОС. Конечно, это может обойти модель и абстрагировать ее от программиста, но в данном случае это просто не стоит.

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

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

1 голос
/ 05 апреля 2011

Я думаю, что это все о предотвращении тупиковой ситуации.

Компоненты Swing не считаются поточно-ориентированными, и они не должны быть из-за этого потока диспетчера событий. Если бы пользовательский интерфейс был многопоточным, все приложение должно было бы полагаться на то, что каждый компонент работал бы в поточно-ориентированном режиме, а если нет, то в неясных ситуациях могли бы возникнуть взаимные блокировки.

Так что, это просто безопаснее.

Мало того, но тот же дизайн был выбран Windows Forms (& .Net), GTK, Motif и другими. Интересно, если бы Java была вынуждена принять это решение базовыми API-интерфейсами ОС, с которыми они взаимодействуют. Конечно, SWT вынужден в этой ситуации Windows Forms.

Для получения дополнительной информации, "EDT" - хорошее место для начала http://en.wikipedia.org/wiki/Event_dispatching_thread

Для .NET эквивалент SwingWorker известен как BackgroundWorker.

1 голос
/ 05 апреля 2011

Нет, наверное нет.По крайней мере, когда вы пытаетесь запустить потоки на процессоре.На GPU уже много параллельной обработки в разных формах.Не столько для простой работы с графическим интерфейсом, сколько для фантазии 3D (затенение, отражения и т. Д.)

0 голосов
/ 05 апреля 2011

Это связано с характером приложения пользовательского интерфейса.

Вы должны прочитать ввод (мышь или клавиатура), отправить события, разрешить их обработку и затем снова нарисовать экран.

Попробуйте сделать это в многопоточном процессе.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...