Android之UiAutomator测试框架源码分析（第九篇：UiDevice的wait方法与Until的findObject方法共同使用过程分析）

（注意：本文基于UI Automator测试框架版本为2.2.0）

UiDevice的wait（）方法介绍

    相信对于UI Automator测试框架稍熟悉的同学，一定知道UiDevice的wait（）方法有多重要，我们通过调用UiDevice的wait（）方法，可以使插桩线程根据指定的条件停顿一段时间，用来模拟人类的停顿，而短暂的停顿对于实际Ui自动化测试非常重要，它能确保自动化测试的稳定性（整体测试用例的稳定性）

为什么等待如此重要？

    为什么这么说？举个例子，每台设备的cpu运行效率是不同的，这导致在每台设备上运行同一个App的速度不同的，那么同一个App上的同一个控件在不同设备上的屏幕上绘制出来的时机也将不同，在cpu较差的设备上可能需要花费2秒才能完成控件的绘制，而在cpu较好的高端设备上可能只需要200ms就完成了控件的绘制。不同设备的cpu性能有差异，可我们只能维护一套程序……，此时的同一套程序代码中的查找控件的逻辑就可能会出现一个明显的问题，每当在cpu性能较好的高端设备上运行时很稳定，而在cpu性能较差的低端设备上却经常会无法正常工作，直观的表现为有时可以查找到一个控件，有时又提示找不到控件，简直坑爹！如何使用同一套测试代码，去兼容在不同性能的设备上稳定的运行Ui功能自动化需求呢？没有什么好路子，1条捷径就是使用UiDevice的wait（）方法（或者for循环重试查找），wait（）方法会让插桩线程按照指定条件的进行等待！使用wait（）方法时需要指定传入2个参数，第1个参数表示插桩线程是否需要停顿的条件对象（SearchCondition对象），第2个参数表示插桩线程停顿的最长时间。UiDevice的wait（）方法每次被调用时，只要指定的条件没有满足，插桩线程就会进入停顿状态，停顿的最长时间则是我们显式指定的第2个参数。

插装线程的停顿

    插桩线程处于停顿过程中时，没有完全停顿，它会每间隔1s去检测指定的条件对象是否满足。当条件已满足或者停顿时间达到指定的最长时间，插桩线程才能继续运行！

    插桩线程的停顿功能，是如何实现的呢？上篇文章分析了停顿功能是如何实现的，本篇将不再具体说明，而是查看源码执行的整个流程！接下来先介绍Until的findObject（）方法！

Until的findObject（）方法介绍

    UiDevice的wait（）方法需要两个参数，1个是SearchCondition对象，另1个是long型参数。SearchCondition对象表示插桩测试线程能否继续运行的条件对象，而long型参数表示的则是插桩线程停顿的最大时间。

    在UI Automator测试框架中，有个Until类，Until类位于androidx.test.uiautomator包中，Until类中所有静态工厂方法返回的都是一个Condition对象（Condition是所有条件对象的父类）。Condition的子类有哪些呢？比如SearchCondition、UiObject2Condition、EventCondition都是Condition的子类。Condition的子类SearchCondition对象可以传入到UiDevice的wait（）方法中，在Until类中有几个静态方法是可以返回SearchCondition对象的，它们分别是findObject（）方法、findObjects（）方法、gone（）方法、hasObject（）方法，这几个方法的最显著的区别是指定的类型参数是不同的！

    findObject（）方法本身是一个范型方法，它的类型参数是UiObject2，当我们使用findObject（）方法返回的对象与UiDevice的wait（）方法相结合时，这个在findObject（）方法中指定的类型参数UiObject2将成为UiDevice的wait（）方法的返回值对象，UiObject2对象对于我们来说非常重要，它表示根据指定条件在当前屏幕定位出的一个控件对象！因为Until的findObject（）方法经常与UiDevice的wait（