代码之家  ›  专栏  ›  技术社区  ›  Kevin Montrose

多线程UI api是什么样子的,它提供了什么优势?

  •  2
  • Kevin Montrose  · 技术社区  · 15 年前

    我的好奇心直接来自于这篇文章的评论(以及随后的编辑) answer questions/discussions 在过去,你可以从中得到一些启发,去真正地问这个问题。


    *在这个上下文中,多线程的定义非常松散,但是它对您来说是有意义的。


    接受答复


    几乎每个严肃的应用程序都有不止一个线程。至少,他们会启动一个额外的线程来完成一些后台任务 响应 指向UI事件。

    我不认为这是一个多线程UI。

    所有的UI工作仍在单线程上完成。我想说,在基本层面上,多线程UI api必须(以某种方式)消除UI对象的基于线程的所有权或将事件分派给单个线程。

    记住,这是关于UI api本身的;而不是使用它的应用程序。

    4 回复  |  直到 8 年前
        1
  •  3
  •   bdonlan    15 年前

    我看不出多线程UI API与现有UI API有多大区别。主要区别在于:

    • 所有方法都是可重入的、线程安全的,并保证不会阻塞事件回调(因此,在持有锁时不应调用事件回调)
    • 需要指定锁的总订单;例如,控件上方法的实现只允许调用子控件上的方法,除非安排异步回调稍后运行或在另一个线程上运行。

    通过这两个更改,您可以将其应用于几乎任何您喜欢的GUI框架。其实不需要大规模的改变;但是,额外的锁定开销会降低速度,并且对锁顺序的限制会使定制控件的设计变得更加复杂。

        2
  •  1
  •   patros    15 年前

    大多数GUI都是多线程的,至少在这个意义上,GUI是在与应用程序其余部分分开的线程中运行的,并且通常为事件处理程序多运行一个线程。这有一个明显的好处,即复杂的后端工作和同步IO不会使GUI突然停止,反之亦然。

    增加更多的线程往往是一个收益递减的命题,除非你在处理诸如多点触摸或多用户之类的事情。然而,大多数多点触摸输入似乎是在驱动程序级别进行线程化处理的,因此通常不需要在GUI级别进行处理。在大多数情况下,您只需要1:1的线程与用户比率加上一些常数,具体取决于您正在做什么。

    例如,预缓存线程很流行。线程可以在执行预测缓存时消耗任何额外的CPU周期,以使事情总体上运行得更快。动画线程。。。如果您有密集的动画,但希望保持响应能力,则可以将动画放在比UI其余部分优先级更低的线程中。如上所述,事件处理程序线程也很流行,但通常对框架的用户是透明的。

    因此线程肯定有用途,但是为GUI生成大量线程是没有意义的。然而,如果您正在编写自己的GUI框架,您肯定必须使用线程模型来实现它。

        3
  •  0
  •   Blindy    15 年前

    多线程ui应用程序没有问题,也没有特别之处。您所需要的只是线程之间的某种同步,以及一种跨线程边界更新ui的方法(在C#中启动InVoke,在普通Win32应用程序中发送消息,等等)。

    具体来说,您认为哪些方面不可取或难以实施?

        4
  •  0
  •   kaboom kaboom    15 年前

    1. 翻译
    2. 数字处理/网络/磁盘/等

    用户输入方法#2应该非常短,如果需要更多时间,那么调用#3中的内容,在这里添加更多线程将没有任何用处。