And*_*mbe 4 language-agnostic user-interface
在过去,我曾与许多专门编写GUI应用程序的程序员合作过.
我得到的印象是,他们几乎普遍最小化了在他们的应用程序中使用多个线程.在某些情况下,他们似乎已经竭尽全力确保他们使用单个线程.
这是常见的吗？这是gui应用程序设计的普遍接受的哲学吗？
如果是这样,为什么？
[编辑]
有许多答案说应该最小化线程使用以降低复杂性.一般来说降低复杂性是一件好事.
但是,如果你看看对外部事件的响应至关重要的任何数量的应用程序(例如,Web服务器,任何数量的嵌入式应用程序),对线程使用的态度似乎存在差异.
我认为就Windows来说,你只限于在一个线程上发生的所有GUI操作 - 由于windows消息泵工作的方式,为了增加响应性,大多数应用程序添加至少一个额外的工作线程,否则会阻止更长时间运行的任务使ui反应迟钝.
线程从根本上来说很困难,所以用一些线程或多个线程进行思考通常会导致大量的调试工作 - 有一个引用现在就让我感到厌烦 - "如果你认为你理解线程那么你真的没有"
一般来说,GUI框架不是线程安全的.对于像Swing(Java的GUI API)这样的东西,只有一个线程可以更新UI(或者可能发生不好的事情).只有一个线程处理调度事件.如果你有多个线程更新屏幕,你可能会得到一些丑陋的闪烁和不正确的绘图.
但这并不意味着应用程序需要是单线程的.在某种情况下,您肯定不希望出现这种情况.如果单击计算pi到1000位数的按钮,则不希望UI被锁定,并且在接下来的几天内要按下按钮.这就像SwingWorker之类的东西派上用场.它有两个部分:一个doInBackground(),它在一个单独的线程中运行,一个done()由doNBackground线程完成后处理更新UI的线程调用.这允许快速处理事件,或者在后台处理需要很长时间的事件,同时仍然让单个线程更新屏幕.
我也见过同样的事情。理想情况下，您应该在后台线程中执行任何需要超过几百毫秒的操作。任何超过 100 毫秒的排序，人类可能不会注意到其中的差异。
过去与我共事的许多 GUI 程序员都害怕线程，因为它们很“困难”。在一些 GUI 框架（例如 Delphi VCL）中，存在有关从多线程使用 VCL 的警告，这往往会吓到一些人（其他人将其视为挑战；））
多线程 GUI 编码的一个有趣的例子是 BeOS API。应用程序中的每个窗口都有自己的线程。根据我的经验，这使得 BeOS 应用程序的响应速度更快，但它确实使编程变得更加棘手。幸运的是，由于 BeOS 默认被设计为多线程，因此 API 中有很多东西可以使事情比我使用过的其他一些操作系统更容易。