GUI的程序有时候会因为等待一个耗时操作完成,导致界面卡死。本篇我们就UWP开发中可能遇到的情况,来讨论如何优化处理。

  假设当前存在点击按钮跳转页面的操作,通过按钮打开的新页面,在初始化过程中存在一些耗时的操作。

        public void OnNavigatedTo(object obj)
{
var watch = new Stopwatch();
Debug.WriteLine("---------------Start");
watch.Start(); //假设耗时1秒
DoBusyWork();
//耗时1秒
int count = GetPersonCount();
//假设每创建一个Person耗时500毫秒
PersonList = CreatePersonList(count); watch.Stop();
Debug.WriteLine(watch.ElapsedMilliseconds);
Debug.WriteLine("----------------Stop"); Notify = "页面初始化已完成!计时:" + watch.ElapsedMilliseconds + "毫秒";
}

  可以注意到以上方法都是顺序同步执行完成的,在点击跳转按钮后,会有一个明显的卡死且非常尴尬的等待过程。GetPersonCount方法返回100这个数字的话,StopWatch记录的用时会是大约7秒,在这7秒之后才会打开跳转的页面,这是一个无法忍受的时间。

  优化的初步思路是将无需等待完成的操作放到非UI线程去做。这里发现DoBusyWork这个方法是可以剥离开的。

  Task.Run(()=> { DoBusyWork(); });

  写完之后发现虽然减少了1秒,但是意义不大,还是很卡。而PersonList的赋值操作必须在UI线程执行,不能够用Task来放到后台,这一步的优化貌似到这里就没辙了。

  接下来的思路是采用async和await这对关键字来进行异步编程,首先我们要明确使用了await的语句仍然是会阻塞并等待完成,才可以执行下一句的。不同的是程序会在await的时候yeid return一次,以使得UI线程保持响应。但错误或者不合适的使用await往往会导致意想不到的结果,甚至比同步执行更差的性能。我们先看第一版的异步程序:

        public async void OnNavigatedTo(object obj)
{
var watch = new Stopwatch();
Debug.WriteLine("---------------Start");
watch.Start(); //不必要的等待,耗时1秒
await DoBusyWorkAsync();
//耗时1秒,返回数字100
int count = await GetPersonCountAsync();
//依然会造成长时间阻塞的Get方法
PersonList = await CreatePersonListAsync(count); watch.Stop();
Debug.WriteLine(watch.ElapsedMilliseconds);
Debug.WriteLine("----------------Stop"); Notify = "页面初始化已完成!计时:" + watch.ElapsedMilliseconds + "毫秒";
}

  运行发现,Navigate到第二个页面很快(这是await的功劳),但是等到PersonList完全加载出来,仍然耗时7秒。这里的第一个错误是不必要的await DoBusyWorkAsync这个方法,应该果断去除await关键字,虽然Visual Studio会给出warning:“由于此调用不会等待,因此在此调用完成之前将会继续执行当前方法。请考虑将 "await" 运算符应用于调用结果”。但仔细想想会发现我们的本意就是不等待该方法。如果想去掉该提示,可以考虑将DoBusyWorkAsync方法的返回值由Task改为void。

        private async void DoBusyWorkAsync()
{
await Task.Delay();
}

  改为void之后在捕获异常时可能会没有堆栈信息,考虑到这里是个简单方法,就不用顾虑了。

  CreatePersonListAsync方法依赖于GetPersonCountAsync的返回值,这种情况下没有太好的优化方案。只能说GetPersonCountAsync的这一秒你值得等待。

  至于CreatePersonListAsync方法本身的耗时达到了5秒,成为了性能瓶颈,对该方法进行分析:

        private async Task<ObservableCollection<Person>> CreatePersonListAsync(int count)
{
var list = new ObservableCollection<Person>();
for (int i = ; i < count; i++)
{
var person = await Person.CreatePresonAsync(i, i.ToString());
list.Add(person);
}
return list;
}

  可以看到阻塞发生在for循环的内部,每次 await Person.CreatePresonAsync都有500毫秒的等待发生。而实际上每个create preson的操作是独立的,并不需要等待前一次的完成。代码修改如下:

        private ObservableCollection<Person> CreatePersonListWithContinue(int count)
{
var list = new ObservableCollection<Person>();
for (int i = ; i < count; i++)
{
Person.CreatePresonAsync(i, i.ToString()).ContinueWith(_ => list.Add(_.Result),TaskScheduler.FromCurrentSynchronizationContext());
} return list;
}

  修改后运行效果还挺不错的,首先页面间的跳转不再卡顿,同时PersonList的加载时间也有了明显的缩短,在“页面初始化已完成”这句话出现后很短的时间内,列表便加载完毕,不过仔细观察发现元素的顺序是错乱的。

  

  这是因为for循环里CreatePersonAsync的操作相当于并发进行,添加到List里的顺序自然是不固定的。我们可以在插入前进行排序来修正。

        private ObservableCollection<Person> CreatePersonListWithContinue(int count)
{
var list = new ObservableCollection<Person>();
for (int i = ; i < count; i++)
{
Person.CreatePresonAsync(i, i.ToString()).ContinueWith(_ => {
var person = _.Result;
int index = list.Count(p => p.Age < person.Age);
list.Insert(index, person);
},TaskScheduler.FromCurrentSynchronizationContext());
} return list;
}

  至此程序才算有了一个比较好的效果,有两点可以总结一下:

  1. 通过Task.Run将非UI相关的操作运行在后台线程上,减少不必要的等待时间
  2. 通过将耗时操作拆分成N个await返回的异步方法,可以使UI线程保持响应

  GitHub:https://github.com/manupstairs/UWPSamples/tree/master/UWPSamples/KeepUIResponsive

