一个更易懂GAutomatorAndroid脚本和开源的GAutomatorView

概述

我的工作受惠于腾讯的GAutomator自动化框架，这套框架给自动化带来了很多便利。这套工具功能没有Airtest的多，但是代码结构相对简单，容易定制化开发，而且对于需要快速连点的战斗场景自动化很友好（关于这一点已经在之前的博客里面讲过了，提到了为什么在想尝试转型Airtest最后又弃坑的原因）。

Anyway，这里有两个开源代码：
qintianchen的GAutomatorAndroid 和 qintianchen的GAutomatorView。

GAutomator

第一个仓库是从tencent GAutomator直接fork过来的，改了GAutomatorAndroid的部分。因为里面自带了对wetest远端report的功能，代码结构比较混乱，然后整理了一版，优化了日志打印，代码结构；修改了Device的API，用来支持与sdk无关的操作。

这其中涉及到一些游戏自动化的哲学。目前自动化没有很难开发一套统一的框架，原因就是因为游戏控件复杂，而且多变。目前有两套比较主流的自动化思路：基于图像识别的控件识别，和基于游戏控件路径的控件获取。

网易继承了sikuli和poco的理论，开发了Airtest，在图像识别上做的比较好。然而对于需要精准控制和高速控制的自动化需求就显得捉襟见肘了。因为控件识别和场景识别依然存在不小的错误率，而且单次的图像识别至少需要这么几个步骤：截图，图像处理，发送操作命令。用过adb shell screencap 的伙伴一定知道截图的速度是多么的感人。所幸的是，Airtest在内部提供除adb原生截图方法以外的另外两种方法：minicap和javacap。其中minicap截图速度能够达到50ms以内。然后就是图像处理。图像处理是很慢的，因为设计一套特征规则，然后提取特征进行识别。唯一让计算机能够对复杂场景进行精准识别的方法就是提前训练，正如新生儿无法判断一个画面中什么是控件什么是3D模型一样，都是需要后生训练的。而训练就需要海量的数据和庞大的计算资源。这对于一些小公司而言不是一笔划算的买卖。如果一次操作（截图，图像处理，发送操作命令）超过了某种阈值，那很多自动化的操作就比较难实现了，比如你需要两次点击间隔小于200ms才能触发“连击技”，但是你单词操作就将近一秒的时候，连击压根儿释放不出来。

GAutomator没有图像识别的功能（不过这个fork的版本我后来会加上去），它需要嵌入sdk，来获取游戏的信息。而且GAutomator还对sdk做了很多优化，在复杂的控件树中精准查找或者模糊查找控件的时间都不会超过5ms。它的缺点就是你不能自动化地跑没有源代码的项目，因为你不能给它嵌入sdk。而且编写代码略微比较繁琐。而且客户端对控件的命令规则有可能非常糟糕，导致你在决策如何获取控件路径，获取什么控件路径的时候十分头疼。但是排除以上困难，它的高性能还是非常吸引人的。

GAutomatorView

第二个仓库就是GAutomatorView的开源版本。因为GAutomator依赖控件获取，但是作为测试人员，你有可能没有权限拿到项目源码，然后用引擎打开，再获取它的控件。GAutomatorView就是这样的一套工具，帮助你在嵌入了sdk的游戏上获取游戏控件的全路径。

工具会获取当前游戏的控件树和截图，当你点击图中某个地方时，如果那个地方存在一个可见的控件，GAutomatorView就会给你在图中标出来，同时在控件树中定位该控件。

但是这工具实际用起来有许多问题，最大的问题就是在多设备的情况下，它拿到的控件树和截图永远是第一个设备的信息。为此，我每次需要拿控件的时候，都需要把其他设备断开连接才行。而GAutomatorView不开源，官方也很久不更新了。在忍受了半年之后，终于下决心自己做一个。源码就开放在上面的github仓库中，里面也有打包好的exe可执行文件。除了原版GAutomatorView的基础功能之外，还修复了原版的问题，添加了控件路径自动添加到剪贴板的功能，不用每次都麻烦地去手动选择复制。

除此之外，还有另一个仓库 UnityDemo-TestGAutomatorView，这个仓库从Assets商店上下了一个UGUI的Demo，然后加了一个场景转换的功能。并且仓库里面有打包好的apk，嵌入了sdk，可以专门用来测试这个工具。