 butubb
|
0bc713137d
|
feat(抓取): 选择器优先语义化（同 id 多实例用 @text 限定，而非序号）+ 修掉两类"死选择器"
语义消歧（B 项）：主属性在整棵树里重复时，先找第二个属性把目标单独圈出来 ——
//*[@resource-id="x" and @text="我"] （次属性 text > content-desc > class，
单个不够就两两组合）
标 semantic:true + via；只有组合也分不开（列表里同 id 同文字）才退回
(//*[@resource-id="x"])[k] （标 indexed，前端黄标提醒脆弱）
抖音底部导航正是这个场景：tab 个数随灰度版本变（4 个 ↔ 3 个），序号必然错位。
顺带修掉两个结构性缺陷（给上面做验证时逐条 lxml 求值发现的，均非本次引入）：
1. 结构步进把 class 当标签名 —— dump 的 XML 标签**一律是 <node>**，class 在
@class 上，所以 //FrameLayout[1]/… 这类路径**永远零命中**；改 *[@class="…"][n]
2. 兜底结构路径用 @index 定位兄弟 —— 实测同级 index 会重复（状态栏/内容区/
导航栏三个兄弟全是 index="0"）；改按子节点位置 //hierarchy/*[1]/*[2]
前端：抓取列表把 text/content-desc 排到最前并加粗上色（最稳的定位依据）；
序号型从蓝标改**黄标 ⚠ 序号 k/n**，语义型给**绿标 ✓ 语义**；属性页新增
「选择器稳定性」一行说明这个选择器靠什么定位、会不会因界面变化失效。
真机实测（192.168.20.100，248 个元素）：
精确命中目标 221 → 247 ｜ 死选择器 26 → 0 ｜ 语义型 0 → 26（序号型 141 → 115）
「我」的语义选择器经 /api/steps/test 真机点击 → 命中 ✓
文档：TASK_DEV §5.3/5.4（含两个 XPath 坑）、API §8（suggested 字段表 +
snapshot 行）、research/U2_ELEMENT_SELECTORS §五/§六、backlog ②标记完成。
|
2026-09-13 22:05:47 +08:00 |
|
|
butubb
|
37a2b1c59b
|
feat(抓取): 元素检查器改成本地版"大图 + 一次取齐"——复刻云检查器的体验
用户要的是 uiauto.dev 那个检查器的体验（左边大图点元素、右边层级树、选完回填），
并希望本地复刻（云页面跨域，拿不到它的选中结果，没法自动回传）。
- core/uiauto_helper.py: 新增 `snapshot(serial)`
* **一个 u2 连接背靠背** dump_hierarchy() + screenshot()：截图与元素树同源同刻，
不再像原来那样分两个接口取（中间隔着 dump 本身的 1.3~1.8 秒）
* `_xml_to_node()`：把 u2 的 XML 节点转成 uiautodev 那套结构，直接复用既有的
选择器建议逻辑（不写第二遍）
* **双截图校验**：dump 前后各截一张，差异明显就标 `unstable`，让前端明确提示
"界面在变化中，请停在静止界面再抓"，而不是悄悄给一个可能错位的框
- web/tasks_api.py: 新增 `GET /api/uiauto/snapshot`（登录 + 设备权限）
- static/admin/editor.js + templates/admin/monitor.html:
* 抓取弹窗从 900px 加宽到 1280px，预览列从"固定 320px"改为铺满左侧 →
**图片按原始分辨率 1:1 显示**（实测 720x1650 缩放 1.000），元素框严丝合缝；
原来缩到 294px 时框全挤在一起，看着就像错位
* 工具栏显示 `720x1650 · 247 个元素 · 2370ms`；界面在变时顶部弹黄色提示条
* 鼠标在图上移动时高亮"最深命中"的元素框，便于确认真要点哪个
实测：抓取弹窗 1:1 显示、222 个框逐一贴合元素、无 JS 报错；
`unstable` 在静止界面为 false。
|
2026-09-13 21:17:12 +08:00 |
|
|
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 |
|