Dot Net屏幕传输 v1.0

      上一次介绍了图像差异比较的方法，原想进一步修改算法，采用动态分块的实现方式。但是，“内心觉得不够宁静”，于是乎，打算先根据图像差异的实现算法实现屏幕传输功能。

      按照我的惯例，先来预览下效果图：

图1 屏幕传输效果图

      程序说明：本程序只适用于局域网。整个程序包含两部分，其中“屏幕分享 v1.0“ 为Control端，用于截取屏幕图片后将差异发送给Client端。屏幕分享终端为Client端，用于接收Control端发送过来的屏幕，并绘制在当前窗口。要想得到效果，必须先选择终端菜单中的“启动”按钮，而后配置Control端的IP信息后选择连接，便可以进行屏幕传输。

      开发工具：VS.NET 2008
      开发语言：C#
      开发测试平台：Windows XP sp2、Windows XP sp3、双核

      正 文

      原以为很简单，但是从着手到今天写博客已经花了近一星期的时间。其中大部分时间都花在了性能调整上，即使是我今天发布的1.0版本，性能上也是相当不尽人意。我的屏幕传输程序分为Control端和Client端：Control端负责截取屏幕，然后发送到Client端。

      将这两端分别置于局域网内两台机器上运行后发现，Control端在我的实验机（双核）上占内存接近54M，Client端占内存45M；如果图片差异大，则Control端占20%左右的CPU，而Client端可能会占到50%的CPU；如果差异小，则Control端占10%左右的CPU，而Client端最低占11%的CPU。而屏幕传输的延迟一般在0.3秒左右。（上述数据会因为具体的配置不同而不同）

      经过反复测试，发现Control端的主要性能瓶颈就在于这个差异算法，因为该差异算法需要0.11秒才能找出一个差异（差异较大的情况），利用while循环进行差异的不断查找，如果不在循环内设法让线程睡上一会时间，则CPU会占到70%，而我的解决方案就是让线程睡眠0.1s，但很明显，0.1s使得帧频一下子变成了原来的1/2。而Client端的主要性能瓶颈则在于循环接收的这个过程，我目前采用的是TCP的传输协议。

     目前看来，该版本的屏幕传输不管是在性能还是在效果上可能都不一定比得上直接整屏的截图发送（当前的差异算法还会产生不少的碎片），但是在整个传输过程中带宽的占用明显小于整屏截图。下一步的工作重点，我将主要改进差异算法及传输过程，也希望大家多多指点。

     好了，要说的基本上就这么多了。主要的代码在上一篇文章中也已经提到了（为了用于屏幕传输做了些细微的调整，其中主要就是调整了在捕获到差异后的处理流程。）

     项目打包下载：http://files.cnblogs.com/stg609/ScreenShare.rar

作者：stg609
出处：http://stg609.cnblogs.com/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。