什么是Android Target Size目标尺寸测试？如何执行这项无障碍测试？

Target Size目标尺寸测试是Android无障碍（Accessibility）测试体系中的基础项目之一，很多应用在接入无障碍合规检测时，第一轮就会被这一项卡住。它的核心逻辑很简单：界面上所有可以被用户点击、长按、滑动的元素，其可交互区域必须足够大，否则手指难以准确命中。Android Material Design指南给出的推荐值是至少48dp宽、48dp高，这个尺寸大致对应平均指尖的物理大小。本文将从判定标准、检测工具和修复方案三个层面，详细讲解这项测试的执行方法。

Target Size测试的判定标准是什么

首先要明确一点，Target Size考察的不是控件视觉上的渲染大小，而是控件可接收触摸事件的区域大小。一个图标在屏幕上可能只显示24dp，但如果系统给它设置了足够的padding或者父容器将点击区域放大了，测试依然可以通过。反之，有些控件看起来不小，但实际响应点击的hit area只有一小块，这种情况就是典型的失败案例。

Android的官方规范来源于WCAG 2.5.8目标尺寸准则，最低要求是24dp乘以24dp，增强要求是44dp乘以44dp，而Material Design以及国内主流应用市场的无障碍检测标准普遍采用48dp乘以48dp作为合格线。也就是说，如果你要对接国内应用商店的无障碍检测，按48dp来设计是最稳妥的选择。

需要注意的是，判定范围包括所有可交互元素：Button、ImageButton、CheckBox、RadioButton、Switch、ImageView设置了点击监听的、甚至RecyclerView中item里的嵌套图标按钮。测试时会检测控件的getHitRect或者实际布局边界，视觉边界与触摸边界不一致时以触摸边界为准。另外，两个相邻可点击元素之间还应保留适当间距，靠得太近即使各自满足48dp也容易造成误触。

如何使用工具执行Target Size检测

最便捷的工具是Google官方的Accessibility Scanner，可以在Google Play上下载。打开应用后进入待测页面，点击扫描按钮，工具会自动截取当前界面并标记出所有不满足目标尺寸的控件，在结果列表里找到Target Size分类即可查看具体哪些元素过小。它的优势是零代码侵入，测试人员也能直接操作，适合快速摸底。

对于开发者，更精确的方式是使用Layout Inspector配合代码检查。在Android Studio中打开Layout Inspector，选中可疑控件，查看其布局边界尺寸换算成dp是否达标。也可以写一个自动化检测脚本，遍历View树找出所有可点击但尺寸不足的控件：

public static List<View> findSmallTargets(View root, float density) {
    List<View> result = new ArrayList<();
    if (root instanceof ViewGroup) {
        ViewGroup group = (ViewGroup) root;
        for (int i = 0; i < group.getChildCount(); i++) {
            result.addAll(findSmallTargets(group.getChildAt(i), density));
        }
    }
    if (root.isClickable() && root.getVisibility() == View.VISIBLE) {
        int minPx = (int) (48 * density); // 48dp换算为像素
        if (root.getWidth() < minPx || root.getHeight() < minPx) {
            result.add(root);
        }
    }
    return result;
}</code>

上面这段代码在View树中递归查找可点击但宽或高不足48dp的控件，-density参数可以通过getResources().getDisplayMetrics().density获取。将它接入自动化测试框架，就能在每个页面上批量执行Target Size检查，比人工扫描效率高得多。此外，uiautomator dump导出的界面XML中包含每个控件的bounds属性，也可以基于它做离线分析，适合测试团队做全量回归。

不达标控件的常见修复方案

第一种方案是直接调整布局尺寸，给小图标设置minWidth和minHeight属性，或者给ImageView增加padding并用clipToPadding控制绘制范围。推荐的做法是使用Touchpoint Sized样式，让图标视觉上保持24dp，但实际控件占据48dp：

<ImageView
    android:id="@+id/btn_close"
    android:layout_width="48dp"
    android:layout_height="48dp"
    android:padding="12dp"
    android:src="@drawable/ic_close"
    android:contentDescription="@string/close"
    android:background="?attr/selectableItemBackgroundBorderless" />

这种写法利用padding撑大触摸区域，图标本身仍然只有24dp，视觉效果不受影响，同时点击区域达到了48dp的标准。selectableItemBackgroundBorderless还能提供涟漪反馈，让用户明确感知到点击范围。

第二种方案是TouchDelegate，适用于无法修改控件本身尺寸的场景，比如第三方组件或者列表item布局已经固定。TouchDelegate允许父容器代为扩展某个子控件的点击区域：

final View parent = findViewById(R.id.item_container);
final View child = findViewById(R.id.btn_icon);
parent.post(new Runnable() {
    @Override
    public void run() {
        Rect delegateArea = new Rect();
        child.getHitRect(delegateArea);
        delegateArea.inset(-24, -24); // 四个方向各扩展24像素
        parent.setTouchDelegate(new TouchDelegate(delegateArea, child));
    }
});

TouchDelegate的原理是父View把超出子View边界的触摸事件转发给子View处理，inset传负值表示向外扩展。使用时要注意扩展区域不能与兄弟控件的可点击区域重叠，否则触摸事件的分发顺序会产生混乱。

第三种情况是相邻控件间距问题。有些应用在列表末尾放置上一页、下一页两个小按钮，各自尺寸勉强达标但紧贴在一起，误触率很高。修复思路是引入SpatialBuffering布局约束，在ConstraintLayout中通过layout_margin保证至少8dp的间隔，或者干脆合并为一个更大的分页区域。修复完成后，务必重新运行Accessibility Scanner或自动化脚本做回归验证，确认所有页面均无残留问题，再提交无障碍检测审核。

测试执行中的注意事项

执行Target Size测试时要覆盖应用的主要页面，特别是那些包含小图标操作的页面，比如输入框右侧的清除按钮、列表项中的收藏图标、视频播放器的控制按钮等，这些是失败率最高的位置。横竖屏切换后控件尺寸可能变化，两个方向都要测。另外，字号放大场景下布局会重新排布，建议在系统字体缩放最大档位下复测一遍。

还有一个容易忽略的细节是WebView内嵌H5页面的元素。原生检测工具对WebView内部元素的识别能力有限，需要借助Chrome DevTools或者手动检查H5页面中按钮的CSS尺寸是否满足44px以上的等效标准。如果是混合开发应用，建议与前端团队约定统一的触摸目标规范，从设计源头保证合规，比后期逐个修补的成本低得多。

AndroidTarget Size目标尺寸测试修改时间：2026-09-16 08:36:39