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

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

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

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

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

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

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

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

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

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

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

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