电脑装配网

cs1.6闪退怎么解决(csgo闪退进不去)

 人阅读 | 作者yiyi | 时间:2022-09-28 14:05

UWP应用,全称或许可称Windows通用平台应用,是微软推出的新一代Windows应用开发模型。但是自推出以来,却饱受诟病,其中,易闪退是很多人对它的第一印象。今天,我们就来谈一谈UWP应用闪退的问题,并教你如何解决它。

本文所述是立于开发者角度,即从应用代码解决问题。而非处于用户角度,在应用之外解决UWP应用闪退的问题

大部分闪退的根源

UWP应用不是瓷娃娃,没那么易碎。“闪退”,归根结蒂其实是Windows对系统的保护,避免因应用而干扰到系统运行。这种处理方式是站在系统角度上的,但开发者和用户都不领情。

用户自不必说,应用闪退,极大地影响用户体验,闪退了几次就把软件卸载了,闪退的应用多了,连带着对整个UWP应用都讨厌上了。

而开发者也很纠结,用户抱怨出现闪退,可在开发者这里没办法复现,导致开发者调试困难,有时候也是不了了之。

那么大部分闪退的根源是什么呢?

一言以蔽之,就是出现了未捕获的异常,即UnhandledException

在写应用的时候,出现错误的原因多种多样,从大的架构设计失当,到小的出现了不安全的空(Null)值。这些错误,开发者有的可以在程序设计时就利用`try-catch`语句进行捕获,经验越丰富的程序员,设计时考虑到的可能异常就越多。但是人力有时穷,不可能方方面面都考虑到,而程序一旦在运行过程中出现了**未捕获的异常**,应用马上闪退,毫无二话。

照这样说,出现未捕获的异常似乎是再所难免的,可为什么有些应用基本不闪退呢?是它们的程序全身上下都是try-catch吗?

肯定不是啦~

解决未捕获的异常非常简单,即便算上大括号,也只需要5行代码就可以搞定。

如何一劳永逸地解决闪退问题

如上节所述,绝大部分闪退的根源是未捕获的异常。既然是未捕获,那我们把它捕获了不就完事了吗?

说起来简单,做起来……更简单!

每一个新建的UWP应用都有一个App.xaml的文件,其背后则有一个App.xaml.cs。

App.xaml.cs中包含着关于应用启动、暂停等应用层级的操作逻辑,这个我相信各位开发者都是知道的。而所有未捕获的异常,最终都会冒泡到这里,所以这里是最后一关。换句话说,我们只要在这里设一道卡,抓住这个异常,不让它触发闪退机制就万事大吉了。

App类派生自Application类,且自带了一个事件,就是UnhandledException,说明是**当异常可由应用程序代码处理,如从本机级别的Windows运行时错误转发时发生。应用程序可标记事件数据中处理的匹配项**。

换句话说,人家早就想到会有闪退这种情况,已经预先把这个事件给你定好了。那我们要做的就非常简单了。

首先,在App的构造函数里加上

this.UnhandledException = OnUnhandledException;

给这个事件绑定上一个处理函数。

接下来,我们就来写这个处理函数:

private void OnUnhandledException(object sender, Windows.UI.Xaml.UnhandledExceptionEventArgs e)

{

e.Handled = true;

}

就这样,因出现未捕获的异常而造成的闪退就解决了,这个原因的闪退占了总体的九成以上。可以说,接下来,只要你的应用不作死,不故意写点死循环,不搞不安全的骚操作,基本上就不会再闪退了。

闪退问题的后续处理

出现闪退,意味着程序有错误未捕获。既然有错误,那就要解决。单靠一个e.Hanled=true;……

这种粗暴的解决方式虽然能够一次性解决闪退问题,但是治标不治本(虽然用户并不清楚,但实际使用体验却有了不少的提升)。作为软件的设计者,我们依然需要知道具体是哪里出现了问题,错误的原因是什么,这就涉及到了异常的后续处理。

如果你做的应用上架到了微软应用商店,那么在微软应用商店的后台,会记录你的软件在用户处的使用状况,而当出现异常的时候,也会上传到你的软件后台,这样就方便管理了:

你可以在后台观察出现的异常,然后在程序里解决它。

但是凡事总有例外,微软应用商店也不能捕获所有的异常并加以分析,这里分享一个例子:

我在开发WFA的时候,遇到过一个棘手的问题,Win10 14393的用户在打开应用设置时应用会闪退,而更高版本的则不会。当时在应用商店后台查看时,它也不知道原因,显示一个Unkonwn Exception,这我就很尴尬了啊。

百思不得其解的情况下,我在App.xaml.cs的异常捕获函数中加了个小东西,即捕获到异常后,将异常的解释传到我的数据库里。通过这样的方式,我很快找到了问题的成因,即AutoSuggestBox控件的某个样式在14393系统中不支持,这导致应用无法渲染,直接闪退了。

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

小小总结一下,闪退异常的后续处理可以通过两种方式来解决:

• 一种是依赖微软应用商店的异常上传机制,这种方式便于管理;

• 当前种处理方式不能满足需求时,可以在App.xaml.cs中的异常捕获函数里进行本地处理,将更为详细的信息上传到你的数据库中,便于你进行分析。

不过要注意,由于发布的安装包基本都是Release的,异常捕获不会有Debug时那样精准,有时候也需要自己根据情况进行分析。

第二种闪退原因

闪退原因可分为两部分,一种是我前面讲的代码中出现了未捕获的异常,而另一种,则是应用渲染无法获取到对应资源,这一点就尤其显示出UWP开发平台的不成熟性了。

这种原因说白了其实就是“样式引起的闪退”,这个在我前面分享的WFA的例子中也提及过。

开发过UWP应用的同学对于控件样式应该不陌生吧。这个是UI的关键部分。而控件样式的设计,低版本(15063及以下)可以使用Blend,而更高版本,Blend尚未支持,就需要自己创建控件样式的副本,手动对XAML代码进行修改(我现在已经更偏向于这一种处理方式了)。

不论是利用Blend还是手动改,都需要创建控件样式的副本,这个副本依据什么创建的呢?依据的是系统默认的样式。而系统默认的样式有一个很严重的问题,以16299为例。

众所周知,在16299中,Win10采用了Fluent Design,很多控件的默认样式都进行了更新,添加了一种名为AcrylicBrush的笔刷,而在最新的17134中,则有Reveal光效。当这些仅特定版本支持的特殊样式被内化到系统默认样式中,一件凄凉的事情就发生了:

一个最为基础的控件,你认为的各个版本都会支持的控件,却偏偏成了闪退的罪魁祸首。

原因就在于你使用高版本Win10进行开发时,控件的默认样式已经不再支持低版本了,而你却对此并不了解,导致你没修改控件的样式。这样的应用做出来,虽然名义上支持低版本,但是低版本打开后会因为应用找不到对应的系统资源而无法渲染,因此闪退。

因这种原因而闪退的应用也屡见不鲜,很多时候都是开发者没有经过认真比对而强行上新的效果造成的。

但是你说这个是开发者的原因吗?或许是,但微软也需要承担一定的责任。你控件更新就更新吧,好歹告诉我一声啊,就算没写什么更新说明,那么在创建默认样式时,加个波浪线,告诉一声“该样式在当前软件的最低系统版本中不受支持”也好啊。但很可惜的是,目前这种提示文字有,但不全面,仍有一些样式没有被包括在提醒列表之内。

所以,当你在App.xaml.cs中完成了对代码的异常捕获后,如果应用依然会出现闪退,那么你就要考虑一下这种样式原因了。

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


文章标签:

本文链接:『转载请注明出处』