c# - 使用 DispatcherObject 的 VerifyAccess 和 CheckAccess 方法

Question

在遍历 this 时文章我遇到了这个声明-

If you are writing your own WPF objects, such as controls, all methods you use should call VerifyAccess before they perform any work. This guarantees that your objects are only used on the UI thread, like this

//Using VerifyAccess and CheckAccess 
public class MyWpfObject : DispatcherObject
{
    public void DoSomething()       
    {
        VerifyAccess();

        // Do some work
    }

    public void DoSomethingElse()
    {
        if (CheckAccess())
        {
            // Something, only if called 
            // on the right thread
        }
    }
}

我在遇到的任何自定义控件中都没有看到这一点(据我所知)。

• 您在构建自定义控件时是否使用它？
• 是必须这样做还是拥有它就好了？
• 有没有人因为您的控件中缺少此功能而遇到过任何问题？

Answer 1

不，从来没有用过这个。并且从未注意到有人在自定义控件的上下文中使用它。 WPF Toolkit 中也不遵循此规则。

这种方法不仅会污染代码，还会使您的自定义控件负责一些它不应该关心的事情。考虑一下您总是在做的情况:

// Don't do this in all methods of your custom control!
public void Foo()
{
  if (!CheckAccess())
  {
    Dispatcher.Invoke(()=> Foo()); // Transit to UI Thread
    return;
  }
  // .. do work in UI.
}

乍一看这段代码看起来不错。如果不在UI线程，则跳转到UI线程，执行操作并返回结果。正确的？ - 错了!

问题 1. 当您调用 Dispatcher.Invoke() 时，您会阻止调用线程，直到您的请求被 UI 线程处理为止。这会导致性能不佳。当然，您可以将其更改为 Dispatcher.BeginInvoke() 现在您的客户应该知道他们的操作是异步完成的。 IE。如果客户端写入要控制的内容，然后立即将其读回，则无法保证 UI 线程已经执行了该操作。

问题 2. 考虑从非 UI 线程对方法 Foo() 的后续调用。例如在循环中调用:

// Somewhere not in UI
for (int i = 0; i < 1000000; i++)
{
  control.Foo(); // Looks good, but performance is awful!
}

开发人员可以在调用线程中执行一次检查并在必要时转移到 UI，而不是无意识地在线程之间跳回并计算值，而不是阻塞调用线程 1000000 次。

此外，当您从非 UI 线程访问 UI 元素时，WPF 将为您进行此检查。它的尖叫声足以摧毁应用程序并被做错事的开发人员听到:)。

希望这对您有所帮助。