WinUI 3作为一个新式桌面应用框架，还有很多方面需要打磨，崩溃错误也是频发的。
在使用IDE调试（Debug模式）过程中，异常大都会被编译器捕捉并被我们看见，也就是几乎不需要我们手动收集。
但一旦进入生产环境（Release模式）时，就会出现这些问题：

• 异常和崩溃不会被调试器（Debugger）捕捉，也不会有任何输出。
• 生产环境中我们追求稳定，就会抑制一些不是很重要的异常。但这并不代表异常就解决了，它反而可能到其他地方表现了出来，而且甚至表现为崩溃，这导致我们找不到故障的原发地而一头雾水。
• AOT模式下大量代码被剪裁。在WinUI 3 AOT技术预览版中，调试模式下的错误甚至都不会被调试器捕捉，这迫使我们手动输出错误。

使用MVVM框架时，属性的赋值顺序一直都是令人头疼的点。
一方面希望参数赋值一步到位，以减少OneWay绑定的使用；
另一方面若顺序搞错了，后果轻则属性获得空值，可能需要触发PropertyChanged才能更新，
重则直接调用了null成员，直接导致程序崩溃。

所以本文我们通过实验的方法进行探讨，XAML的赋值顺序和事件的触发顺序是什么样的。

测试目标

首先我们需要明确，到底有多少内容需要分析。经过整理，得到以下内容：

事件和方法：

写过任何桌面应用，尤其是WinForm的朋友们应该见过，Main函数上放置了一个[STAThread]的Attribute。
而且几乎所有的桌面应用框架，都是由同一个UI线程来执行渲染操作的，这表现为从其他线程修改控件的值就会抛异常：

await Task.Run(() => control.Content = ""); // throws exception

ImageSource相关类型是最常用的API之一，用来在界面中展示图片。
但从WPF开始，我就一直分不清ImageSource、BitmapImage、Bitmap的区别。
甚至还因为它们名称带“Source”，错认为“Source”类才是承载图片的源、核心，现在看来真是大错特错了。
本文将会纠正这些概念。

首先请看WinUI 3中ImageSource相关的类型继承表。

名称辨析

首先先要理解何为“Source”才好对这些类型做个初步的印象。

WinUI 3是本地UI平台组件，由NuGet包WindowsAppSDK（旧称Project Reunion）提供API及功能。 WindowsAppSDK提供了一组统一的API和工具，可用于创建桌面应用。

WindowsAppSDK正在快速迭代中，正以每半年一个大版本进行更新。

WinUI 3框架与微软其他桌面应用框架的异同一直是初学者最关心的问题：

与UWP的关系和区别

WinUI 3是UWP的直接继任者。是UWP框架的UI层（该层又称为WinUI2）解耦移植来的，旨在取代UWP。
所以可以看到WinUI 3和UWP的API，除了命名空间分别是Microsoft.UI.Xaml.*和Windows.UI.Xaml.*以外，其他部分几乎没有区别（所以当遇到WinUI 3问题而资料太少时，可以查询UWP相关问题）。