最近跟售后经理吃饭，他跟我再次谈起两年前为公司临时写的一个客户端，仍然非常激动的跟我说，这个客户端完爆了公司其他版本的客户端，包括最老的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组件部分异步加载，给出正在加载的提示即可，可以立即显示“选择”按钮，这样体验性立即上升了一个层次。

延迟加载

延迟加载是指用到的时候，再去进行实际的构建。