使用resourceid定位控件
  UISelector提供的定位的方式很多,可以是类名,文本,资源id,索引值等,但是索引、文本很容易随版本变化,类名重复程度又太高,而资源id通常是不会变的,使用多种条件混合有时效果更好。
  执行控件方法前判断是否存在
if (mDevice.hasObject(By.clazz(TextView.class).res(downloadRes))){
UiObject downloag = mDevice.findObject(new UiSelector().className(TextView.class).resourceId(downloadRes));
downloag.clickAndWaitForNewWindow(mOutTime/2);
if (mDevice.hasObject(By.text(lostApk))){
UiObject confirmBtn = mDevice.findObject(new UiSelector().resourceId(dialogbtnRes));
confirmBtn.click();
}
waitAndInstall();
}
  多使用clickAndWaitForNewWindow
  对于有跳转的click,使用clickAndWaitForNewWindow会比直接点击更有效,这个方法等待新窗口的出现后才返回,降低了由于卡顿而导致跳转慢终找不到控件的概率
  查找控件失败的可能原因
  有的控件设置了属性NAF=true,这个属性大概是no access flag之类的,表示不能被自动化工具识别到,这种控件我一般用起父控件的坐标去点击。
  资料:https://stuff.mit.edu/afs/sipb/project/android/docs/tools/testing/testing_ui.html
  用一些重试机制使脚本更稳定
  对于自动化,关注的不是功能点击的实现,而是脚本的稳定性,兼容性,为了写把一个click写好,很可能要额外写10几行代码,下面写的是如何写一个兼容性强的apk安装脚本
protected void waitAndInstall() throws UiObjectNotFoundException{
if(mDevice.hasObject(By.clazz(Button.class).text("下一步"))){
UiObject btn = mDevice.findObject(new UiSelector().text("下一步").className(Button.class));
btn.click();
waitAndInstall();//循环查找下一步
}else if(mDevice.hasObject(By.clazz(Button.class).text("安装"))){
UiObject btn = mDevice.findObject(new UiSelector().text("安装").className(Button.class));
btn.click();
btn = mDevice.findObject(new UiSelector().text("确定").className(TextView.class));
btn.waitForExists(30000);
btn.click();
}else{
mDevice.pressBack();//进入到这个流程通常时点击下载或安装时弹出了《是否需要root自动安装》《推荐其他应用》的弹窗。这类弹窗没有规律
UiObject btn = mDevice.findObject(new UiSelector().text("下一步").className(Button.class));
btn.waitForExists(mOutTime/2);
btn.click();
waitAndInstall();
}
}
  使用UIWatcher对异常情况处理,增强稳定性
  脚本运行时的异常弹窗,谷歌当然也会预料到,所以在UiAutomator里提供了UiWatcher这个接口,希望脚本编写者能够在异常时进行一些处理。
  UiWatcher的使用简单,首先它是一个接口,其次它只有一个方法需要实现,下面是其接口定义。
public interface UiWatcher {
/**
* Custom handler that is automatically called when the testing framework is unable to
* find a match using the {@link UiSelector}
*
* When the framework is in the process of matching a {@link UiSelector} and it
* is unable to match any widget based on the specified criteria in the selector,
* the framework will perform retries for a predetermined time, waiting for the display
* to update and show the desired widget. While the framework is in this state, it will call
* registered watchers' checkForCondition(). This gives the registered watchers a chance
* to take a look at the display and see if there is a recognized condition that can be
* handled and in doing so allowing the current test to continue.
*
* An example usage would be to look for dialogs popped due to other background
* processes requesting user attention and have nothing to do with the application
* currently under test.
*
* @return true to indicate a matched condition or false for nothing was matched
* @since API Level 16
*/
public boolean checkForCondition();
  }
  从接口的注释可以看到,当我们注册了watcher时,如果通过selector没有找到我们想要的Ui元素,会调用watcher。具体使用方法如下,首先实现这个接口,在我的安装自动化中,安装完apk后经常有些app弹窗问是否要删除安装包,影响脚本后续的点击。所以我写了这个watcher,当触发时,如果UI中找到了类似这个弹窗,那么我点击系统back按键取消这个弹窗,使我的脚本继续执行。
public class MyWatcher implements UiWatcher {
private UiDevice mDevice;
public MyWatcher(UiDevice device){
mDevice = device;
}
@Override
public boolean checkForCondition() {
if(mDevice.hasObject(By.text("删除安装包"))){
mDevice.pressBack();
return true;
}
return false;
}
}
  完成定以后,在脚本的setUp里注册自己的watcher,当控件查找失败时会自动调用watcher了。
  myWatcher = new MyWatcher(mDevice);
  mDevice.registerWatcher("testwatcher",myWatcher);
  下面我们看下watcher是如何增强脚本稳定性的。以下是UiObject中查找控件的方法,可以看到当查找控件失败时,会调用device的runWatcher方法启动所有注册的watcher,然后如果没有超时会再次寻找。所以如果我们在watcher里把弹窗处理掉,那么下次查找会成功了。
protected AccessibilityNodeInfo findAccessibilityNodeInfo(long timeout) {
AccessibilityNodeInfo node = null;
long startMills = SystemClock.uptimeMillis();
long currentMills = 0;
while (currentMills <= timeout) {
node = getQueryController().findAccessibilityNodeInfo(mUiSelector);
if (node != null) {
break;
} else {
// does nothing if we're reentering another runWatchers()
mDevice.runWatchers();
}
currentMills = SystemClock.uptimeMillis() - startMills;
if(timeout > 0) {
SystemClock.sleep(WAIT_FOR_SELECTOR_POLL);
}
}
return node;
}
  实际用的过程中,不管是调用device的findObject还是hasObject,如果查找失败都会调用到watcher,所以watcher里一定要根据实际状态进行处理,切不可统一做处理。
  takeScreenShot失败?
  这两天写自动化时有时会截图失败,会提示device or resource is busy,后来发现是RootExplorer打开着没有完全退出,只是退到了后台,应该是RE打开时把文件系统重洗挂载了导致无法写入截图文件。
  同时在实践也发现takescreenshot函数的重载版,设置图片质量和缩放时貌似是无效的,如果图片有传输要求还是自己写代码压缩吧
  即使你了解了这些技巧,目前来看,仍不建议去做功能自动化,脚本的稳定性保证需要很多额外的代码,提升却很有限