androidelementhash的这个getelement命令要做的事情就是针对这两点来根据不同情况获得目标控件
/** * return an elements child given the key (context id), or uses the selector * to get the element. * * @param sel * @param key * element id. * @return {@link androidelement} * @throws elementnotfoundexception */ public androidelement getelement(final uiselector sel, final string key) throws elementnotfoundexception { androidelement baseel; baseel = elements.get(key); uiobject el; if (baseel == null) { el = new uiobject(sel); } else { try { el = baseel.getchild(sel); } catch (final uiobjectnotfoundexception e) { throw new elementnotfoundexception(); } } if (el.exists()) { return addelement(el); } else { throw new elementnotfoundexception(); } } |
如果是第1种情况就直接通过选择子构建uiobject对象，然后通过addelement把uiobject对象转换成androidelement对象保存到控件哈希表
如果是第2种情况就先根据appium传过来的控件哈希表键值获得父控件，再通过子控件的选择子在父控件的基础上查找到目标uiobject控件，最后跟上面一样把该控件通过上面的addelement把uiobject控件转换成androidelement控件对象保存到控件哈希表
4. 求证
上面有提过，如果pc端的脚本执行对同一个控件的两次findelement会创建两个不同id的androidelement并存放到控件哈希表中，那么为什么appium的团队没有做一个增强，增加一个keymap的方法（算法）和一些额外的信息来让同一个控件使用不同的key的时候对应的还是同一个androidelement控件呢？毕竟这才是哈希表实用的特性之一了，不然你直接用一个dictionary不就完事了？网上说了几点hashtable和dictionary的差别，如多线程环境最好使用哈希表而非字典等，但在bootstrap这个控件哈希表的情况下我不是很信服这些说法，有谁清楚的还劳烦指点一二了
这里至于为什么appium不去提供额外的key信息并且实现keymap算法，我个人倒是认为有如下原因：
有谁这么无聊在同一个测试方法中对同一个控件查找两次？
如果同一个控件运用不同的选择子查找两次的话，因为最终底层的uiobject的成员变量uiselector mselector不一样，所以确实可以认为是不同的控件
但以下两个如果用同样的uiselector选择子来查找控件的情况我就解析不了了，毕竟在我看来bootstrap这边应该把它们看成是同一个对象的：
同一个脚本不同的方法中分别对同一控件用同样的uiselelctor选择子进行查找呢？
不同脚本中呢？
这些也许在今后深入了解中得到解决，但看家如果知道的，还望不吝赐教
5. 小结
最后我们对bootstrap的控件相关知识点做一个总结
androidelement的一个实例代表了一个bootstrap的控件
androidelement控件的成员变量uiobject el代表了uiautomator框架中的一个真实窗口控件，通过它就可以直接透过uiautomator框架对控件进行实质性操作
pc端的webelement元素和bootstrap的androidelement控件是通过androidelement控件的string id进行映射关联的
androidelementhash类维护了一个以androidelement的id为键值，以androidelement的实例为value的全局唯一哈希表，pc端想要获得一个控件的时候会先从这个哈希表查找，如果没有了再创建新的androidelement控件并加入到该哈希表中，所以该哈希表中维护的是一个当前已经使用过的控件
相关文章：
appium android bootstrap源码分析之简介
通过上一篇《 源码分析之简介》我们对bootstrap的定义以及其在appium和uiautomator处于一个什么样的位置有了一个初步的了解，那么按照正常的写书的思路，下一个章节应该就要去看bootstrap是如何建立socket来获取数据然后怎样进行处理的了。但本人觉得这样子做并不会太好，因为到时整篇文章会变得非常的冗长，因为你在编写的过程中碰到不认识的类又要跳入进去进行说明分析。这里我觉得应该尝试吸取著名的《重构》这本书的建议：一个方法的代码不要写得太长，不然可读性会很差，尽量把其分解成不同的函数。那我们这里就是用类似的思想，不要尝试在一个文章中把所有的事情都做完，而是尝试先把关键的类给描述清楚，最后才去把这些类通过一个实例分析给串起来呈现给读者，这样大家就不会因为一个文章太长影响可读性而放弃往下了。
那么我们这里为什么先说bootstrap对控件的处理，而非刚才提到的socket相关的socket服务器的建立呢？我是这样子看待的，大家看到本人这篇文章的时候，很有可能之前已经了解过本人针对uiautomator源码分析那个系列的文章了，或者已经有uiautomator的相关知识，所以脑袋里会比较迫切的想知道究竟appium是怎么运用了uiautomator的，那么在appium中于这个问题最贴切的就是appium在服务器端是怎么使用了uiautomator的控件的。
这里我们主要会分析两个类：
:代表了bootstrap持有的一个ui界面的控件的类，它拥有一个uiobject成员对象和一个代表其在下面的哈希表的键值的string类型成员变量id
androidelementshash:持有了一个包含所有bootstrap（也就是appium）曾经见到过的（也就是脚本代码中findelement方法找到过的）控件的哈希表，它的key就是androidelement中的id，每当appium通过findelement找到一个新控件这个id就会＋1，appium的pc端和bootstrap端都会持有这个控件的id键值，当需要调用一个控件的方法时就需要把代表这个控件的id键值传过来让bootstrap可以从这个哈希表找到对应的控件
1. androidelement和uiobject的组合关系
从上面的描述我们可以知道，androidelement这个类里面拥有一个uiobject这个变量：
public class androidelement {
private final uiobject el;
private string id;
...
}
大家都知道uiobject其实就是uiautomator里面代表一个控件的类，通过它就能够对控件进行操作（当然最终还是通过uiautomation框架). anroidelement就是通过它来跟uiautomator发生关系的。我们可以看到下面的androidelement的点击click方法其实就是很干脆的调用了uiobject的click方法：
public boolean click() throws uiobjectnotfoundexception {
return el.click();
}
当然这里除了click还有很多控件相关的操作，比如dragto,gettext,longclick等，但无一例外，都是通过uiobject来实现的，这里就不一一列举了。
2. 脚本的webelement和bootstrap的androidelement的映射关系
我们在脚本上对控件的认识就是一个webelement:
webelement addnote = driver.findelementbyandroiduiautomator("new uiselector().text(\"add note\")");
而在bootstrap中一个对象就是一个androidelement. 那么它们是怎么映射到一起的呢？我们其实可以先看如下的代码：
webelement addnote = driver.findelementbyandroiduiautomator("new uiselector().text(\"add note\")");
addnote.gettext();
addnote.click();
做的事情就是获得notes这个app的菜单，然后调用控件的gettext来获得‘add note'控件的文本信息，以及通过控件的click方法来点击该控件。那么我们看下调试信息是怎样的：
: : :
text-to-speech function is limited to 100 characters