老李推荐: 第14章2节《MonkeyRunner源码剖析》 HierarchyViewer实现原理-HierarchyViewer架构概述
HierarchyViewer库的引入让MonkeyRunner可以以面向控件的方式进行脚本编写,那么它是怎么做到这一点的呢?它的实现原理又是怎么样的呢?在这一小节开始我们就会开始一起揭开它的神秘面纱。
HierarchyViewer这个框架的工作需要ViewServer的协同工作,它们是以CS(Client-Server)架构来协同工作的。我们在上一章已经学习了如何让做为Server端的ViewServer为我们提供获取控件列表的服务,那么这一章我们主要分析的就是做为Client端的HierarchyViewer是如何实现驱动目标机器的ViewServer服务器来获取控件列表等相关工作的。
从我们编写MonkeyRunner测试脚本的角度来看,我们一般会这样子使用HierarchyViewer:
1 device = MonkeyRunner.waitForConnection()
2 viewer = device.getHierarchyViewer()
3 view = viewer.findViewById("id/button") #Return a ViewNode
4 p = viewer.getAbsoluteCenterOfView(view)
5 device.touch(p.x,p.y,MonkeyDevice.DOWN_AND_UP)
代码14-2-1 通过控件点击按钮
从以上的代码我们可以看到整个使用HierarchyViewer的流程是非常的简单明了的:
- 第一步: 通过MonkeyDevice的实例获得HierarchyViewer的实例
- 第二步: 使用HierarchyViewer的实例来通过控件的ID来获得代表控件的一个ViewNode实例
- 第三步: 最后就可以通过操作ViewNode实例暴露出来的各种控件属性来进行控件的操作了
我们最终通过ViewNode控件实例的属性来操作控件确实让我们用起来得心应手,但是暗藏在这些简单的脚本代码背后的实现原理其实并不会这么简单的。我们尝试把我们脑袋里面的疑问给列出来:
- 问题1: findViewById是从哪里根据控件ID获得我们需要的控件的?直接把ID发给ViewServer让它去查找吗?还是通过其他方法?
- 问题2 :MonkeyDevice的getHierarchyViewer方法究竟做了什么事情?
这两个问题的答案其实就是本章的重点,我们先带着这两个问题来往下学习,最后问题就会不言自明了。
往下我们先看下HierarchyViewer涉及的关键类的类图来了解下它的架构:
图11-2-1 HierarchyViewer类图
从上图我们可以看到整个框架其实涉及到了多个库,包括chimpchat,hierarchyviewerlib和ddmlib类,这里先简要描述下主要会用到每个库的哪些类,以及这些类在这里主要的作用是什么,其实很多我们在前面章节都已经接触过了,但以前可能没有去描述这些类跟HierarchyViewer是什么关系。
类名 | 库 | 作用 | 注释 |
HierarchyViewer | chimpchat | 提供控件相关API给测试开发人员调用,如findViewById等 | 拥有ddmlib的Device类的一个实例,所以可以通过该实例来操作AdbHelper来跟ADB服务器进行通信 |
Device | ddmlib | 在这里的主要作用是可以直接调用AdbHelper来往ADB服务器发送命令 |
|
AdbHelper | ddmlib | 负责连接ADB服务器并向其发送命令 |
|
DeviceBridge | hierarchyviewerlib | 相当于ViewServer在客户端的代理,两者的关系类似于adbd和adb服务器的关系; | 组织命令然后调用DeviceConnection的API把命令发送给ViewServer |
DeviceConnection | hierarchyviewerlib | 连接ViewServer的Socket客户端,专门用来连接ViewServer,发送命令和接收命令返回 |
|
Window | hierarchyviewerlib | 代表一个控件的窗口,它跟控件ViewNode是不一样的,它不会保存控件的所有属性,它主要的成员变量有:窗口标题mTitle;代表该窗口的哈希值 |
|
ViewNode | hierarchyviewerlib | 代表了一个控件,拥有Window实例以及一个控件的所有属性信息 |
|
表格 11-2-1 HierarchyViewer关键类简述
往下我们描述下每个类之间是怎么互动的:
- HierarchyViewer依赖DeviceBridge: HierarchyViewer在初始化的时候会调用途中的setupViewServer这个私有方法来准备好目标机器端的ViewServer,期间它会调用DeviceBridge的一系列方法来完成这些事情,其中DeviceBridge是一个静态类,不需要初始化就能直接使用其内部公共方法
- DeviceBridge依赖DeviceConnection: DeviceBridge成员方法会初始化DeviceConnection对象来通过它把组织好的命令发送到ViewServer,比如DUMP命令.
- DeviceBridge依赖ViewNode: DeviceBridge在通过发送DUMP命令到ViewServer获得控件列表后,会把每个控件的信息都解析出来,然后建立一个由ViewNode控件实例组建起来的一棵控件树。
- DeviceBridge依赖Device: HierarchyViewer在调用DeviceBridge的setupViewServer去准备好ViewServer的时候会把它持有的Device实例传进去给DeviceBridge,DeviceBridge就是通过这个Device实例来组织相应的ADB命令来发送给ADB服务器来操作ViewServer的
- Device依赖AdbHelper: Device本身并不会连接ADB服务器的socket来发送命令,这些都是由AdbHelper来做的,我们在之前的章节已经见识过了
- ViewNode组合Window: 每个ViewNode都拥有一个Window成员变量。也就是说每个控件都应该是属于某一个窗口的,一个不属于某个窗口的控件是没有意义的,是不应该存在的
- HierarchyViewer使用ViewNode: 脚本在调用HierarchyViewer的findElementById的时候,会首先使用DeviceBridge来获取控件列表并建立控件树,最后会遍历由ViewNode实例组成的控件树来获取目标控件
HierarchyViewer架构到了这里就算描述的差不多了,往下我们会进入到实现细节去看下它的实现原理是怎样的。