最近发现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相关，那么如果在登陆后在后台线程注册，就会出现跨线程访问问题哦