在Android开发中，Custom Views承载着大量个性化交互与绘制逻辑，但当开发者试图为这些自定义视图编写测试时，常常遭遇莫名其妙的崩溃或断言失效。其根本原因在于视图生命周期与UI线程绑定，脱离了系统环境便无法完成measure、layout、draw的完整链路。
自定义视图为何难以在普通单元测试中验证
很多开发者第一次写Custom View测试时，会直接在本地JVM单元测试里new一个自定义View，然后调用onMeasure或onDraw方法，结果要么空指针，要么尺寸计算全为0。这是因为Android的视图系统强依赖Context、Resources以及底层的显示服务。当没有Instrumentation环境时，getContext().getResources()返回的对象并不具备真实屏幕参数，导致TypedValue.applyDimension这类方法无法换算正确的像素值。
另一个容易被忽略的点是视图的绘制并非同步方法。即使你手动调用了draw(Canvas)，系统也不会真正把内容渲染到屏幕，只是执行了你重写的逻辑。如果测试意图是确认某段绘制代码没有抛异常，这种做法尚可；但若想验证界面效果，就必须借助Espresso或UiAutomator在真实环境中截图比对。下面这段代码展示了脱离环境时测量失效的典型错误：
public class MyView extends View {
public MyView(Context ctx) {
super(ctx);
}
@Override
protected void onMeasure(int w, int h) {
// 假设依赖资源中的尺寸
int size = (int) getContext().getResources().getDimension(R.dimen.item_size);
setMeasuredDimension(size, size);
}
}
// 单元测试中
MyView v = new MyView(mock(Context.class));
v.measure(0, 0); // 此处getResources返回null，直接崩溃
从架构角度看，自定义视图既是UI组件也是状态机。它的正确性包含两部分：一是内部数据到绘制指令的映射是否正确；二是外部父容器约束下布局是否如预期。普通单元测试只能覆盖第一点且极不稳定，因此Google官方更推荐用AndroidJUnitRunner在设备上执行视图测试。
基于Instrumentation与Espresso的集成测试方案
要在真实环境中验证Custom Views，首选是在androidTest目录下编写Instrumentation用例。通过ActivityScenario启动一个承载自定义视图的空Activity，再利用Espresso的onView(withId(...))执行点击或断言。这种方式的优势在于系统会完整走完从inflate到draw的流程，你自定义的onTouchEvent也能收到真实MotionEvent。
举例来说，如果一个自定义进度环需要根据手势改变角度，测试代码应当模拟滑动并校验内部字段。注意Espresso默认在主线程执行，因此视图的重绘会在断言前完成，不需要手动调用invalidate。示例如下：
@RunWith(AndroidJUnit4.class)
public class RingViewTest {
@Test
public void testDragChangeAngle() {
ActivityScenario<TestActivity> scenario = ActivityScenario.launch(TestActivity.class);
onView(withId(R.id.ring)).perform(swipeRight());
scenario.onActivity(a -> {
RingView rv = a.findViewById(R.id.ring);
assertTrue(rv.getAngle() > 0);
});
}
}
除了Espresso，Robolectric提供了在JVM上模拟部分Android环境的方案，它比真机快很多，适合做自定义视图的测量与状态单测。但Robolectric对Canvas绘制支持有限，复杂Shader或硬件加速相关代码可能不准确。因此建议将逻辑与绘制解耦：把计算角度、颜色的方法提取成纯Java类，用Robolectric测测量与事件分发，用真机测视觉与动画。
常见测试误区与稳定断言的写法
第一个误区是盲目断言getMeasuredWidth等于某个固定值。实际上父布局的MeasureSpec可能是AT_MOST模式，加上padding后实际尺寸会缩小。正确做法是在XML里给自定义视图明确layout_width并设置固定父容器，或在测试里构造确定的MeasureSpec。
第二个误区是在onDraw里写业务逻辑。一旦绘制被系统跳过（比如视图不可见），你的核心状态就得不到更新，测试也无法触发。应当保证onDraw只消费状态，状态变更放在setProgress之类的方法中并调用postInvalidate。这样测试可以直接调用setter并断言字段，无需关心绘制时机。
public class CircleView extends View {
private float progress;
public void setProgress(float p) {
this.progress = p;
postInvalidate();
}
@Override
protected void onDraw(Canvas c) {
// 仅根据progress画圆，不含计算
c.drawArc(rect, 0, progress * 360, false, paint);
}
}
// 测试
CircleView cv = new CircleView(appContext);
cv.setProgress(0.5f);
assertEquals(0.5f, cv.getProgress(), 0.01f);
最后，自定义视图若使用了自定义属性，请在测试用的Activity主题中声明相同style，否则obtainStyledAttributes会读取不到值。通过分离环境依赖、明确断言目标以及选择合适的测试框架，Custom Views的自动化验证就能从碰运气变成可重复的工程实践。
Android_Custom_Views自定义视图测试Instrumentation修改时间：2026-08-18 08:26:29