模拟器与物理设备运行Instrumentation Tests异步等待行为差异咨询

差异产生根因 #

• @UiThreadTest注解仅保证测试代码运行在UI线程，不会自动等待异步任务执行完成，测试方法执行完最后一行代码就会直接结束，断言逻辑写在回调里的话如果回调还没触发，就会被系统判定为测试通过。
• 模拟器和物理设备的系统线程调度策略存在差异：Pixel 4a (API 30) 模拟器的后台线程调度优先级更高，API请求完成后可以快速切回UI线程执行回调，在测试方法结束前完成断言；而三星Galaxy S7作为老款设备，系统对后台网络请求相关线程的优先级限制更严格，回调执行速度远慢于模拟器，导致测试提前结束。

可行修复方案 #

• 禁用硬编码线程休眠方案，改用CountDownLatch做同步等待：如果测试不需要强制运行在UI线程，可移除@UiThreadTest注解，在测试逻辑中添加同步锁：

// 初始化锁，等待1个回调触发
CountDownLatch latch = new CountDownLatch(1);
AtomicBoolean testPassed = new AtomicBoolean(false);

// 调用你的API请求函数
callApi(new SuccessHandler() {
    @Override
    public void onSuccess() {
        // 此处可添加success场景断言逻辑
        testPassed.set(true);
        latch.countDown();
    }
}, new FailureHandler() {
    @Override
    public void onFailure() {
        // 此处可添加failure场景断言逻辑
        testPassed.set(false);
        latch.countDown();
    }
});

// 最多等待10秒，避免测试卡死
latch.await(10, TimeUnit.SECONDS);
// 执行最终断言
Assert.assertTrue(testPassed.get());

• 保留@UiThreadTest注解的场景下，使用官方推荐的Espresso IdlingResource做异步等待：可直接接入对应网络框架的IdlingResource实现（如OkHttpIdlingResource），注册后Espresso会自动监听所有异步请求状态，等待请求完成后再执行后续断言逻辑，无需手动处理线程同步，可兼容全机型。

内容的提问来源于stack exchange，提问作者Diego