2018-12-13-不要相信那些事件引发者

黄腾霄

发布于 2020-06-10 11:39:06

3520

发布于 2020-06-10 11:39:06

文章被收录于专栏：黄腾霄的博客

最近发现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;
            }
        }

。

。。

。。。

答案揭晓：