不要阻止UI线程！
有时，有一种诱惑可以避免ContinueWith的麻烦，甚至可以通过阻止用户界面线程直到后台进程完成来等待更轻微的麻烦。 也许您知道后台进程会很快完成，并且用户无论如何都不会做任何事情直到完成。 有什么危害？
不要这样做！ 它不仅对用户不礼貌，而且可能会在您的应用程序中引入微妙的错误。
让我们举个例子：在TextFileAsyncPage的代码隐藏文件中，OnFileListViewItemSelected处理程序具有以下代码来读取文件并在编辑器中设置内容：
fileEditor.Text = await fileHelper.ReadTextAsync((string)args.SelectedItem);您可能已经意外地或者通过实验发现，在这样的语句中，您可以省略await运算符并只访问从ReadTextAsync返回的Task 对象的Result属性。 Result属性是要读取的文件的内容：
fileEditor.Text = fileHelper.ReadTextAsync((string)args.SelectedItem).Result;代码似乎很好，它甚至可能工作。 但它的工作方式并不好。 此语句将阻止用户界面线程，直到ReadTextAsync方法完成并且Result可用。 在此期间，用户界面将无响应。
此外，如果在FileHelper中的ReadTextAsync实现中未使用ConfigureAwait（false），则该ReadTextAsync方法将需要切换到用户界面线程，以便在每个await运算符之后恢复执行。 但是当它尝试切换回用户界面线程时，UI线程将无法使用，因为它在TextFileAsyncPage中的ReadTextAsync调用中被阻止，并且会产生典型的死锁。 该程序将完全停止执行。
规则很简单：对每个异步方法使用ContinueWith或await。
