大家可能会觉得奇怪，为什么启动目标设备端的monkey进程会放在“运行测试脚本”这一节之后来阐述。
纵观前面整个MonkeyRunner的启动流程，我们看到并没有提及到monkey进程启动的地方。那么就奇怪了，monkey是什么时候被MonkeyRunner启动起来的呢？
我们的测试脚本一开始时几乎毫无例外的都需要执行一个调用:MonkeyRunner.waitForConnection(),如果有多个设备连接到主机的话还需要指定设备序列号，还可以指定等待连接的Timeout时间,比如:MonkeyRunner.waitForConnection(“xxx”,10000)，其中xxx代表序列号，10000代表超时Timeout时10秒；如果没有指定参数的话框架会提供默认的参数。其实monkey的启动就是在waitForConnection的一些列调用中完成的。
MonkeyRunner调用waitForConnection的目的是什么呢？顾名思义，当然是等待连接上设备了。但是细想下觉得又不对，在上面MonkeyRunner启动运行过程中，不是已经在启动设备监控线程DeviceMonitor中创建了代表目标设备的Device类型的mDevices列表了吗？表明设备已经连接上来了啊。这时就算我们不运行任何monkeyrunner脚本，发送“adb devices”命令也能够列出来所有已经连接上来的设备了。那么难道waitForConnection起名字Google给起错了吗？其实不是的，这里waitForConnection确实是在等待设备的连接，只是等待的不是上面Device设备的连接，因为确实这个设备在启动设备监控线程的时候已经连接上来的了，这里等待的是去连接上AdbChimpDevice这个设备。这里大家可能迷糊了，这又是什么设备啊？这里其实有几个抽象设备类(抽象设备类在这里的意思不是说这些类是抽象的，而是说这些类代表的设备是真是设备在主机端的一个虚拟抽象)，如果我做如下的解析大家应该就很好理解了:
Device(ddmlib):代表的是通过ADB进行控制的设备
ChimpManager(chimpchat): 代表的是通过money进行控制的设备
AdbChimpDevice(chimpchat): 是一个更高层次的设备概念的抽象，它包含了以上的通过ADB控制的Device设备，同时也包含了上面的通过monkey进行控制的设备，当调用过来的时候AdbChimpDevice会根据究竟是需要发送命令到ADB服务器还是发送到monkey来决定使用的是哪个设备
MonkeyDevice(monkeyrunner): 可以被测试脚本直接使用的一个高层抽象设备，它所有的API基本上都是分发到AdbChimpDevice来执行的
大家看下下面的类图中AdbChimpDevice和Device以及ChimpManager的关系就会更清楚了:AdbChimpDevice拥有两个关键的成员变量，一个是IDevice类型,其实就是Device的父类的一个实例；一个是ChimpManager类型的一个实例。在下一章分析MonkeyDevice的实现原理的时候我们就会看到MonkeyDevice过来的一个调用，比如press，最终是被分发到AdbChimpDevice，AdbChimpDevice再来决定是通过ChimpManager来往monkey发送命令还是通过Device往ADB服务器发送命令。
图8-6-1 启动Monkey过程涉及的关键类
我们先分析下类图中每个类的关系以及简要描述下MonkeyRunner是怎么启动 monkey的，然后再去分析它们相关的实现代码。
那些无法讲述的悲伤和苍凉，
