从四分钟到两秒:我的客户端性能优化实践
2020-12-04 来源:博客园
最近跟售后经理吃饭,他跟我再次谈起两年前为公司临时写的一个客户端,仍然非常激动的跟我说,这个客户端完爆了公司其他版本的客户端,包括最老的Delphi写的,Asp.Net写的,以及最新的Wpf写的客户端。无论是多么大的界面(集成的机房多),这个系统都是瞬间打开,而且运行非常稳定,一旦成功部署之后基本没有任何问题。
这个版本的客户端仅仅只是一个临时替代的版本:原来的Delphi客户端实在是太慢了,在大型的数据中心监控中需要4~5分钟才能进入主监控界面,而asp.net版本的客户端又经常存在不稳定的情况(IE浏览器不支持7*24小时的异步刷新),最新的Wpf客户端又还在设计阶段,于是临危受命决定开发一个临时过渡版本,当时也只是开发了一个月,没想到竟然如此成功,至今仍让我们的售后部门津津乐道。这中间其实没有太多高深的技术,但是却有很多的开发技巧以及编程的思想。我至今仍然看到很多人都在犯这么一些简单的错误(例如VS2010工具箱的加载项),导致他们的系统非常缓慢,但是他们却总是抱怨是编程语言的问题,是windows系统的问题,是机器的性能不行……
我决定把我的一些实践经验跟大家分享:不是非得你有多么牛逼的技术,才能做出一个稳定快速的系统,更多的时候,它取决于你是否有一个产品的意识,是否让你的软件真正贴近用户。
系统界面与功能
先来看看原来的系统界面是怎样子的:
其功能如下,我新写的客户端增加了支持生成OCX控件的功能:
整个系统的物理架构是这样的:
原系统存在的问题
- 加载主页面慢
- 随着界面数量的增加,会需要更多的加载时间
- 随着地点和设备的增加,加载会需要更多的时间
- 页面之间切换卡
- 数据显示慢
- 地点的报警状态显示不准确且存在延迟
- 报警并发较多时卡顿更严重
客户端性能优化的基本手法
我们来看看通过一些什么手法能够解决原来的系统存在的这些问题。
按需获取
大部分的情况下,我们其实所能看到的东西都是极其有限的,无论系统是多么庞大,功能多么的丰富,其实呈现给用户的都是极其有限的。
监控界面的按需获取
前面说了,监控主界面里的界面都是组态的,是由工程师拖拉控件上去实现的,大家也看到上面图形还算丰富,主要是使用了大量的图片,因此我们系统中在保存这些组态界面的时候,同时也保存了界面图片的字节流。大型的数据中心由于界面较多,这些界面加起来是可能会超过1G大小的。这么大的界面,如果都是直接加载到界面中,首先就要费不少的时间,即使是在内网的情况下,假设你网络能够1s下载20M左右,也要50秒,接近1分钟,遇上网络高峰,花个1~2分钟并不奇怪。
我们是否有必要把所有界面都加载进来呢,当然没有。我们只需加载第一个界面,其他界面在需要的时候(用户点击或者发生告警需要跳转的时候)才加载,这样我们的速度里面就提升了,这就是按需加载!
当然说的轻巧,实际做的会有很多问题。比如,如何实现不实现页面又能知道该页面是否告警(必须解析每个界面上的控件,才能知道某个界面包含了哪些控件,才知道监控指标告警在哪个界面上)?
我的步骤如下:
- 保存界面的时候,把界面上的控件的Id列表存储到设备记录中
- 加载时只加载所有的设备记录(名称+控件Id列表)
- 把对应的信息附加到树形节点中
- 根据对应的树形节点的告警信息在需要显示界面时生成界面
按需刷新界面上的数据
做监控系统,除了告警页面必须实时通知到客户外,监控数据界面,其实只需展示当前显示页面的数据即可。
怎么做呢,我们可以提供一个单独的程序来管理所有接收到的数据,然后再提供一个获取当前数据的接口给客户端,具体请看下面更改的架构。
有些人可能会疑问,为什么不直接在采集器中提供这个接口呢?因为这是组态界面,界面上的控件要取哪个采集器的数据是未知的,所以把数据放在一起统一管理会更加方便。而且采集器可以7*24小时工作,而客户端是经常要打开关闭的……
VS2010中的反例
如果用过VS2010开发自定义的Winform组件,那么大家对它的工具箱加载自定义组件这个功能肯定印象深刻,每次选择添加项,然后选择自定义控件dll的时候,都非常痛苦,尤其我电脑比较忙而又装了不少插件的情况下,为了一个非常简单的功能,我需要花费4分多的时间来打开那个选择文件的界面,这个界面加载了一大堆我绝大多数时候都用不上的COM组件,我实在没法想象开发这个功能的程序猿是怎么想的。还好,在VS2013中微软总算是改进了这个功能,但是做得还不够。按我的想法,完全可以把COM组件部分异步加载,给出正在加载的提示即可,可以立即显示“选择”按钮,这样体验性立即上升了一个层次。
延迟加载
延迟加载是指用到的时候,再去进行实际的构建。
标签: 突Ф擞呕
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。