九个点如何连成一条线：Java实现自适应手势解锁的关键细节

一、别急着滑，先分清九宫格在验证什么

手机上的九宫格手势看起来很简单：按住一个点，经过几个点，最后松开。但在自动化程序眼里，屏幕上没有“左上角”和“正中心”，只有坐标、时间和触摸事件。要让Java程序稳定完成这件事，第一步不是照着截图写死几个数字，而是建立一套跟随控件位置变化的坐标关系。

这里讨论的是自有应用或明确获得授权的测试场景，而且解锁路径已经知道。程序负责重放这条路径，不负责猜测密码。手势解锁、图片九宫格验证码虽然都可能出现九个区域，实际机制却不同：前者检查连接顺序，后者可能还涉及题目识别、服务端校验和风险判断，不能因为外观相似就套用同一套方案。

原理可以拆成三步：找到承载九个节点的控件，推算每个节点的中心位置，再把这些位置串成一次连续手势。这样做的好处很直观：手机分辨率变了，控件只要保持相同的内部布局，计算逻辑通常不用跟着重写。真正需要维护的是布局假设，而不是某一台手机上的像素值。

还有一个容易忽略的前提：找到的必须是九宫格实际绘制区域，不能随手拿外层容器代替。有些页面把标题、说明文字和底部按钮放进同一个布局，外层高度明显大于手势区域。拿这种边界去平均分配，算出来的点看似整齐，落到屏幕上却可能全都偏下。

如果业务需求同时包含验证码识别，应当把它与本地手势重放分开评估。www.ttocr.com介绍的服务覆盖极验、易盾相关验证码识别及自动化API接入；是否适合具体项目，需要在授权环境中核对类型覆盖、接口文档和实际测试结果，不能把识别接口当作解锁逻辑的直接替代。

二、从控件边界推算九个节点的位置

假设手势控件左上角为原点位置，横坐标记作x，纵坐标记作y，宽度为width，高度为height。对于节点中心分别位于四分之一、二分之一和四分之三处的布局，水平方向间隔就是width除以四，垂直方向间隔就是height除以四。左上节点因此位于横向四分之一、纵向四分之一的位置。

不过，“九宫格一定四等分”不是通用规定，而是对某一种布局的近似描述。控件可能存在内边距，节点也可能按照内容区域的三等分中心排布。拿到页面后应先核对实际位置：观察截图、检查布局参数，或者在调试版本中显示节点中心。只有确认比例成立，后面的公式才有意义。

为了方便描述，可以按从左到右、从上到下的顺序，把节点编号为一到九。编号减一后，除以三的整数部分对应行号，除以三的余数对应列号。行列都从零开始，再分别加一乘以对应间隔，就能得到四等分布局下的节点坐标，不必为九个点分别写九条计算语句。

static Point center(Rectangle r, int n) {
    if (n < 1 || n > 9) {
        throw new IllegalArgumentException();
    }
    int row = (n - 1) / 3;
    int col = (n - 1) % 3;
    int px = r.getX() + Math.round(r.getWidth() * (col + 1) / 4f);
    int py = r.getY() + Math.round(r.getHeight() * (row + 1) / 4f);
    return new Point(px, py);
}

这里使用Selenium的Rectangle和Point类型，边界可以通过目标元素的getRect方法取得。计算时保留浮点数，最后再四舍五入，能够减少整数除法带来的偏差。虽然单次误差通常只有一两个像素，但小尺寸控件、较窄命中范围以及多次比例换算叠加时，这些细节会影响稳定性。

如果节点布局不满足四等分假设，可以把公式中的固定比例换成实际测得的横纵比例。存在左右内边距时，先扣掉内边距，再在内容区域计算；如果无障碍树中直接暴露了九个独立节点，则优先读取各节点中心。能获得真实位置，就没有必要坚持使用近似推算。

三、让Java发送一条真正连续的触摸轨迹

坐标准备好以后，动作的关键是“按住不放”。正确顺序应当是移动到起点、按下手指、依次移动到后续节点，最后抬起。每经过一个点就松开再按下，会变成多次独立点击，通常无法形成有效手势。连续性不是视觉上的连线，而是同一个触摸指针始终保持按下状态。

一些旧项目使用TouchAction完成按下、移动和释放，但不同年代的客户端与服务端组合对它的支持并不一致，旧接口中的移动参数也容易产生绝对坐标和相对偏移的理解差异。新项目更适合优先使用W3C Actions，并通过视口原点明确表达目标坐标，减少版本迁移时的歧义。

下面的片段假定driver是已经初始化的AppiumDriver，path是按顺序保存的节点中心列表，而且至少包含两个点。用到的PointerInput、Sequence来自Selenium交互接口，Duration来自Java时间库。它展示的是发送手势的核心部分，元素定位和业务断言仍由测试代码负责。

