一个仿windows泡泡屏保的实现
有天看到有人在百度知道上问windows 泡泡屏保该怎么用C#做，一时有趣，就做了一个出来，对于其中几个要点总结如下：
一，屏保程序的制作要求
屏保程序的扩展名是.scr, 但其实还是一个exe文件，只要把编译好的exe文件扩展名改为.scr，就变成了一个屏保了。
但做为屏保程序，也对之有一定的要求如下：
1.应该是一个全屏的、无边框的程序。
2.退出机制应该符合屏保的操作习惯，如动鼠标就退等。（我在这个例子里是用esc做退出。）
3.支持以下命令行参数：
/c , 显示选项对话框。
/p, 显示预览。
/s, 或不加参数：正常运行。
提醒注意一点: 当程序扩展名修改之后，.config配置文件也需要同时改名。比如原来叫popo.exe, 配置文件就是popo.exe.config, 当你把popo.exe改为popo.scr时，也要把配置文件改为popo.scr.config。
二，程序运行原理
接下来，就是要做一个全屏的泡泡程序了。原理如下：
1.程序启动时，先把当前的屏幕位图保存下来备用。
2.设计泡泡对象，记录自己的位置、大小、速度、颜色等。在设计时，我认为泡泡怎么动，怎么画都是泡泡自己该知道的，所以，把运行计算方法与绘制方法都放在泡泡类里了。另外，在计算时，泡泡需要参考环境因素来决定自己的运动状态，因此还带进去了一些环境参数。我这里就把屏幕大小和整个泡泡集合做为两个参数放进去了，如果需要的环境变量太多，可以做个环境类，把这些都包到一个环境对象里传递，或是做为全局变量来用。
3.做一个无框无内容、最大化、自绘制的form。
4.设置一个定时器。在触发时，逐一更新泡泡的运动状态。然后通知form进行重绘。
5.在form重绘时，先把保存下来的屏幕位图画到屏幕上，再调用泡泡自己的绘制方法，用gdi+作图。
三、gdi+绘图
绘图部分很简单，我就只画了个圆做泡泡，并把圆里面用线性渐变画刷刷了个从有颜色到完全透明色的效果，看起来也挺漂亮的。请看截屏。
如果用路径渐变画刷绘图，还可以做到园心透明的效果。但我没有继续改进这块儿。
关于透明色，可以用Color.FromArgb()方法来得到，第一个参数就是不透明度，只要设为0就是完全透明了，255为完全不透明。
四，两种计时器的不同
为了简化时间处理，我决定采用定时器的方法来做主循环。 一开始，我使用了一个system.form.timer, 也就是从工具栏里直接拖出来的那个timer，结果发现无论我怎么把interval搞多小，每秒都只会产生大约18次多一点的tick事件，屏幕更新率上也就最多18fps. 后来我想起来之前有看到过说这个定时器最大精度只有55ms，设再短都是55ms.
于是改用system.timer.timer做定时器。这个定时器不能从工具框里拉出来，只能在form里代码定义，在form_load里设置属性、委托事件，并启动。测试后发现它的最小精度似乎是15ms，不过这样也能达到每秒Elapsed上60多次，远超过人眼需要的24fps刷新率了。
五，winform的重绘效率
1.Form的OnPaint()调用机制
我是在定时器Elapsed时，对所有泡泡进行一次状态计算，然后调用form.Invalidate()，要求重绘整屏。进行测试后发现，60次计算是真实发生了，但OnPaint只重绘了40多次，也就是40fps，其中有20次Invalidate并没有产生重绘消息。这应该是windows对wm_paint消息的重复出现时的一种处理方式——上次paint没搞完，这次paint就又来了时，系统就放弃这次的paint消息了。
2.double buffered比位图复制的效率高
在用VC做绘图程序时，如果你直接在Paint事件里给你的Graphics句柄上绘图，这个绘图的过程就会被直接显示到屏幕上，一是造成闪耀，二是由于要向硬件发送绘制信息，绘图的效率也会变低（低得多！），所以习惯上会创建一个与所给的Graphics设备兼容的“内部”Bitmap对象，在这个内部Bitmap上进行绘制，完成之后再整个复制到Graphics句柄上去。由于是全覆盖，所以对原Graphics的句柄都不需要Clear()。
因此，在用C#的winform绘图时，我也习惯地用了这个方法。在最后优化帧率时却发现，这个方法并不是最快的！
在form对象里有个属性做doublebuffered，就是是否采用双显示缓冲区。如果设为True，.net就会给form维护两个显示缓冲区，当请你响应wm_Paint绘图时，给你一个后台的缓冲请你画，画完了，把这个画好的屏幕切换到前台来显示，把原来的前台切到后台备用于下一次paint。
有了这个机制，其实就不用自己来创建那个内部bitmap了，只要启用双缓冲方式，你就可以直管向onPaint方法里送来的那个Graphics上绘制就好，绘制的过程不会被实时显示到屏幕上。当你结束了OnPaint时，.net会把你画好的这个屏幕“翻”到前面去。也不会有闪烁。
实际的测试发现，使用单缓冲 + 自己维护内部bitmap绘图与复制的办法，要比启用双缓冲 + 直接在Graphics上绘图的效率要低上差不多30%。这应该是因为自己的内部bitmap最后要Draw到Graphics的过程是个位图复制过程，整屏内容数据量还是很大的。而双缓冲时，.net只是交换一个指针值就可以了。
六，碰撞算法
泡泡的运动状态参数，我用了Vx, Vy两个值来表示在水平方向和竖直方向上的运行速度，速度分为正负。这个设计在一些情况下简化了运动状态的计算处理。
1.撞边
撞边的检测很简单，就是看边缘座标是否超过屏幕大小，或是小于0。撞上下边时，修改Vy的值为-Vy; 撞左右边时，Vx = -Vx;
2.泡泡互撞
这个很头大，但终于自行搞定了。
我在一个泡泡计算运动时，逐个计算与其他泡泡两两碰撞的情况，原理就是计算两个园心的距离（d =( (x1 -x2) ^ 2 + (y1 - y2)^2) ^ 0.5）是否大于两个泡泡半径之和，如果不大于，d <= r1 + r2, 那么说明与这个泡泡发生碰撞。
碰撞之后，如果发现两个泡泡已经相交了，d < r1 + r2, 第一件事情就是先把两个泡泡移开到谁不挨谁的位置上，为了看起来正确一些，我决定按两圆心的延长线，把两个泡泡各向后移动重叠部分( r1 + r2 - d) 的一半距离。这种情况在两个时候很容易有，一是刚开始，泡泡的位置是随机的，有大量挤一起的，二是在运动中，一个泡泡如果速度太快，在一次计算周期里它移动的位置很可能已经让它超过另一泡泡的边界了。我现在想到只是移回到边界处也不是很对，应该弹回对应的距离才符合实际。
后来发现，各自回退一半距离时，有时会有某个圆的回退方向上会碰到其他圆，其他圆又会把它挤回原位置，这个循环引起了一些泡泡间的奇怪行为，还造成一些误差积累的问题。最后，我把规则改为只移动其中一个泡泡，这样就消除了这种问题。
然后，要计算两个泡泡的碰撞对两方产生的影响。
我先规定这些泡泡的重量都是相同的，以简化问题。然后，我推测自然界里的碰撞过程应该是一个动量（速度矢量 * 质量）交换的过程，交换的法则应该符合平行四边形法则，结合我Vx,Vy速度分量的设计，我分析了在两个正交方向上向对方输出动量的计算方法，比如下图是B圆的Vy动量向A圆Vy和Vx输出的分析：
如图：Vy向A圆的输出动量大小，应该是Vy在法线上的投影ObP, 这个投影是个矢量，正指向A圆圆心，也就是法线的方向。这个矢量被分解到两个正交方向上，就是Py和Px。
同样，Vx也要如此分解为两个方向上的分量(Px2, Py2)。
Px+Px2, Py + Py2, 需要都从Vx和Vy里减出去，加到圆A的Vx和Vy上。
以此类推，圆A的动量也要如此计算出要分给圆B的部分，并从自己的两个速度与动量中减出，加到圆B的两个动量里去。
最后的效果，看起来和现实情况比较符合。为了测试，我做了一个下面的布置，把5个球放一排，然后让两个球从左边撞过去，看看碰撞的效果如何，结果是右边也弹出了两个球，与现实相当符合：
3.多个泡泡同时撞到一起
两两相撞计算后，看起来也差不多了。没做更多处理。
4.效率问题
由于要两两计算，每一轮的计算量就是n*n次。一开始比较担心，但设置了30个泡，运行起来之后，发现大量的cpu时间是在绘图部分的，900次的碰撞检查几乎不占什么CPU比例，于是就算了。
5.难以彻底处理的问题
程序运行中，发现有一些误差被积累，或是在很多球球时，它们之间的相互作用就变得很复杂，行为有时有点怪异。仔细分析后，归结为两大原因：
一、 现实中，物体的运行状态是依时间连续发生的，实时的。而在计算机里，只能在离散的时间点上计算状态，这就会错过去很多事件，不得不加了一些纠正。这种事件错失与纠正行为会让物体表现得不太自然。
二、 现实中，物体间的相互作用是并行发生的，但在计算里，只能两两考虑，逐个处理，这也造成计算结果与现实环境不太一致。
这两大原因都是目前不太好完全解决的，最多只是精度修正，不可能完全消除。
七，如何实现不妨碍工作的屏幕泡泡?
最后，抛出一个问题：在这个程序里，背景部分是抓屏后绘出来的假屏幕。有没有可能让泡泡们在真正的屏幕上飘动，而且不影响当前的工作？
我想到把每个泡泡都作为一个真正的窗体来处理，以Top most方式运行，并设置window的剪裁区域为自己的形状，但是这样的话，这些窗口泡泡就会载到在它们上面发生的windows消息，似乎会影响下面的程序工作，比如点击到它们时，就让下面的窗口失去了焦点。
用系统钩子如何呢？
下载源码在这里： https://files.cnblogs.com/haoxiaobo/PopScreenSaver.rar
