如果跑Espresso测试跑久了，你大概率遇过这种情况：应用内部逻辑全都畅通，一点击某个按钮触发系统权限弹窗、或者跳转到系统设置页，测试就在那儿干等，最终以NoMatchingViewException或者超时收场。这就是Espresso的边界——它的一切都是基于你应用自身进程内的View层级，系统界面和别的应用它是管不到的。而要补上这块能力，就得让UI Automator进场。这篇文章我会从为什么必须混合使用这两套框架讲起，再给出一套我自己在项目里验证过的配合方案，包括环境配置、选择器写法、等待策略，以及实测中反复踩过的坑。
1. Espresso测试的“天花板”：为什么必须引入UI Automator
1.1 能被Espresso掌控的只有你自己App的那一个进程
先理解一件事：Espresso能够自动同步、自动等待、精准匹配ID，是因为它运行在目标App的进程内，直接拿到了Activity、ViewHierarchy和主线程的消息队列。框架可以随时查看界面上有没有东西在做耗时任务、是否处于Idle状态，然后才执行操作。这套机制保证了一个“稳定”的前提——测试看到的状态和App真正渲染的状态基本一致。
但这也意味着，Espresso的所有能力都局限在一个进程里。一旦界面被一个系统弹窗覆盖（例如Android 6.0之后的运行时权限、存储权限、通知权限），或者App跳转到了系统设置页，Espresso就彻底瞎了。它的onView()找不到这些不属于当前Activity的View，因为它压根看不到系统进程的界面；它也找不到别的App的界面，因为那属于另一个进程的View层级。说得直白一点：Espresso是一把只能开自家门的钥匙。
UI Automator不一样。它是基于UiAutomation实现的跨进程UI测试框架，走的是系统辅助功能（Accessibility）通道，可以直接读取整个屏幕上的UI元素层级，可以和系统弹窗交互，可以点通知栏，可以操作其他App。它是设备级的，不关心当前前台是谁，只管“屏幕上有什么”。
所以“使用UI Automator改进Espresso测试”这个命题的本质，不是拿UI Automator替换Espresso，而是给Espresso配一个跨进程的“外挂”：内部逻辑、主流程、View细节全部交给Espresso，跨进程操作和系统UI交互交给UI Automator，两者在同一个Instrumentation测试用例里协作，才算覆盖完整的用户路径。
1.2 三个最常见的“Espresso无奈”场景
下面这些场景是我在实际项目中确认过的，单靠Espresso无法完成，引入UI Automator后直接解决问题：
场景一：运行时权限弹窗。应用首次启动时申请存储/定位/相机权限，弹窗是系统进程（
com.android.permissioncontroller）的界面，不在目标App进程内。Espresso无法点击“While using the app”按钮，UI Automator可以直接用By.text()或By.res()定位系统弹窗上的按钮。场景二：跳转到系统设置页。比如引导用户开启通知栏权限、修改默认短信应用，这类用例经常需要进入系统Settings界面去点击某个Switch或列表项，然后再返回应用验证状态。Settings同样在别的进程，Espresso完全够不到。
场景三：覆盖式启动其他应用。例如从App跳到系统相机拍照、跳到第三方账号登录页再回来。跨进程的界面过渡以及返回操作，需要UI Automator的
uiDevice.pressBack()和设备级滚动能力。
我见过不少团队试图在Espresso里硬等、或者直接Thread.sleep()来蹭过权限弹窗，结果就是CI上50%的失败率，特别不稳定。把UI Automator引进来之后，这些场景都能用可靠的选择器+等待机制稳定通过。
1.3 两套框架的边界对照
| 维度 | Espresso | UI Automator |
|---|---|---|
| 作用范围 | 目标App进程内 | 设备级、跨进程 |
| 视图获取 | 通过Activity的ViewHierarchy | 通过Accessibility节点树 |
| 元素定位 | onView(withId/withText) | By.text/By.res/By.desc |
| 等待机制 | 自动同步Idle | 手动等待Until条件 |
| 适用场景 | 应用内UI细节、业务逻辑 | 系统UI、跨应用交互 |
| 稳定性特点 | 进程内稳定、同步 | 受系统动画影响，需加等待 |
从这张表能看出来，两者并非同一种工具的两种叫法，而是分别管着不同层级的界面。一个完整的用户旅程测试（点击按钮→弹权限→进设置→返回→验证状态）必须同时使用这两套框架，没有替代关系。
2. UI Automator环境准备里最容易翻车的三个配置细节
2.1 testInstrumentationRunner不能只写一个
很多人以为在build.gradle里加上UI Automator依赖就能直接跑，实际上漏了关键一步——测试运行器。
UI Automator的UiDevice.getInstance()在初始化时要拿到Instrumentation实例，它需要你的测试运行器已正确初始化。如果你的项目里同时跑Espresso和UI Automator，建议统一使用androidx.test.runner.AndroidJUnitRunner，它是AndroidX测试全家桶的入口，可以同时承载Espresso和UI Automator用例，不需要再额外注册单独的runner。“每一套框架配一个runner”的想法看着合理，实际执行时会因为runner不兼容直接跑不起来。
android { defaultConfig { testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" } }除了runner之外还要把testInstrumentationRunnerArguments里的clearPackageData设为true，确保每次测试之间应用数据是干净的。这个参数在本项目里非常重要，因为UI Automator类用例经常会触发弹窗，如果不清理数据，第二次运行时会遇到“这个权限已经给过了，弹窗不出现了”的尴尬情况——你的用例是按弹窗存在来写的，结果弹窗被记住了，用例直接失败。
defaultConfig { testInstrumentationRunnerArguments = [ 'clearPackageData': 'true' ] }2.2 依赖版本与打包方式的取舍
UI Automator的依赖官方包是androidx.test.uiautomator:uiautomator，我在项目里用的是2.2.0稳定版。Espresso用的是androidx.test.espresso:espresso-core的最新稳定版。两者可以共存，但建议同时引入androidx.test:core和androidx.test.ext:junit，避免在运行时因为JUnit和AndroidJUnitRunner的版本不匹配导致RuntimeException。
androidTestImplementation "androidx.test.ext:junit:1.1.5" androidTestImplementation "androidx.test:runner:1.5.2" androidTestImplementation "androidx.test.espresso:espresso-core:3.5.1" androidTestImplementation "androidx.test.uiautomator:uiautomator:2.2.0"还有一个容易忽略的地方：UI Automator本质上是遍历屏幕上的所有节点，包括状态栏、导航栏、应用内各种弹窗。如果你在测试Application里设置了FLAG_SECURE（禁止截图、禁止内容在最近任务中显示），UI Automator在获取节点树时也会受限，只能看到窗口级别的信息，看不到内部控件。这种情况不是框架坏了，而是你的测试目标App本身做了安全限制。排查思路是先在设置里关掉“安全屏幕”相关逻辑，或者改用能感知窗口层级的方式去验证。
2.3 真机与模拟器的无障碍通道差别
UI Automator依赖Accessibility通道，这在模拟器和真机上都没问题，但真实环境中有一个陷阱：如果测试设备上安装了带无障碍服务的第三方App（比如自动跳过开屏广告的工具），那这些服务会同时注册到系统节点树中，干扰UI Automator的查找性能——严重时findObject()会明显变慢，甚至超时。
另外，真机上个别厂商ROM（尤其是国内定制ROM）为了节省电量，会延迟或冻结后台进程的UI线程，导致UI Automator等待的时间比理论值长不少。我在小米和华为的几台设备上实测，同一个wait(Until.findObject, 10000)在Pixel模拟器上可能3秒就返回，在部分定制ROM上要到8-10秒。所以那两个配置建议：一是测试前把系统动画全部关掉，二是把等待时间给的足够宽，不要抱着“超时设短一点早点报错”的心态，UI测试本来就该有弹性。
3. UI Automator选择器与交互API的实战拆解
3.1 从UiDevice到UiSelector的查找链路
UI Automator的入口是UiDevice，通过Instrumentation获取实例：
val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())拿到UiDevice之后，你可以直接操作设备级动作，比如点亮屏幕、按返回键、打开通知栏。要查找界面元素，老一代的写法是用UiSelector：
val allowButton = device.findObject( UiSelector().textContains("Allow").className(Button::class.java.name) )UiSelector确实能用，但它是同步查找，找不到就直接返回一个空对象，不会等待。在系统弹窗还没完全渲染出来的瞬间调用，你很可能拿到false结果，然后去调用.click()直接抛异常。所以我在新项目里会更多使用UiObject2和By那套基于等待机制的API，而不是老式UiSelector。
3.2 UiObject2与By的现代写法
用By加UiDevice.wait()可以做到“等到目标出现再返回”，这是跨进程测试稳定性的关键：
val allowButton = device.wait( Until.findObject(By.text("Allow")), 10_000 )这行代码的意思是：从当前时刻开始，最多等10秒，直到屏幕上出现文本为“Allow”的节点。如果超时，返回null。之后的逻辑就可以根据null判断是继续还是失败。
By里面的选择条件非常丰富，我在实际项目中最常用的几个：
By.text("登录")：精确匹配文本By.textContains("登录")：模糊匹配，适合有前后缀的动态文本By.res("com.example.app:id/userName")：按资源ID匹配，最稳定By.desc("打开菜单")：按内容描述匹配，适合ImageView等无文本控件By.clazz(EditText::class.java.name)：按控件类型匹配，常用于输入框定位
组合使用也很方便：
val editText = device.wait( Until.findObject(By.clazz(EditText::class.java.name).hasChild(By.text("请输入手机号"))), 5_000 )这里用hasChild做了一个子节点条件，定位父级输入框比较精准。值得注意的是，UI Automator的By.res不推荐在系统级弹窗上使用，因为不同安卓版本的系统弹窗资源ID不完全一样。我一般对系统弹窗优先用By.text，对应用内控件优先用By.res，两套策略各司其职。
3.3 常用交互操作与等待条件
对于UiObject2，最常用的交互无非是获取文本、点击、输入、滚动：
// 点击 button.click() // 获取文本 val text = textView.text // 输入 editText.text = "测试账号" // 滚动到某元素 val scrollable = device.findObject(By.scrollable(true)) scrollable?.scroll(Direction.DOWN, 1.0f)但有一个细节我在实战里吃过亏：用By.scrollable(true)找到的UiObject2执行scroll()时，滚动是基于控件自身内嵌的Scrollable节点完成的，如果页面的滚动容器是多个嵌套的ScrollView，滚动条不会一定命中目标。这种情况下更稳妥的方式是先尝试device.findObject(By.text("底部目标文本"))，找不到再滚动，而不是一上来就滚动。
另外，很多人在跨进程用例里只记得findObject，忘了“等它消失”同样重要。我在协作用例里会高频使用：
device.wait(Until.gone(By.res("com.example.app:id/loading")), 10_000)这个Until.gone()在等待界面关闭时特别好用，尤其是App内启动了系统页面再返回时，回来之后用一个gone条件等待加载状态消失，再交给Espresso去断言，能大幅减少偶发失败。
4. 从Espresso切到UI Automator的时机与等待策略
4.1 测试用例内的切换时机问题
一个典型的混合用例长这样：先用Espresso点击“打开系统设置”按钮，系统启动设置页；此时Espresso已经无法访问任何View了，因为当前前台的Activity不是被测App的Activity。如果你在此时继续调用onView()，Espresso会尝试等待被测Activity的消息队列，而它已经被切到后台，消息队列不在前台状态，等待就永远不会结束，最终超时失败。
所以切换时机有个基本原则：跨进程发起之后，立刻切到UI Automator，不要尝试让Espresso做任何操作。反过来，从系统页面返回被测App之后，也不要用UI Automator继续点击应用内的复杂控件，直接切回Espresso。
下面这个伪代码展示了我项目里的切换节奏：
@Test fun openSystemSettingsAndBack() { // Espresso阶段：点击触发跳转 onView(withId(R.id.btnOpenSettings)).perform(click()) // 切到UI Automator：等待系统设置界面出现 val settingsTitle = device.wait(Until.findObject(By.text("Settings")), 10_000) assertNotNull(settingsTitle) // UI Automator在系统设置页执行操作 val wifiItem = device.wait(Until.findObject(By.text("Wi-Fi")), 10_000) wifiItem.click() // 返回被测App device.pressBack() device.wait(Until.hasObject(By.res("com.example.app:id/mainLayout")), 10_000) // 切回Espresso：验证页面状态 onView(withId(R.id.linkStatus)) .check(matches(withText("已连接"))) }这里的关键在于每次切换前，当前可见界面要已经符合目标框架能操作的前提。用wait去等到界面元素出现，而不是凭着经验sleep几秒再操作，这是稳定性的分水岭。
4.2 轮询等待比sleep更稳
UI Automator本身有wait机制，但在混合用例里遇到“系统页面正在启动动画”“两个Activity正在过渡”这种阶段，wait(Until.findObject, 5000)也可能提前返回一个尚不可点击的节点。这个时候我对UI Automator的处理是再加上一个可点击轮询，这就有点像Espresso自动同步机制的降级版：
fun waitForClickable(device: UiDevice, selector: BySelector, timeout: Long): UiObject2? { val endTime = System.currentTimeMillis() + timeout while (System.currentTimeMillis() < endTime) { val obj = device.findObject(selector) ?: run { SystemClock.sleep(200); continue } if (obj.isClickable) return obj SystemClock.sleep(200) } return null }这个方法比单纯的Until.findObject多了一层“不仅存在，而且可以点击”的判断，阻尼动画还没播完时特别有用。也不要把SystemClock.sleep完全妖魔化，短小的轮询间隔配合条件判断是合理的，真正有问题的是不加条件直接死睡固定时长。
还有一个值得养成的习惯：在混合测试用例里，每个UI Automator操作之后，用Espresso的onView().check()来做状态断言。因为Espresso的断言调度到主线程，能顺便等待App回到Idle状态，这比在UI Automator里轮询一个应用内文案要可靠得多。我经常是UI Automator负责“做动作”，Espresso负责“验结果”。
4.3 处理混合场景：系统弹窗和应用内表单的组合
如果你有一个用例是“首次启动→触发权限弹窗→授权→进入首页底部导航”，那可以把整个流程拆成三段，每段用合适的框架：
- 第一段用Espresso：启动Activity，点击“同意隐私政策”按钮，触发权限申请（这里Espresso能做的只是点击，点击之后权限弹窗由系统接管）。
- 第二段用UI Automator：等待权限弹窗出现，点击“Allow”，等待返回应用。
- 第三段用Espresso：验证首页是否正常显示、底部导航是否选中了“首页Tab”。
在代码层面，同一测试类中同时用onView和device是完全正常的。但要保证Instrumentation测试进程内已经初始化了UiDevice，建议在@Before里统一获取一次，避免每个测试方法重复初始化的开销和潜在的初始化时序问题。
private lateinit var device: UiDevice @Before fun setUp() { device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()) }5. 实测中踩过的坑：系统弹窗、动画与稳定性
5.1 权限弹窗的时机对测试稳定性影响巨大
UI Automator能解决权限弹窗，但权限弹窗也创造了新的不稳定因素。我遇到过的最典型问题是：权限弹窗的“Allow”按钮和App界面上的某个按钮有相同文本。By.text("Allow")会匹配到多个节点，或者匹配到系统中其他弹窗的“Allow”，导致点击错误。
更进一步的坑是系统权限弹窗的不同样式在不同Android版本上完全不同。Android 11开始，权限申请的弹窗增加了“Only this time”和“While using the app”这种更细化的选项；在某些定制ROM上，甚至有一个“不允许”和一个“下次询问”的排列顺序差异。如果测试代码里写死了只点“Allow only this time”，在Android 10和Android 13上就会点不到。
我的经验是：不要只匹配一个文本，尽量用By.textContains结合By.clazz或者节点内的其他属性做出更精确的选择。比如：
val allowButton = device.wait( Until.findObject( By.textContains("While using the app") .clazz(Button::class.java.name) ), 10_000 )另外，某些厂商ROM的权限弹窗会出现一个“权限说明”过渡页，要先点击“下一步”才会出现真正的授权按钮。处理方式是在测试里先做一个通用方法“尝试点击多个候选按钮，谁出现就点谁”，而不是默认弹窗结构永远一样。
5.2 屏幕方向与跨进程启动的时序问题
跨进程启动的另一个坑发生在屏幕旋转上。如果你的用例要验证“应用切到后台再回来，屏幕方向是否正确”，那从Espresso点击触发旋转到系统完成旋转，再到UI Automator能读到新布局的节点，中间有很长的时序窗口。
我遇到过的情况是：device.wait(Until.findObject(By.res("com.example.app:id/rotatedView")), 10_000)偶尔会直接超时，但是人类肉眼看屏幕，方向已经正确、View也已经显示了。后来排查发现是设备上的“窗口动画缩放”没关导致旋转动画太长，UI Automator的节点树获取在窗口动画没完全结束时，可能读到的是旧布局的节点树。这个问题在主流的AOSP模拟器上很轻微，但在低内存真机上非常明显。
解决方案有点简单粗暴：跑测试前用ADB把系统动画全部关掉，并且把等待时间加长。
adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0不过这个一般是在CI脚本层面处理。如果你把这几行放到测试代码里“临阵磨枪”，反而会因为设置语句本身需要时间生效又引入新的竞态。我在项目里是把动画关闭写进setUp()里，保证每个用例开始时设备都是已关闭动画的状态。
5.3 pressBack与系统返回键的微妙时序
UiDevice.pressBack()看着简单，但它的返回行为跟用户手按几乎一样，会触发Activity的onBackPressed()，接着进入退出动画。在动画过程中如果你立刻device.wait(Until.findObject(...))去等应用内元素，很容易因为动画还没结束而找不到。
我最开始的做法是pressBack()之后直接接着查下一个UI Automator节点，结果偶尔就会碰到“返回动画还在播，新页面还未渲染”的死角。后来改成在pressBack()之后先做一次200ms的短等待，然后再wait条件：
device.pressBack() SystemClock.sleep(200) val mainView = device.wait(Until.hasObject(By.res("com.example.app:id/mainLayout")), 10_000)不要小看这200ms。在UI Automator的场景里，系统返回键的进程切换速度通常比应用内按钮的点击响应要快，但正因为快，UI Automator拿到节点树时Activity可能还在销毁和创建之间。短等待后再走条件等待，成功率从85%直接到了99%以上。
5.4 选择器命中的节点层级差异
最后说一个隐性的坑：同一个元素，在某些设备上可能是android.widget.TextView，在另一些设备上可能是android.widget.Button——这取决于App的主题和渲染方式。你要是把By.clazz(Button::class.java.name)写死了，测试换台设备可能就找不到。我现在的习惯是能省则省：能用By.res或By.text精确匹配的，就不加clazz；必须要加clazz的场景，优先写一个辅助函数去匹配“TextView或Button之一”，不要死等某个具体类名。
UI Automator对界面的描述能力很强，但这份强也是有成本的——它给的“节点层级”不是你以为的那个层级。你要始终记得，你在UI Automator里看到的是Accessibility节点树，不是App内部的View树。两者在大多数情况下一一对应，但在自定义View重写onInitializeAccessibilityNodeInfo、或者使用Compose这类完全自绘框架时，节点层级会跟你预期的完全不一样。遇到UI Automator找不到元素的疑难杂症，第一步不是改选择器，而是去uiautomator dump看一下屏幕上到底有哪些节点：
adb exec-out uiautomator dump /dev/tty这能把当前屏幕的节点树直接打出来，定位问题比瞎猜快得多。
总结一句我的实际使用体验：UI Automator并不是Espresso的替代品，它是帮Espresso补上“跨进程”这块短板的必要组件。一套测试策略里，能通过Espresso同步机制保证稳定的部分就交给Espresso；涉及系统弹窗、系统页面、跨应用交互的部分就放心交给UI Automator。项目里把这两者的分工理清楚，CI上的UI测试稳定性能提高一个量级。
)
