近期跟售后经理吃饭，他跟我第三谈起两年前为公司临时写的一个推广客户端，仍然很激动的跟我说，这个推广客户端完爆了公司其他版本的推广客户端，包含最老的Delphi写的，Asp.Net写的，与最新的Wpf写的推广客户端。无论是多么大的界面(集成的机房多)，这个系统都是瞬间打开，而且运行很稳定，一旦成功部署之后基本没任何问题。
这个版本的推广客户端仅仅只不过一个临时替代的版本从四分钟到两秒：我的推广客户端性能优化实践不是非得你有多么牛逼的技术，才能做出一个稳定迅速的系统，更多的时候，它取决于你是不是有一个商品的意识，是不是叫你的软件真的贴近用户。
系统界面与功能
先来看看原来的系统界面是如何子的从四分钟到两秒：我的推广客户端性能优化实践
整个系统的物理构造是如此的从四分钟到两秒：我的推广客户端性能优化实践
按需刷新界面上的数据
做监控系统，除去告警页面需要实时公告到顾客外，监控数据界面，其实仅需展示目前显示页面的数据即可。
如何做呢，大家可以提供一个单独的程序来管理所有接收到的数据，然后再提供一个获得目前数据的接口给推广客户端，具体请看下面更改的构造。
有的人或许会疑问，为何不直接在采集器中提供这个接口呢？由于这是组态界面，界面上的控件要取什么采集器的数据是未知的，所以把数据放在一块统一管理会愈加便捷。而且采集器可以7*24小时工作，而推广客户端是常常要打开关闭的……
VS2010中的反例
假如用过VS2010开发自概念的Winform组件，那样大伙对它的工具箱加载自概念组件这个功能一定印象深刻，每次选择添加项，然后选择自概念控件dll的时候，都很痛苦，特别我电脑比较忙而又装了不少插件的状况下，为了一个很简单的功能，我需要花费4分多的时间来打开那个选择文件的界面，这个界面加载了一大堆我绝大部分时候都用不上的COM组件，我实在没法想象开发这个功能的程序猿是如何想的。还好，在VS2013中Microsoft总算是改进了这个功能，但做得还不够。按我的想法，完全可以把COM组件部分异步加载，给出正在加载的提示即可，可以立即显示“选择”按钮，如此体验性立即上升了一个层次。
延迟加载
延迟加载是指用到的时候，再去进行实质的构建。