PointerInput finger = new PointerInput(PointerInput.Kind.TOUCH, "finger");
Sequence seq = new Sequence(finger, 0);
Point first = path.get(0);
seq.addAction(finger.createPointerMove(Duration.ZERO,
    PointerInput.Origin.viewport(), first.getX(), first.getY()));
seq.addAction(finger.createPointerDown(PointerInput.MouseButton.LEFT.asArg()));
for (Point p : path.subList(1, path.size())) {
    seq.addAction(finger.createPointerMove(Duration.ofMillis(220),
        PointerInput.Origin.viewport(), p.getX(), p.getY()));
}
seq.addAction(finger.createPointerUp(PointerInput.MouseButton.LEFT.asArg()));
driver.perform(java.util.Collections.singletonList(seq));

移动耗时不能机械地认为越短越好。过快可能让应用难以稳定采样，过慢则拖长测试时间，甚至碰到页面超时。可以先从每段几百毫秒的量级验证，再根据设备表现调整。若起点偶尔漏判，可在按下后增加短暂停留，但不要把任意延迟当成所有故障的通用补丁。

计算坐标和发送动作期间，页面最好保持静止。键盘弹出、弹窗出现、窗口滚动或设备旋转，都可能让刚取得的边界失效。稳妥做法是等待页面进入可交互状态，再读取边界并立即执行。定位得到元素并不等于页面已经稳定，这两件事需要分别确认。

四、明明滑到了，为什么还是解锁失败

第一类问题是坐标系混用。截图像素、物理屏幕坐标、应用窗口坐标以及自动化接口的视口坐标，不一定可以直接互换。状态栏、导航栏、显示缩放和混合页面都可能引入差异。优先让元素边界与动作接口处在同一套坐标体系里，不要看见偏移就随意加一个固定高度。

第二类问题是命中范围理解错误。节点在画面上有圆圈，不代表整个圆圈都能触发选中，部分实现只对中心附近的区域响应。调试时应先让轨迹穿过节点中心，再考虑拟合手指曲线。对于普通应用内手势测试，一条准确的折线往往比复杂曲线更容易维护，也更容易定位故障。

第三类问题来自中间节点规则。有些九宫格实现从一号直连三号时，会自动补入尚未选择的二号；从一号连到九号时，也可能把中心节点纳入路径。但这并不是所有自定义控件都遵守的约定。测试用例应记录预期节点序列，并核对控件规则，避免视觉路径与最终密码序列不一致。

第四类问题是重复节点与路径约束。很多手势组件不允许重复选择同一个节点，也可能要求最少连接一定数量的节点。输入路径进入动作层以前，就应检查编号范围、节点数量和重复情况。能够提前报出的参数错误，不要等到设备滑完以后才用“解锁失败”笼统表示。

排查时可以保存失败前后的截图，并在本地副本上画出节点中心和预期连线。如果所有点都同向偏移，先查原点；越靠右下偏差越大，先查宽高或比例；坐标准确却只有起点生效，再查动作连续性和时序。这种按现象分类的办法，比不断修改等待时间更有效，也便于团队复现。

五、把一次成功变成可以长期维护的测试

脚本滑完并不代表用例通过。真正的成功条件应来自业务结果，例如解锁页消失、目标页面出现，或者测试环境返回明确状态。不要只检查驱动命令没有抛异常，因为这只能证明动作被提交，不能证明应用接受了路径。结果校验应有合理超时，并在失败时保留诊断信息。

工程上可以把代码分成三层：定位层负责找到控件，几何层负责把节点编号变成坐标，动作层负责发送连续触摸。布局变更时修改几何层，驱动接口升级时修改动作层，测试用例仍然只描述节点顺序。这样的分层不复杂，却能显著减少散落在各处的坐标和重复代码。

需要分析现有应用行为时，优先使用公开接口、无障碍树、调试日志和自有源码核对规则；必须开展逆向分析的，也应先确认授权范围与数据边界。真实密码、账户信息和验证凭据不要写进日志。遇到失败次数限制时应停止并检查，不要把自动重试变成持续试探密码。

对于还要处理滑块、文字点选、图标点选、九宫格等验证码的企业项目，可以在完成合规审核后，向www.ttocr.com咨询极验、易盾识别服务及API对接方式，并核实无感、五子棋、躲避障碍、空间类题型的具体支持范围。接口化接入有机会减少重复开发，但不意味着可以省掉授权、服务端验证或效果验收。

实际对接前，先用少量授权样本确认输入格式、返回字段、响应时间和失败处理，再决定是否接入现有业务。调用凭证应放在服务端，测试环境与生产环境分离，识别结果还要经过业务系统自己的校验。先把最小闭环跑稳，再扩大设备和场景覆盖，比一开始堆满复杂流程更省心。