UWP应用，全称可能叫Windows通用平台应用，是微软推出的新一代Windows应用开发模型。然而，自推出以来，一直饱受诟病。其中很容易闪回，这是很多人的第一印象。今天我们就来聊聊UWP应用闪回的问题，教大家如何解决。

本文所描述的是从开发者的角度出发，即从应用代码出发解决问题。UWP应用程序闪回的问题不是从用户的角度，而是在应用程序之外解决的。

大多数闪回的根源

UWP应用不是瓷娃娃，所以没那么脆弱。“闪回”，说到底其实是Windows对系统的保护，避免因应用而干扰系统运行。这种处理是从系统的角度出发的，但是开发者和用户都不欣赏。

应用闪回对用户体验的影响不用多说。几次闪回之后，软件卸载，闪回应用很多，甚至让他对整个UWP应用都产生了厌恶。

而开发者也在纠结。用户抱怨闪回，但在这里无法重现，给开发者调试带来困难，有时不了了之。

那么大部分闪回的根源是什么呢？

总之，有一个不可处理的异常。

写应用的时候，出错的原因多种多样，大的架构设计不当，小的不安全空(Null)值。一些开发人员在设计程序时可以通过使用“try-catch”语句来捕捉这些错误。越是有经验的程序员，设计的时候会考虑越多可能出现的异常。但是人力资源有时候很差，不可能考虑到方方面面。一旦程序在运行过程中出现* *未被捕获的异常，应用二话不说，立即闪退。

这样看来，似乎不可避免的会出现未被捕获的异常，但为什么有些应用不闪退呢？他们的节目都是试捕吗？

肯定不是~

解决未捕获的异常非常简单，即使有大括号，也只需要五行代码。

如何一劳永逸的解决闪回问题？

正如上一节提到的，大多数闪回的根本原因是未捕获的异常。既然没捕捉到，那我们不就应该把它捕捉完吗？

说起来容易，但是...更容易做到！

每个新的UWP应用都有一个App.xaml文件，后面还有一个App.xaml.cs。

App.xaml.cs包含了关于应用启动、暂停等应用层面的操作逻辑，相信所有开发者都知道。而所有未被捕捉到的异常，最终都会在这里冒泡，所以这是最后一关。换句话说，我们要做的就是在这里建立一个卡片，捕捉这个异常，防止它触发闪回机制。

App类是从Application类派生出来的，它有一个事件，就是UnhandledException，也就是说* *它发生在应用程序代码可以处理异常的时候，比如本机级别的Windows运行时的错误转发。应用程序可以标记事件数据* *中处理的匹配。

换句话说，人家早就想到会有闪回，早就给你预定好了这个活动。那么我们要做的很简单

首先，添加App的构造函数。

这个。unhandled exception = onunhandlexception；

将处理程序绑定到此事件。

接下来，让我们编写这个处理程序:

private void onunhandlexception(对象发送方，Windows。UI . xaml . unhandledexceptioneventargs e)

{

e . Handled = true；

}

这样就解决了未捕捉到的异常引起的闪回，这种原因引起的闪回占总数的90%以上。可以说接下来，只要你的应用不死，不故意写无限循环，不搞不安全的Sao操作，基本上就不会再闪退了。

逆燃问题的后续处理

发生闪回，说明程序中有错误没有被捕获。既然有错，就一定要解决。只有一个e . Hanled = true……

虽然这种粗暴的解决方法可以一次性解决闪回问题，但是治标不治本(虽然用户不清楚，但是实际体验已经提升了很多)。作为软件设计人员，我们还是要知道到底哪里出了问题，错误的原因是什么，这就涉及到异常的后续处理。

如果你的应用上传到微软应用商店，你的软件在用户处的使用情况会被记录在微软应用商店的后台，出现异常时也会上传到你的软件后台，方便管理:

可以在后台观察异常，然后在程序中解决。

但总有例外，微软应用商店无法捕捉所有的例外并进行分析。这里有一个例子:

在开发WFA的时候，我遇到了一个棘手的问题。Win10 14393的用户打开应用程序设置时，应用程序会闪退，但后来的版本不会。当时我在app store后台看的时候，它不知道为什么，显示了一个未知的异常，让我很尴尬。

在莫名其妙的情况下，我在App.xaml.cs的异常捕获函数中加入了一个小东西，就是在捕获到异常后，把对异常的解释传递给我的数据库。这样我很快就找到了问题的原因，就是14393系统不支持AutoSuggestBox控件的一种样式，导致应用无法渲染，直接后退。

虽然我最终放弃了对14393的支持(使用了ContentDialog的新控件)，但是这种本地处理也可以作为一种体验保留下来(WFA现在还没有在异常捕获中加入上传代码)。

综上所述，闪回异常的后续处理可以通过两种方式解决:

一种是依靠微软App Store的异常上传机制，易于管理；

当当前的处理方式无法满足需求时，您可以在App.xaml.cs中的异常捕获函数中进行本地处理，并将更详细的信息上传到您的数据库中供您分析。

不过需要注意的是，由于发布的安装包基本都是Release，所以异常捕捉不会像调试那么准确，有时候需要根据情况来分析。

闪回的第二个原因

闪回的原因可以分为两部分。一个是我前面提到的代码存在未被捕获的异常，另一个是应用渲染得不到相应的资源，这尤其说明了UWP开发平台的不成熟。

说白了，这个原因其实就是“风格导致的闪回”，我之前分享的WFA的例子里也提到过。

开发过UWP应用程序的学生应该熟悉控件风格。这是UI的关键部分。至于控件样式的设计，较低版本(15063及以下)可以使用Blend，而较高版本，Blend不支持，需要创建控件样式的副本，手动修改XAML代码(我现在更倾向于这种方式)。

无论是使用Blend还是手动更改，都需要创建控件样式的副本。这个文案的依据是什么？基于系统的默认样式。系统的默认样式有一个严重的问题，以16299为例。

众所周知，在16299年，Win10采用了Fluent设计，很多控件的默认样式都进行了更新，增加了一个名为AcrylicBrush的笔刷，而在最新的17134中，它已经有了Reveal light效果。当这些特定版本支持的特殊样式内化为系统默认样式时，可悲的事情发生了:

一个你以为所有版本都会支持的基础控件，成了闪回的罪魁祸首。

原因是当你使用Win10的高配版本进行开发时，控件的默认样式已经不支持低配版本了，但是你并不知道这件事，所以你并没有修改控件的样式。这样的应用虽然名义上支持低配版，但是当低配版打开时，由于应用找不到对应的系统资源，无法渲染，所以闪退。

应用因为这个原因被闪退的情况并不少见，这往往是开发者没有仔细对比就强行添加新效果造成的。

但是你觉得这是开发商的原因吗？也许吧，但是微软也需要承担一些责任。更新你的控制，至少让我知道。即使不写任何更新说明，在创建默认样式时加一条波浪线，告诉我“当前软件的最低系统版本不支持此样式”，也是很好的。但遗憾的是，目前这种提示文字并不全面，还有一些样式没有列入提醒列表。

所以，在你已经捕捉到App.xaml.cs中代码的异常之后，如果应用仍然会闪回，那么你就要考虑这种风格的原因了。

个人博客地址:blog.richasy.cn。

,