为什么大多数UI框架都是单线程的？

Question

例如，Java Swing和Android UI都使用单线程模型，其中单个UI线程负责更新所有UI。是什么让框架设计师选择了一个线程模型而不是另一个？

多线程UI模型不会以更复杂的代价提供更多性能吗？我意识到后者是一个大问题，因为线程相关的错误讨厌但我想知道除了简单性之外单线程模型是否还有其他优点？

Answer 1

  

是什么让框架设计师选择了一个线程模型而不是另一个？

来自the horse's mouth：

  

AWT最初是正常暴露的   多线程Java库。但是作为   Java团队研究了这种体验   与AWT和僵局和   人们遇到的种族，我们   我们开始意识到我们正在做一个   保证我们不能保留。

     

这一分析最终导致了其中一项   1997年Swing的设计评论   我们回顾了AWT的比赛状况，   和整个行业经验，   我们接受了Swing团队的工作   建议Swing应该   支持非常有限   多线程。

（阅读整篇文章，它非常详细地解释了这个决定，并指出完全相同的问题，最终转向单线程模型甚至在施乐帕洛阿尔托研究中心早些时候发生过 - 我们认为几乎所有的东西都是现代化的在CS发明于30年前）

  不会有多线程的UI模型   可能会给你更多的表现   虽然以更复杂的代价为代价？

绝对不是，因为绘制GUI和处理用户操作（这是UI线程需要做的所有事情）不会成为任何理智2D应用程序的瓶颈。

Answer 2

  

多线程UI模型不会以更复杂的代价为您提供更多性能吗？

在大多数情况下并不是这样，并且在绝大多数情况下增加复杂性会带来更多弊大于利。您还必须意识到UI框架也必须处理底层操作系统模型。当然，它可以解决模型并抽象出程序员，但在这种情况下它根本不值得。

多个线程更新UI ad hoc导致的错误数量远远超过大多数无意义的性能提升（如果甚至有增益，由于锁定和同步，线程会带来相关的开销，你可能实际上只是在很多时候使性能变差。）

在这种情况下，最好只在需要时明确使用多个线程。大多数情况下，在UI中，您希望一个线程上的所有内容都通过使用多个线程获得很多东西。 UI交互几乎从不成为瓶颈。

Answer 3

不，可能不是。至少在尝试运行CPU上的线程时不会。在GPU上已经有很多种形式的并行处理。对于简单的GUI工作而言，并不是那么多，而是用于花哨的3D（阴影，反射等）

Answer 4

我认为这都是关于预防死锁的。

Swing的组件不被认为是线程安全的，并且它们不一定是因为这个事件调度程序线程。如果UI是多线程的，那么整个应用程序必须依赖于每个组件以线程安全的方式表现自己，如果没有，那么在不明显的情况下就会出现死锁。

所以，它更安全。

不仅如此，Windows Forms（＆amp; .Net），GTK，Motif和其他各种设备也选择了相同的设计。我想知道Java是否会被他们与之交互的底层OS API强制做出这个决定。当然，Windows Forms强迫SWT进入这种情况。

欲了解更多信息，“EDT”是一个开始http://en.wikipedia.org/wiki/Event_dispatching_thread

的好地方

对于.NET，SwingWorker的等价物称为BackgroundWorker。

Answer 5

这是因为UI应用程序的性质。

您应该阅读输入（鼠标或键盘），调度事件，让他们处理，然后重新绘制屏幕。

尝试在多线程进程上执行此操作。