最近发现C#的事件和wpf的dispatcherobject在一起使用会有一些不容易发觉的问题。


我们都知道C#的事件原理,实际上是存储了一系列方法的委托。当事件引发的时候,依次调用(Invoke)委托列表的委托进行执行。

所以从中可以发现显而易见的一些问题比如:

  • 监听事件执行顺序无法保证
  • 耗时委托执行拖慢其他业务注册的方法
  • 资源泄露问题

这些很多人都会聊,我们就不讲了~

今天重点讲wpf会遇到的跨线程访问的问题。

我们都知道wpf的DispatcherObject,必须在创建它的Dispatcher上执行,而由于C#的事件机制,这个调用线程(及关联的Dispatcher)的控制权交给了事件引发者。

所以不注意的小伙伴就常常会出现这样的情况:

  • 事件引发者时而从主线程Invoke,时而从后台线程Invoke
  • 事件监听者概率性出现UI元素跨线程调用问题。

怎么办呢?

  • 方案1:部分小伙伴会选择直接在事件注册的函数里添加Application.Current.Dispatcher.Invoke
AppFoo.Login += ()=>
{
    Application.Current.Dispatcher.Invoke(()=>
    {
    	//业务
    });
}

很不错,这个方法可以很好的解决问题。但是只能发现一处解决一处

  • 方案2:于是又小伙伴别出心裁,在引发处处理
	Application.Current.Dispatcher.Invoke(()=>
    {
    	Login?.Invoke();
    });

这样一来所有的注册函数都会在主线程执行。跨线程调用是解决了,但是UI卡顿就加重了。。

  • 最佳实践:我们在事件注册函数中不相信那些事件引发者,(路由事件等确定是UI线程引发的事件除外),针对UI元素调用使用Dispatcher.Invoke,针对耗时操作使用异步方法。

一个附加的测试小案例,下面的代码小伙伴为了解决登陆事件早于注册时机的问题,在注册事件的时候判断是否已经登陆,如果是,则直接Invoke函数

你们能够看出问题所在么?

		private event EventHandler _userLogined;
        public event EventHandler UserLogined
        {
            add
            {
                if (IsAuthed)
                {
                    value.Invoke(this, EventArgs.Empty);
                }
                _userLogined += value;
            }
            remove
            {
                _userLogined -= value;
            }
        }

。。

。。。

答案揭晓:

  • 注册的时候调用,执行的线程控制权就交给了注册方法。如果事件引发是来自主线程,注册的方法也是UI相关,那么如果在登陆后在后台线程注册,就会出现跨线程访问问题哦

本文会经常更新,请阅读原文: https://huangtengxiao.gitee.io/post/%E4%B8%8D%E8%A6%81%E7%9B%B8%E4%BF%A1%E9%82%A3%E4%BA%9B%E4%BA%8B%E4%BB%B6%E5%BC%95%E5%8F%91%E8%80%85.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名黄腾霄(包含链接: https://huangtengxiao.gitee.io ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系