最近在用MVVM模式写应用的时候和线程打交道很多，也遇到一些问题，引起一些思考，这里和大家分享一下。
MVVM设计模式
**Model-View-ViewModel (MVVM) **在Windows平台开发可以使用MVVM Light Toolkit进行，简化开发过程，构建松耦合的应用程序。
MVVM Light通过：
- 依赖注入(DI)/控制反转(IOC)的方式创建ViewModel
- 使用
Messenger实现消息通知 - 使用
RelayCommand替代事件处理程序
实现了View和ViewModel的分离关系。
客户端上的多线程和调度
如今在移动客户端上处理多线程以及线程间的通信显得非常重要。在.Net平台上构建应用程序和框架，多线程也是长谈的话题，每个完整的应用都要启动多个后台线程并对他们进行管理，对于计算能力较低，资源受限的平台，例如移动端设备和嵌入式设备，在这些平台上处理好线程对UX的流畅显得尤为重要。
Windows 10 Mobile平台最早的版本Windows Phone7上，对于长列表的滚动流畅非常困难，但在其后的版本中，专门使用后台线程处理，不在影响主线程，实现了滚动的流畅。本文中，我会回顾基于XAML编写界面的程序中处理线程的一般方式。
线程
线程(Thread),在操作系统中被视为最小的执行单位。每个程序至少都有一个主线程，新的线程可以在代码中显式启动，多数情况下，新线程的启动主要是为了执行或者等待某个操作，也不会导致程序的其他部分被阻塞。耗时操作主要是计算密集型操作、磁盘I/O和网络传输。由于这些操作在现代应用程序中非常常见，应用也日益多线程化。
同步和异步
在为Windows 10 UWP编写的应用中，异步操作已经是家常便饭了。例如，UWP中对文件的操作都是以异步的方式进行的。
下面是在WPF中同步读取文件方式：
public string ReadFile(FileInfo file)
{
using (var reader = new StreamReader(file.FullName))
{
return reader.ReadToEnd();
}
}
而在UWP中，和上面效果等同的异步操作:
public async Task<string> ReadFile(IStorageFile file)
{
var content = await FileIO.ReadTextAsync(file);
return content;
}
我们注意到，这里多了两个关键字await和async ，这里要感谢微软爸爸对C#的不断完善，这两个关键字使新的程序代码的可读性提高，方便了程序员编写异步方法。
同步方式和异步方式的主要区别在于，同步方法如果正在读取的文件较大，可能会阻塞主线程，导致UX变得糟糕。而异步的方法将在后台线程处理。
线程间通信
当一个线程要和另一个线程通行时，例如访问另一个线程的对象，我们需要采取一些防范措施。看下面的代码：
private async void Button_Click(object sender, RoutedEventArgs e)
{
await Change();
}
private async Task Change()
{
await Task.Run(() =>
{
this.Count.Text=DateTime.Now.ToLocalTime().ToString();
});
}
使用Task.Run()方法新开一个线程，访问一个XAML中的文本框控件的Text属性。
如果真的用这段代码运行程序，点击按钮时，应用程序会崩溃退出。
我们来分析一下。在创建对象时，这个操作发生在调用构造函数的线程上。对于UI控件，创建控件对象的操作发生在主线程上，也可以说是UI线程。因此，所有UI控件都是属于主线程的，当我们新开一个线程去访问UI线程拥有的对象时就会发生跨线程访问问题。这个操作会引发一个异常：
注意到，异常信息提示“应用程序调用一个已为另一线程整理的接口”。
那么问题来了，难道我们真的不能在非UI线程去更新UI控件么？
线程调度
要使代码按照我们设想的运行，我们需要让新线程通过联系主线程，通过主线程的调度程序更新UI控件。将上面的代码修改为：
await Task.Run(async () =>
{
await this.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>
{
this.Count.Text = DateTime.Now.ToLocalTime().ToString();
});
});
注意到这里用到了Dispatcher属性
Dispatcher属性摘要
获取此对象所关联的 CoreDispatcher。 CoreDispatcher 表示即便代码由非 UI 线程发起也可访问 UI 线程上的 DependencyObject 的设备。
这个属性提供对其所有者调度程序的访问。所以所有拥有这个属性的对象，理论上都能提供跨线程访问的服务。
这个属性源自Windows.UI.Xaml.DependencyObject对象，也就是说，所有有依赖属性都继承自这个对象，那么所有的UI控件都是可以通过Dispatcher实现跨线程访问的。
MVVM中的跨线程调度
当我们在ViewModel中执行后台线程操作时，情况有所不同。通常，VM不会去继承前面提到的DependencyObject，也就没有Dispatcher属性。
当我们把一个UI控件的属性绑定到VM中的一个属性，我们的程序通过更改VM的属性来改变UI控件属性。注意到，我们在使用MVVM Light的时候，每个VM都要继承一个叫做ViewModelBase的对象，这个对象实现了INotifyPropertyChanged接口，这个接口的方法引发PropertyChanged事件，在这里实现通知UI属性改变的效果。
当我们按先前的方法，新开一个线程，用这个线程去更改VM中绑定到UI控件属性的属性时，你会发现也引发了跨线程访问异常，程序异常退出。
我们可以知道，即使我们通过数据绑定来实现这样的目的也是不能实现的。
因此，我们需要一种方式来访问主线程。在MVVM Light中，为我们实现了一种方式。当你的项目使用了MVVM Light之后，你尝试在VM的类中输入DispatcherHelper，再用一下智能感知，你会发现在MVVM Light中存在这个对象。这个类所做的就是将主线程的调度程序保存在静态属性中，公开了让我们跨线程访问等一些实用方法。为了正常使用这些功能，我们需要在主线程初始化这个类，最好是在应用程序初始化时进行。
我们能够想到，App.xaml.cs这个文件的OnLaunched方法是在程序开始运行是执行的，我们要把DispatcherHelper.Initialize();放在这个方法的最后以实现初始化，之后就能在VM中使用了。
DispatcherHelper.CheckBeginInvokeOnUI(() =>
{
//访问VM的属性
});
这里推荐使用他的CheckBeginInvokeOnUI方法去执行而不是他的UIDispatcher属性。这个方法首先执行检查，检查调用方是否已经在主线程上，如果在就直接执行后面的委托，如果不是就去执行调度。
那这篇文章就到这里啦，希望大家在MVVM的使用中一切顺利~
本文参考MVVM : Multithreading and Dispatching in MVVM Applications
