Appium Android Bootstrap源码分析之简介
Appium Android Bootstrap源码分析之简介
本文在真个系列中会扮演一个简介的角色，不会分析任何的代码，只会先给大家一个基本的印象，方便大家在持有这个印象的基础上往下和本人一块分析。
1. Bootstrap定义及在Appium中扮演的角色
我们先看一下本人大概一个月之前刚接触appium时整理的一个高层架构图
下面一部分就是蓝色的就是bootstrap所在的位置，可以看到它是运行在我们的安卓目标测试机器端的，它会监听4724端口获得命令然后pass给UiAutomator来做处理。
那么我们应该怎么来给bootstrap做一个定义呢？我不知道官方有没有做一个定义，但是按照我自己的语言，我会这样来定义它：
Bootstrap是Appium运行在安卓目标测试机器上的一个UiAutomator测试脚本，该脚本的唯一一个测试方法所做的事情是在目标机器开启一个socket服务器来把一个session中Appium从PC端过来的命令发送给UiAutomator来执行处理。
这个定义说明了bootstrap在appium和uiautomator中究竟处于一个什么样的角色： 首先，它是一个uiautomator的测试脚本，它的入口类Bootstrap继承于UiAutomatorTestCase，所以UiAututomator可以正常运行它，它也可以正常的使用uiautomator的方法，这个就是appium的命令可以转换成uiautomator的命令的关键其次，它是一个socket服务器，它专门监听4724端口过来的appium的连接和命令数据，并把appium的命令转换成uiautomator的命令来让uiautomator进行处理最后，它处理的是appium从pc端过来的命令，而非一个文件。这在初次接触appium的朋友是很容易困惑的，以为appium是整个脚本文件发送到目标机器再由bootstrap进行分析处理的，事实并非如此
2. Bootstrap关键类一览表
上面寥寥几句道出了bootstrap的定义，那么往下我们就继续寥寥几行的把bootstrap这个jar包的关键类以及它的关键方法和相应的本人的一些说明给列出来，给大家现有一个draft idea每个类大概是怎么一回事，这样我们往下的文章就比较好说，大家也比较好理解了。
|
Class |
Key Method |
Key Member |
Parent |
Description |
Comment |
|
Bootstrap |
testRunServer |
|
|
以一个UiAutomatorTestCase的方法的方式运行一个SocketServer来监听4724端口 |
整个bootstrap是以UiAutomator的TestCase的方式运行的，所以这里的Bootstrap这个类必须要继承于UiAutomatorTestCase |
|
SocketServer |
handleClientData |
|
|
读取socket进来的字串命令信息并转换成AndroidCommand命令然后调用runCommand命令执行命令进行返回 |
|
|
AndroidComma ndType |
|
enum AndroidCommandType { ACTION,SHUTDOWN } |
|
安卓命令的类型，只有两种，shutdown的处理方式和普通的action会不一样 |
|
|
AndroidComma nd |
action/getElement |
JSONObject json; AndroidCommandType cmdType; |
|
从用户发过来的json命令信息得到真正的命令 |
|
|
CommandHand ler |
execute |
|
|
虚拟类，其他真实CommandHandler如click的父类 |
|
|
AndroidComma ndExecutor |
execute |
HashMap< String, CommandHan dler> map
|
|
map是所有的命令字串和真实的CommandHandler的一个映射。 其成员函数execute就是通过字串命令找到map对应的handler然后执行的 |
|
|
AndroidComma ndResult |
AndroidCommandResult |
JSONObject json |
|
组织json格式返回值的类 |
|
|
AndroidElement |
Click |
UiObject el; String id; |
|
代表了一个控件 |
其中id是其在AndroidElementsHash维护的elements这个哈希表的key，并非控件id。 |
|
AndroidElement Hash |
addElement |
Hashtable< String, AndroidEle ment> elements;
|
|
维护这个session当前为止碰到过的所有控件的哈希表 |
注意key就是上面AndroidElement的id这个成员变量。每有一个新的控件从appium pc端过来这个值就会加一 |
|
Click |
execute |
|
CommandHandler |
处理点击命令的类。 真正执行的是传进来的AndroidCommand对应UiObject的Click方法 |
其他find,drag,setText等命令同理 |
|
Strategy |
fromString |
publicenumStrategy {
CLASS_NAME (class name”),
CSS_SELECT OR(css selector”) , ID(“id), NAME(“name ), LINK_TEXT( link text), PARTIAL_LI NK_TEXT(“p artial link text), XPATH(“xpa th), ACCESSIBIL ITY_ID(“ac cessibilit y id”), ANDROID_UI AUTOMATOR( -android uiautomato r); |
|
查找控件命令的策略类 |
find这个CommandHandler会根据用户给出的不同策略来用不同的方式进行控件查找。比如用xpath的方式和用uiautomator的方式是不一样的 |
|
|
|
|
|
|
|
这里类在我们往下的分析文章中会做进一步的阐述，所以在这里你只需要由一个rough的idea这些类大概是怎么一回事就可以了。
3. Bootstrap运行流程简介
本来想画一个类图来描述bootstrap的架构的，但通过以上的类表可以看出来bootstrap里面的关键类基本没有真正用到面向对象中的继承，因为它们基本上都没有父类。其实我们也可以理解，每个类都不算复杂做的事情都不是很多，就算稍微需要做多点事情，组合其他的类来做就好了。 所以这里我也放弃给大家提供类图了，就提供我自己手画的（还是那句话，本人的macbook pro上没有安装相应的收费流程图软件）一个以处理appium从pc端过来的click命令的流程为例子的顺序图，大家先有一个初步的idea，看不明白也没有关系，我后面会另外开一篇文章专门来描述这个流程以把所有的关键类给串起来的。
用户评论