.net - 为两个独立的表单设置两个 GUI 线程是否有意义？

Question

在工作中，我们有一个非常占用 CPU 资源的 Windows 窗体应用程序。它在具有 24 个内核的服务器上运行。

由于 Windows 窗体模型涉及处理消息泵的单个 GUI 线程，因此丰富、复杂的 GUI 似乎没有充分利用系统的功能。我这样说有错吗？

所以我的同事正在讨论这个。我们的应用程序恰好涉及两个或多或少独立的表单。想法是让辅助表单在其自己的专用线程上运行，释放应用程序的主 GUI 线程以仅处理发送到主表单的消息。

大概这看起来像这样:

void CreateAuxiliaryForm()
{
    Action displayForm = () =>
    {
        var f = new AuxiliaryForm();
        f.ShowDialog();
    };

    displayForm.BeginInvoke(displayForm.EndInvoke, null);
}

现在，首先，我不知道这样做是否安全。但我的想法是，既然这两种形式将是独立的，那么每个形式都有自己的线程确实应该没问题。这是真的吗？

我确实说了“或多或少”，那是因为我真的不能说这两种形式没有任何相互作用。但是我和我的同事认为，在主窗体必须以某种方式与辅助窗体交互的任何情况下(比如一个处理另一个引发的事件)，我们只需要确保使用 Invoke/BeginInvoke 将任何与 GUI 相关的代码发送到适当的消息泵。

人们对这个想法有何看法？

Answer 1

通常:不要。

线程化 UI 可能有帮助的可能原因很少:

• 您在用户操作后阻塞前台线程很长一段时间(比如 > 5 秒)
• 您正在阻塞非用户触发的显着时间跨度(>~300..500 毫秒)(例如，通过定期计时器)
• 您有非常昂贵的更新(呈现全屏图表)并且期望有十几个这样的表格处于事件状态。

否则，即使是具有数百个按钮和控件的“来自 hell 的 UI”，也毫无意义。

UI 的唯一性能要求是流畅，这意味着用户感知 UI 对其操作的响应是“即时的”——对于大多数操作来说是 100..300 毫秒(取决于 Action 的频率和响应的“大小”)。

缺点很多。 WinForms 建立在 Win32 GUI 之上，其中线程“有点适用于顶级表单”，但需要一些注意才能正确。 Internet Explorer 甚至使用多个进程，并且一些插件仍然设法在一个页面挂起时关闭所有选项卡。