Commit Graph
3 Commits
Author SHA1 Message Date
butubb accd06df4b docs(research): 章节编号理顺(三·补 → 四,建议改动 → 五) 2026-09-13 21:02:01 +08:00
butubb ee559786e7 docs(research): 补「抓取弹窗老是错位」的真因——截图与元素树不是同一时刻(附实测)
用户澄清"是抓取的窗口老是会错位"。把几种常见猜测逐一实测排除:
两条通道元素树不一致(✗ 逐项相同)、CSS 缩放没跟着算(✗ 缩放比正确、
框位置与理论值一致)、窗口 resize(✗ 预览列固定 320px)、列表索引错位
(✗ indexOf 保住原始序号)。

真因是取数时序:
  /api/uiauto/screenshot 0.4s + /api/uiauto/elements 1.8s(两次请求)= 间隔约 1.8s;
  换成原生 u2 背靠背也仍有约 1.4s(dump 本身就要 1.3~1.8s,设备端开销改不动)。
界面只要在动(信息流/视频/动画),这两秒就足以让元素位置全变 → 框永远落在旧位置。
因为是**每次都发生**,所以表现为"老是错位"而不是偶发。

解法(写进文档待排期):①新增 /api/uiauto/snapshot 一个请求取齐(也正是
"用原始 u2"的做法,间隔降到 ~1.4s);②抓取前后各截一张做校验,不一致就
明确提示"界面在变化中,请停在静止界面再抓",而不是悄悄给一个错位的框。
2026-09-13 21:01:53 +08:00
butubb a94f63f0bf docs: 元素选择器研究——「点不到按钮」的根因是序号型选择器(附实测证据与解法)
用户反馈任务步骤老是点不到元素,怀疑"执行用的 u2"和"抓取用的 uiautodev"两条
通道不一致。建 research 分支实测,结论与假设相反:

1) **两条通道其实是一致的**:同设备同屏各 dump 一次,节点数 330/330、
   id 个数逐项相同 —— 都是同一份 UiAutomation 树,不存在"看到的不一样"。
   顺带纠正一处过时注释:uiautodev 的 `rect` 就是像素(`bounds` 才是归一化)。

2) **真凶是序号型选择器**:复现「抖音→我页面」,底部 `0qf` 只有 **3 个**
   (首页/消息/我 —— 「朋友」tab 是灰度功能,有的账号/设备没有),
   而任务里写死 `(…0qf…)[4]` → 第 4 个不存在 → 必然点空。
   同一选择器在 4 tab 设备上碰巧对、在 3 tab 设备上必错 —— 这就是"时好时坏"。

3) **解法(实测有效)**:同一 id 多实例时用**文字/描述限定**:
   `//*[@resource-id="…0qf" and @text="我"]` → 命中并把设备带进我页面(jy- 出现)。

文档里还列了同类限定条件的优先级与四条待排期改动(抓取器优先产语义选择器、
对带序号的选择器加提示、存量任务批量复核、运行期 dump 同 id 实例数)。
2026-09-13 20:56:37 +08:00