UWP开发入门(二十一)——保持Ui线程处于响应状态的更多相关文章

  1. UWP开发入门(十一)——Attached Property的简单应用

    UWP中的Attached Property即附加属性,在实际开发中是很常见的,比如Grid.Row: <Grid Background="{ThemeResource Applica ...

  2. UWP开发入门(十七)——判断设备类型及响应VirtualKey

    蜀黍我做的工作跟IM软件有关,UWP同时会跑在电脑和手机上.电脑和手机的使用习惯不尽一致,通常我倾向于根据窗口尺寸来进行布局的变化,但是特定的操作习惯是依赖于设备类型,而不是屏幕尺寸的,比如聊天窗口的 ...

  3. UWP开发入门(十)——通过继承来扩展ListView

    本篇之所以起这样一个名字,是因为重点并非如何自定义控件,不涉及创建CustomControl和UserControl使用的Template和XAML概念.而是通过继承的方法来扩展一个现有的类,在继承的 ...

  4. UWP开发入门系列笔记之(一):UWP初览

    标签: 随着微软Build2015带来的好消息,Win10正式版发布的日子已经离我们越来越近了,我们也终于欣喜地看到:一个统一的Windows平台对于开发人员来说充满了吸引力,这局棋下的好大的说--于 ...

  5. UWP开发入门(十六)——常见的内存泄漏的原因

    本篇借鉴了同事翔哥的劳动成果,在巨人的肩膀上把稿子又念了一遍. 内存泄漏的概念我这里就不说了,之前<UWP开发入门(十三)——用Diagnostic Tool检查内存泄漏>中提到过,即使有 ...

  6. UWP开发入门(四)——自定义CommandBar

    各位好,再次回到UWP开发入门系列,刚回归可能有些不适应,所以今天我们讲个简单的,自定义CommandBar,说通俗点就是自定义类似AppBarButton的东西,然后扔到CommandBar中使用. ...

  7. UWP开发入门(25)——通过Radio控制Bluetooth, WiFi

    回顾写了许久的UWP开发入门,竟然没有讲过通过Windows.Devices.Radios.Radio来控制Bluetooth和WiFi等功能的开关.也许是因为相关的API设计的简单好用,以至于被我给 ...

  8. Java并发(二十一):线程池实现原理

    一.总览 线程池类ThreadPoolExecutor的相关类需要先了解: (图片来自:https://javadoop.com/post/java-thread-pool#%E6%80%BB%E8% ...

  9. Directx11学习笔记【二十一】 封装键盘鼠标响应类

    原文:Directx11学习笔记[二十一] 封装键盘鼠标响应类 摘要: 本文由zhangbaochong原创,转载请注明出处:http://www.cnblogs.com/zhangbaochong/ ...

随机推荐

  1. 在PHP中使用Mysqli操作数据库

    PHP的 mysqli 扩展提供了其先行版本的所有功能,此外,由于 MySQL 已经是一个 具有完整特性的数据库服务器 , 这为PHP 又添加了一些新特性 . 而 mysqli 恰恰也支持了 这些新特 ...

  2. myrocks 之数据字典

    data dictionary rocksdb作为mysql的一个新的存储引擎,在存储引擎层,会维护自已的元数据信息.在innodb存储引擎中,我们通过information_schema下的INNO ...

  3. 桌面 透明 三角形 分层窗口 DX

    //桌面 透明 三角形 分层窗口 DX //IDirect3DSurface9 GetDC UpdateLayeredWindow #include <Windows.h> #includ ...

  4. C#函数式编程

    提起函数式编程,大家一定想到的是语法高度灵活和动态的LISP,Haskell这样古老的函数式语言,往近了说ruby,javascript,F#也是函数式编程的流行语言.然而自从.net支持了lambd ...

  5. [stm32] STM32 Interrupts and events 系统了解(EXTI)及槽型光电开关tp850电路研究

    中断和事件 1 嵌套向量中断控制器 特性: ● 68个可屏蔽中断通道(不包含16个Cortex™-M3的中断线):● 16个可编程的优先等级(使用了4位中断优先级):● 低延迟的异常和中断处理:● 电 ...

  6. WaterfallTree(瀑布树) 详细技术分析系列

    前言 WaterfallTree(瀑布树) 是最强纯C#开源NoSQL和虚拟文件系统-STSdb专有的(版权所有/专利)算法/存储结构. 参考 关于STSdb,我之前写过几篇文章,譬如: STSdb, ...

  7. jQuery实现在线文档

    1.1.1 摘要 现在,许多网站都提供在线图片和图书阅读的功能,这种方式比下载后阅读来的直观和人性化,要实现该功能涉及到点击处理和图片动态加载. 在接下来的博文中,我们将通过Javascript方式实 ...

  8. Java的一个高性能快速深拷贝方法。Cloneable?

    本人在设计数据库缓存层的时候,需要对数据进行深拷贝,这样用户操作的数据对象就是不共享的. 这个思路实际上和Erlang类似,就是用数据不共享解决并发问题. 1. 序列化? 原来的做法,是用序列化,我用 ...

  9. P,NP,NP_hard,NP_complete问题定义

    背景:在看李航的<统计学习方法时>提到了NP完全问题,于是摆之. 问题解答:以下是让我豁然开朗的解答的摘抄: 最简单的解释:P:算起来很快的问题NP:算起来不一定快,但对于任何答案我们都可 ...

  10. WebApi系列~开放的CORS,跨域资源访问对所有人开放

    回到目录 之前有客户问我,如何AJAX跨域post,这个问题挺有意思,在我们看来,我是不被允许的,因为它是不安全的,但随着web api的火热,这个东西也被人们一步步的接受了,确实,有时,我们的接口希 ...