简介
最近需要做一个辅助项目，控制一个简单的flash游戏，总共有三步：
1. 等待开始。
2. 操作，确认操作成功或失败。
3. 等待结果，重复第1步。
我到网上搜索了一些控制flash的高级方法，如获取传输数据，模仿之与服务器通信，由此代表客户端的操作。思想很简单暴力，但是由于我没有此类的经验，也没有太多时间去研究，故此放弃了此方法。又之前看到别人控制iphone的App使用图片识别的方式，而我又熟悉windows的此类API，所以决定采用图片驱动的方式。
图片驱动带来了一些问题：
1. 图片获取问题。
2. 图片识别的效率问题。
3. 图片识别的内存大小问题。甚至一些图片API的知识壁垒问题。
4. 处理变化的能力，容差问题。
系统预览
首先，循环有三步，就必然有三张图片：（1）开始状态图片，（2）操作状态图片，（3）结果状态图片。当图片匹配上当前状态时，根据状态结果进入下一个状态，当有异常时通知相关人员处理。
系统有4个模块：（1）图片处理模块，（2）动作模块（根据不同状态结果，进行不同动作），（3）状态模块（每张图片代表的状态，以及匹配的动作），（4）框架，循环引擎，根据状态调用不同的动作，及获取图片来驱动状态变化。
我根据这些模块，把各个子动作，子图片，及状态，状态循环由一个json文件描述。
```json
{
"base":"base information"
"facets":[]
"actions":[]
"states":[]
"engine":{
"states":[]
}
}
```
系统实现
由于把所有功能都变成小王国，因此考虑好具体参数，扩展参数就能轻松实现小王国了。这里就具体说一下图片处理模块，及循环引擎的实现
1. 引擎
引擎安装配置文件，不停的获取图片（由facet提供），识别图片（由facet提供），匹配图片（由facet提供），完成动作（由action提供），移动状态，及错误处理。
辅助功能：提供中途暂停（需由不同功能而定，这比较复杂，涉及上下文（context）重构），或者结束。异常处理，比如一个状态上等待时间超过阈值（valve）等。日志的打印。
我使用了一个简单方式，单独建立一个循环线程去驱动，这个线程处于无限循环中，直到外部停止或者满足跳出循环条件。
2. 图片处理
图片处理又分为图片获取，图片识别。
图片获取：Windows最简单的图片获取方式为：
（1）类似Weixin，QQ截图方式，采用Graphics.CopyFromScreen方法获取图片。然后再根据你需要图片的位置，大小copy出你需要的图片。copy出的图片一定是只有你需要的地方，而不是整个屏幕。
（2）采用Win32 API的方式。
获取Window Handle: 直接获取方式（大部分傻瓜式辅助程序）：FindWindow, FindWindowEx, EnumWindows, 手动获取方式（程序员使用工具，如Spy++）WindowFromPoint
获取窗口截图：GetDC获取Draw Handle，BitBlt拷贝窗口画面（选择你需要图片的相对位置），
图片处理：如果图片比较规律，可采用特定点的颜色值来确认。如果图片文字较多，可采用OCR识别技术（需要内存，及长时间）。当然也可以采用高手自己造轮子的方式。OCR识别推荐用Tesseract。
我由于flash简单，图片规律，故采用了比较高效暴力的特定点颜色识别来确认。
结语
没有太多详细代码的东西，只是把这个简单系统写下来。一是自己梳理一遍，加深印象，排查潜在bug。二是供有缘人看一看。根据现有情况看：添加到新的浏览器很简单，在网络稳定的情况下，能够长时间稳定的运行。
由于项目原因，无法根据具体情况，来写具体代码的选择，实属无奈。
由于之前没有找到Markdown编辑器选项，导致排版失误。
