1、Appium Android Bootstrap 源码分析简介(http://blog.csdn.net/zhubaitian/article/details/40619777)
1) bootstrap 是 appium 运行在安卓设备上的一个 uiautomator 测试脚本,该脚本唯一测试方法做的事情就是在设备上开启一个 socket 服务器来把一个 session 中 appium 从 PC 端过来的命令发送给 uiautomator 测试框架来执行处理
2)执行时序图:
2、Appium Android Bootstrap 源码分析之控件 AndroidElement(http://blog.csdn.net/zhubaitian/article/details/40650953)
1)AndroidElement:代表了 bootstrap 持有的一个 ui 界面的控件的类,它拥有一个 UiObject 成员对象和一个代表其在下面的哈希表的键值的 String 类型成员变量 id
2)AndroidElementsHash:持有了一个包含所有 bootstrap(也就是 appium)曾经见到过的(也就是脚本代码中 findElement 方法找到过的)控件的哈希表, 它的 key 就是 AndroidElement 中的 id,每当 appium 通过 findElement 找到一个新控件这个 id 就会+1,Appium 的 pc 端和 bootstrap 端都会持有这个控件的 id 键值, 当需要调用一个控件的方法时就需要把代表这个控件的 id 键值传过来让 bootstrap 可以从这个哈希表找到对应的控件
3)总结:
a:AndroidElement 的一个实例代表了一个 bootstrap 的控件
b:AndroidElement 控件的成员变量 UiObject el 代表了 uiautomator 框架中的一个真实窗口控件,通过它就可以直接透过 uiautomator 框架对控件进行实质性操作
c:pc 端的 WebElement 元素和 Bootstrap 的 AndroidElement 控件是通过 AndroidElement 控件的 String id 进行映射关联的
d:AndroidElementHash 类维护了一个以 AndroidElement 的 id 为键值,以 AndroidElement 的实例为 value 的全局唯一哈希表,pc 端想要获得一个控件的时候会先从这个哈希表查找, 如果没有了再创建新的 AndroidElement 控件并加入到该哈希表中,所以该哈希表中维护的是一个当前已经使用过的控件
4)简要总结:Appium 从 pc 端发送过来的命令如果是控件相关的话,最终目标控件在 bootstrap 中是以 AndroidElement 对象的方式呈现出来的,并且该控件对象会在 AndroidElementHash 维护的控件哈希表中保存起来
3、Appium Android Bootstrap 源码分析之命令解析执行(http://blog.csdn.net/zhubaitian/article/details/40653199)
总结:
1)bootstrap 接收到 appium 从 pc 端发送过来的 json 格式的键值对字串有多个项:
cmd: 这是一个 action 还是一个 shutdown
action:如果是一个 action 的话,那么是什么 action,比如 click
params:拥有其他的一些子项,比如指定操作控件在 AndroidElementHash 维护的控件哈希表的控件键值的'elementId'
2)在收到这个 json 格式命令字串后:
3)AndroidCommandExecutor 会调用 AndroidCommand 去解析出对应的 action
4)然后把 action 去 map 到对应的真实命令处理方法 CommandHandler 的实现子类对象中
5)然后调用对应的对象的 execute 方法来执行命令
4、Appium Android Bootstrap 源码分析之启动运行(http://blog.csdn.net/zhubaitian/article/details/40678123)
总结:
1)Appium 的 bootstrap 这个 jar 包以及里面的 o.appium.android.bootstrap.Bootstrap 类是通过 uiautomator 作为一个 uiautomator 的测试包和测试方法类启动起来的
2)Bootstrap 测试类继承于 uiautomator 可以使用的 UiAutomatorTestCase
3)bootstrap 会启动一个 socket server 并监听来自 4724 端口的 appium 的连接 ,一旦 appium 连接上来,bootstrap 就会不停的去获取该端口的 appium 发送过来的命令数据进行解析和执行处理,然后把结果写到该端口返回给 appium
4):bootstrap 获取到 appium 过来的 json 字串命令后,会通过 AndroidCommand 这个命令解析器解析出命令 action,然后通过 AndroidCommandExecutor 的 action 到 CommandHandler 的 map 把 action 映射到真正的命令处理类,这些类都是继承与 CommandHandler 的实现类,它们都要重写该父类的 execute 方法来最终通过 UiObject,UiDevice 或反射获得 UiAutomator 没有暴露出来的 QueryController/InteractionController 来把命令真正的在安卓系统中执行
5):appium 获取控件大概有两类,一类是直接通过 Appium/Android Driver 获得,这一种情况过来的 appium 查找 json 命令字串是没有带控件哈希表的控件键值的;另外一种是根据控件的父类控件在控件哈希表中的键值和子控件的选择子来获得,这种情况过来的 appium 查找 json 命令字串是既提供了父控件在控件哈希表的键值又提供了子控件的选择子的 ,一旦获取到的控件在控件哈希表中不存在,就需要把这个 AndroidElement 控件添加到该哈希表里面
5、Appium Server 源码分析之启动运行 Express http 服务器(http://blog.csdn.net/zhubaitian/article/details/40710049)
1)介绍:
Appium Server 其实拥有两个主要的功能:
它是个 http 服务器,它专门接收从客户端通过基于 http 的 REST 协议发送过来的命令
他是 bootstrap 客户端:它接收到客户端的命令后,需要想办法把这些命令发送给目标安卓机器的 bootstrap 来驱动 uiatuomator 来做事情
2)总结:
主要描述了 appium server 是如何创建一个基于 express 框架的 http 服务器,然后启动相应的监听方法来获得从 appium client 端发送过来的数据
6、Appium Server 源码分析之作为 Bootstrap 客户端(http://blog.csdn.net/zhubaitian/article/details/40783625)
总结:
通过本文我们了解了 appium server 作为 bootstrap 的客户端,同时又作为 appium client 的服务器端,是如何处理从 client 来的命令然后组建成相应的 json 命令字串发送到 bootstrap 来进行处理的:
1)初始化 REST 路由表来接收 appium client 过来的 REST 命令调用并分发给相应的 controller 方法来进行处理
2)appium client 发送命令之前会先触发一个创建 session 的请求,在路由表表现为 “rest.post('/wd/hub/session', controller.createSession);”。对应的 controller 处理方法会开始初始化与 bootstrap 的连接
3)创建的 session 的过程会调用 Appium 类的 start 方法然后机型一系列的动作:
4)初始化设备类 Android
5)用 Async 库的 queue 对象初始化 Appium 的 Work Queue
6)创建 adb 实例并启动 adb
7) 安装测试 apk
8)通过 adb 启动 bootstrap
9)建立 Appium Server 和 bootstrap 的 socket 连接 等
10)创建好连接后 Appium Server 就会接收 client 过来的命令,比如 click,然后对应的 controller 处理方法就会建立命令对应的 task 并把它 push 到 async queue 里面 ,一旦有新 task 进入到 async queue,对应的回调函数就会触发,开始往已经建立的与 bootstrap 的 socket 连接发送 json 字串命令