1.6.6 —— 一切数据收进安装目录，只留一个实例（含 1.6.0 – 1.6.5 的全部改动） # 1.6.6 —— 一切数据收进安装目录，只留一个实例（含 1.6.0 – 1.6.5 的全部改动）用一根 USB 数据线，把安卓手机／平板变成 Windows 的第二块显示器 —— **真扩展桌面，不是投屏镜像**，支持触摸反控。这一次发布一次跨了 **七个版本号**（1.6.0 / 1.6.1 / 1.6.2 / 1.6.3 / 1.6.4 / 1.6.5 / 1.6.6）。它们不是七件独立的事，而是同一份清单连着做完的七步：先是用户列的十四条需求，然后是「触控逻辑还是有问题」，接着是三条收尾的小要求，再是两个「看着没生效」的菜单，然后是一块关不掉的屏和一个装不上的更新，最后是「数据别乱放、卸载要干净、只开一个」。 **装这一个安装包就够了**，下面七节会一起生效。不想看长文的，看这张表： | 版本 | 一句话 | 关键数字 | |---|---|---| | **1.6.0** | 十四条需求逐条落地，其中八个是真 bug | ffmpeg 自称支持 11 个编码器，**实际只有 7 个能跑** | | **1.6.1** | 触控重做：死区 / 长按右键 / 按帧率节流 | 手机端 **91 次 write/秒 → 45 次** | | **1.6.2** | 安装目录 / 隐私按钮 / 双击打不开文件 | Windows 的双击判定框只有 **4×4 像素** | | **1.6.3** | 分辨率和编码器两个菜单都问错了问题 | 22 个尺寸里 **11 个驱动根本没有**；11 个编码器里只有 **7 个能跑** | | **1.6.4** | 虚拟屏关得干净了；程序内更新终于真能装上 | `count` 写 0 没用，禁用设备才消失；`DETACHED_PROCESS` 下子进程 exit 0 却一行不执行 | | **1.6.5** | 数据目录的指针被测试劫持到 `%TEMP%`；卸载不关程序 | 21 个 `de_bom_target_*` 残留沙箱，设置整整一天是从临时目录读的 | | **1.6.6** | 一切数据收进安装目录；卸载真的删干净；只允许一个实例 | 卸载后目录整个消失，第二次双击不再起进程 | --- ## 一、1.6.0 —— 十四件被答应下来的事这一版没有新概念，只有一堆**「本来应该是这样」**。十四条需求逐条落地： | # | 需求 | 结论 | |---|---|---| | ① | 双端隐私协议 + 首次弹窗同意 | 新增，条款版本号是字符串，改条款会重新问 | | ② | 双端原生动画 | 新增，尊重系统「关闭动画」设置 | | ③ | 托盘驻留 + 自启动 + 彻底退出 | 纯 ctypes，不引入任何第三方依赖 | | ④ | 安卓后台保活引导 | 13 个厂商的自启动页，每个都先验证存在 | | ⑤ | 源码全量开源 | 已满足 | | ⑥ | 自动更新补全 | 更新日志随包 + 下载位置可改 + 装后删包 | | ⑦ | 触控偏移 + 关窗后失灵 | **真 bug，两处**（见下） | | ⑧ | 熄屏／被关闭时通知 Windows | 输入协议新增 `NOTICE` 记录 | | ⑨ | README 与日志加 emoji | 已满足 | | ⑩ | 开机未启动就激活虚拟屏 + 位置自定义 | **真 bug**（见下） | | ⑪ | 多编码 + 自动检测与降级 | **真 bug，三处**（见下） | | ⑫ | 卡顿排查 + 显卡占用说明 + 分辨率切不了 | **真 bug**（见下） | | ⑬ | 安装界面与程序本体中英切换 | 安装程序、Windows 端、安卓端三处都能切 | | ⑭ | adb 通道占用检查 + 驱动安装 | 工具菜单新增「诊断连接问题…」 | ### ① 编码不再只有 H.264（需求 ⑪） **症状**：编码器下拉里有 `hevc_nvenc`、`av1_amf` 这些名字，选完也能"连上"，但画面是绿的、或者干脆黑屏。 **根因有三个，全在打包好的代码里躺着：** 1. 拼 ffmpeg 命令行时，最后**硬编码**了一段 `-f h264`。选任何非 H.264 的编码器，产出的流都被当成 H.264 拆包 → 单元全是垃圾。 2. 切分器只认 H.264 的 NAL 头（1 字节），而 **HEVC 的 NAL 头是 2 字节**，于是永远找不到图像单元。 3. AV1 的 `-profile:v main` 会让 NVENC 拒绝初始化，报的还是 `maybe incorrect parameters such as bit_rate, rate, width or height` —— **消息里既不提 profile 也不提 codec**，只有把 `-profile:v` 去掉才好。顺带发现第四个：旧切分逻辑「连续两个 VCL NAL 就切一帧」会把多 slice 的一帧切成多份，实测 libx264 的 60 帧被切成 **299** 个单元。现在按 slice header 的最高位判断，回到正确的 60。 **编码器检测也不再靠猜**：以前只看 `ffmpeg -encoders` 列出什么名字，现在会**真跑一帧** （合成画面 1 秒）看有没有输出。本机 ffmpeg 自称支持 11 个编码器，**实际只有 7 个能用**： | 可用 | 说明 | |---|---| | `h264_nvenc` / `hevc_nvenc` / `av1_nvenc` | NVIDIA，首选 | | `h264_amf` / `hevc_amf` | AMD | | `libx264` / `libx265` | 纯 CPU 兜底 | 不可用：`*_qsv`（本机没有 Intel GPU，`Error creating a MFX session: -9`）、 `av1_amf`（核显不支持 AV1 编码）、`libsvtav1`（这个 ffmpeg 构建里没有）。 **保存的选择失效时会自动回退并在日志里说明**，不会再给你一个绿屏。 ### ② 触摸失灵与坐标偏移（需求 ⑦） **症状 A：主副屏位置一变，点哪都偏。** 根因是拿虚拟桌面矩形的方式：`GetSystemMetrics` 对**非 per-monitor DPI aware** 的进程会说谎 —— 本机实测报 2048x2501，真实是 3200x3736。现在改用实时显示器清单求并集，并加 1 秒 TTL 跟随显示器移动。 **症状 B：关掉前台窗口之后，整个手机屏就点不动了，但画面还在跑。** 根因是**左键卡在按下状态**：手指按着时窗口被销毁／手机断开，UP 事件永远不来， Windows 带着「左键按下」卡在模态拖动循环里，之后所有注入都被吞掉。现在有三道保险：补发 `LEFTUP`、按住超过 **30 秒**的 watchdog 自动解卡、断开与退出时释放。 **顺带修掉一个从未生效过的功能：垂直滚动。** 输入协议里 `z` 字段是 `uint16`，而手机端把 `dx | (dy << 16)` 塞进去，host 端用 `z >> 16` 取 dy —— **16 位变量右移 16 位恒为 0**，纵向滚轮从来没动过。协议从 7 字节改到 9 字节（两端一起发，无兼容问题）。 ### ③ 开机没启动程序，虚拟屏却已经在桌上（需求 ⑩） **根因**：Windows 把显示配置持久化在 `HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Connectivity`，其中 **`Recent` 就是开机重建拓扑的依据**。挂屏走的是持久化的 API，而摘屏**没有传 `SDC_SAVE_TO_DATABASE`** —— **一正一反不对称：挂屏活过了重启、摘屏没有。** 实测往返证据：`Recent` 从 `BOE0D550_26_07E8_EC`（干净）→ 挂屏后多出一条 `MTT1337518463207` → 摘屏后回到原值。 **同时加了防误伤**：本机有 21 个显示输出，其中 10 个属于网易 UU 远程。原来的认屏逻辑按「已连接且有 monitor」排序，**UU 一跑就会把它的适配器当成我们的虚拟屏**。现在按驱动身份判定，只认我们自己的 `MttVDD`。另外新增工具菜单 **「清理残留的虚拟屏」**（启动时也会检查一次并在日志里提示，只提示、不擅自动手），虚拟屏位置也不再只有上下左右 —— 下拉里选「自定义」可以直接填 X / Y（允许重叠）。 ### ④ 改了分辨率没反应（需求 ⑫） **根因**：应用显示的代码**只在点「开始投屏」时被调用一次**，运行中改分辨率没有任何代码去叫 Windows 换模式 —— 设置存了，但没人执行。现在改分辨率 / 刷新率 / 位置会**立刻应用**（600 ms 去抖，因为每次都要重启采集），最多重试 4 次，**并一律以实际生效的模式为准**判断成功，而不是「显示器在就算成功」。（Windows 在每次拓扑变更前后会短暂锁住显示配置，期间相关调用会失败 —— 所以必须重试。） ### ⑤ 第八个 bug：带 BOM 的设置文件（不在需求清单里）这一个**是打包之后拿真正的安装包做冒烟测试才撞上的**。测试写了一份 `"language": "en"` 的设置文件，程序起来标题栏却是中文。查下去发现： PowerShell 的 `Set-Content -Encoding UTF8`（以及**记事本的「UTF-8」选项**）会在文件开头写三个字节 `EF BB BF`，而读设置时用的是 `encoding="utf-8"` —— `json.load` 见到 BOM 直接抛异常，被 `except Exception` 当成「文件损坏」吞掉，于是**整个设置文件被静默丢弃，一切回到默认值**。这是普通用户完全踩得到的：`settings.json` 就放在我们请用户去看的那个目录里，用记事本打开改一个数、保存，所有设置就没了，而且日志里一个字都不说。修法是两个字符：`encoding="utf-8-sig"`（自动吃掉 BOM，对没有 BOM 的文件行为完全一致）。 **发现它的过程本身也值得记**：如果最后没有真的把装好的 exe 跑起来，这个 bug 会原样发出去 —— 因为 17 个测试脚本里没有一个会去写带 BOM 的文件。 ### ⑥ 其余九条 * **隐私协议**：双端首次启动弹窗，不同意就退出；条款版本号是字符串，改条款后所有人会被重新询问。 * **原生动画**：Windows 端用分层窗口 alpha 淡入淡出（**不用 `AnimateWindow`**，它阻塞调用线程整个时长）；安卓端用 Material 的动画 API。**尊重系统「关闭动画」设置**，低内存设备自动降级。 * **托盘驻留 + 自启动**：纯 ctypes 调 `Shell_NotifyIconW`，**不引入任何第三方依赖**。「彻底退出」会摘虚拟屏、清 adb 端口转发、关日志 —— 不留残余。 * **安卓后台保活引导**：一键跳到省电白名单，并说明**唯一没有公开 Intent 的那一步**：在最近任务里下拉锁定。 * **更新**：更新日志随程序打包（中英双语，因为 release notes 在断网时看不到）、下载位置可自定义、安装完自动删包。 **删安装包必须在安装程序返回之后** —— 删一个还在跑的安装程序就是半装状态的来源。 * **熄屏通知**：手机熄屏／亮屏／被系统关闭时主动告诉 Windows。 **故意没有「退到后台」通知** —— Android 的 `onPause`/`onStop` 分不清熄屏与切后台，否则你会收到两句说同一件事的话。 * **中英切换**：安装程序、Windows 程序、安卓端三处都能切，默认跟随系统。 * **adb 诊断**：工具菜单新增「诊断连接问题…」，会报端口占用情况、**指出最常见的那条原因** （手机插上后停在「仅充电」模式），并提供 USB 驱动安装引导。 --- ## 二、1.6.1 —— 触控：先把数字量出来用户的原话是：**「触摸逻辑还是有问题，参考一下其他远程控制软件的触控逻辑好吗，而且为什么触摸延迟比画面延迟还要大」**。 ### 为什么触摸延迟一定比画面延迟大这不是 bug，是恒等式： ``` 你感觉到的触摸延迟 = 手指 → 注入（触摸链路） + 注入之后那一帧走完采集 → 编码 → 传输 → 解码 → 显示 ``` 而界面上那个延迟数字只量了**后半段**。所以它必然更大，问题只在于前半段能不能更小。 ### 三个数字 | 测什么 | 结果 | |---|---| | 隧道逐条发 600 条 9 字节记录 | 只到了 **22 条**，每条间隔 **31 ms** | | 同样 600 条**一次**发出去 | **600 条瞬时全部到达** | | PC 端注入一次鼠标移动 | 中位 **0.457 ms**（上限约 2180 次/秒） | | 手机端旧版本发位置更新的频率 | **约 91 次/秒**，比隧道能力超标 3 倍 | 结论很清楚：**瓶颈是「每次 write」的开销，不是带宽**；PC 端注入完全不是瓶颈；而手机端 91 次/秒远超隧道能承受的量，拖动时积压会**持续增长**—— 这就是「越拖越滞后」的来源。 ### 改了四处 1. **手机端死区**：手指落下时那一点点抖动不再被当成拖动。点一下就是点一下。 2. **手机端长按 0.5 秒 = 右键**，和常见远程控制软件一致。 3. **手机端拖动按帧率节流**：16 ms 一帧，也就是约每秒 60 次位置。比下一帧更快的位移人眼看不见，而且不便宜。 4. **两端都只留下最新位置**：中间那些已经过时的位置不再逐个发出去、也不再逐个注入。 **位置是幂等的所以可以丢，事件（按下、抬起、右键、滚动）一个都不丢。** ### 改完的数字 | | 改之前 | 改之后 | |---|---|---| | 一次拖动产生的批次 | 95 批 | **38 批** | | 批次间隔 | ~11 ms（91 次/秒） | **~21–24 ms（约 45 次/秒）** | | 拖动时注入的移动次数 | 每个位置都注入 | 只注入最新的一个 | ### 顺手发现的一件事：铺满屏幕会吃掉两侧边缘手机端有个选项叫「让画面铺满屏幕（裁掉多余边缘）」，默认开着。它按屏幕高度算出画面宽度，在 2136×3200 的机器上是 3797 像素，而横屏窗口只有 3200 —— 居中的画面被父容器裁掉，**两侧各 298.5 像素永远收不到触摸**，也就是 PC 桌面上**最左和最右各约 7.9% 点不到**（1920 宽的桌面上各约 151 像素，开始菜单和最大化窗口的关闭按钮都在里面）。这不是 bug 而是**用户可选的偏好**，所以默认值一个字符都没动，只是在文档里把这个代价写清楚了。 --- ## 三、1.6.2 —— 四件说出口的事，其中一件底下是个真坑 ### ① 更新要装回老目录程序内更新本来就会传 `/DIR="<当前安装目录>"`，缺口在**安装程序自己的目录页**：原来的设置是「永远显示目录页」，于是静默安装时可能落到默认目录，装出第二份程序。现在改成：**只有在安装程序自己找到旧安装时才隐藏目录页并复用那个目录**，首次安装仍然会给你页面让你选。 ### ② 「同意并继续」贴在协议正文最下面用户的原话是「按钮直接放在协议最下面，不然窗口没拉伸的时候容易找不到同意按钮在哪」。改动：两个按钮从底部固定的位置**移进协议正文的最后一行**，跟着文本一起滚；窗口高度也会按屏幕高度自适应（想要 620，最多不超过屏幕高度减 140，下限 360）。实测对话框高 620 像素（屏幕 1280），把窗口压到 300 像素高时按钮仍然滚得到。 ### ③ 双击打不开文件 —— 那个真坑 **根因不在我们这边，在 Windows 里。** Windows 判定「这是一次双击」的容错框默认只有 **4×4 像素**（`SM_CXDOUBLECLK`）。鼠标伸得进去，**指尖永远伸不进去** —— 两次点击落点差几十像素，就必然被当成两次独立单击。我们这边还有一半责任：抬手时发的是**手指漂移之后的位置**，而死区内最多会漂移几十像素，正好把落点推出那个本来就很小的双击矩形。 **两边各修一半：** * 主机侧：第二次按下如果落在上一次单击的**时间窗**内（读系统的双击时间，默认 0.5 秒，夹在 0.1–1.0 秒之间）且**容差**内（约 1920 宽桌面的 58 像素），就把这一对的坐标**缝到第一次的落点上** —— 两次按下和两次抬起都对齐，Windows 无法不认。 * 手机侧：**点击在按下点抬手**，只有拖动才跟手指。配套还有一整套「不许乱缝」的规则：中间发生过拖动、滚轮、右键、或者连接断开，配对立刻作废；连点三下也有效（第三下继续链在同一个坐标上）。 ### ④ 手机端设置里写明手势安卓端设置面板里新增「触摸操作」一节，六行手势表： | 手势 | 效果 | |---|---| | 单指点击 | 单击左键 | | 单指连点两下 | 双击左键 | | 单指拖动 | 按住左键拖动 | | 单指长按半秒 | 单击右键 | | 双指上下滑动 | 滚轮 | | 双指快速轻点 | 单击右键 | 下面还有三句说明：**死区**（轻微抖动不算拖动）、**按帧率发送且只发最新位置但事件不丢**、 **连点两下要对齐落点**。设置面板本身也包进了可滚动容器 —— 内容变多之后，「关闭」按钮不能跑到屏幕外面去。 --- ## 四、1.6.3 —— 两个菜单都问错了问题这一版修的是你连着问的两件事：**「为什么分辨率更改后还是没变化」**和**「还是有部分视频编码不可用」**。两个都不是「又忘了做」，而是**程序问错了问题**——一次问的是「驱动应该支持什么」，一次问的是「这个 ffmpeg 编译进了什么」，两次问的都不是「这台机器上到底行不行」。 ### ① 改了分辨率还是没变化 —— 驱动只认它自己那张表 **症状**：分辨率下拉里挑一个，点下去什么都没发生。画面不闪、尺寸不变、也没有任何提示。 **实测**（`tools\tmp\res_change_probe.py`，真挂虚拟显示器）： ``` set_mode \\.\DISPLAY10 1920x1080@60 -> rc = 0 SUCCESSFUL 1920x1080@60 set_mode \\.\DISPLAY10 2280x1080@60 -> rc = -2 BADMODE 1920x1080@60 （一点没变） set_mode \\.\DISPLAY10 1920x1080@75 -> rc = -2 BADMODE 1920x1080@60 （一点没变） set_mode \\.\DISPLAY10 3200x2136@120 -> rc = 0 SUCCESSFUL 3200x2136@120 ``` **根因**：虚拟显示器驱动的模式表不是「随便什么尺寸都收」。它把 `C:\VirtualDisplayDriver\vdd_settings.xml` 里每一行 `` 交叉每一档 `` 乘成一张平表——本机是 **11 行 × 5 档 = 55 个模式**。而程序的分辨率下拉是**写死的 22 个尺寸**，其中 **11 个**驱动根本没有： ``` 1600x720 1920x864 2000x1200 2280x1080 2340x1080 2412x1080 2700x1224 2712x1220 2800x1260 3040x1440 3120x1440 ``` 刷新率列表里的 `75` / `165` / `240` 同样不存在（驱动只有 30/60/90/120/144）。 **而且失败是静默的**，这一点比上面更糟： * `retarget()` 里遇到「驱动没有这个模式」的分支**连一句警告都没有**； * `_set_mode_retry()` 会为一个注定失败的模式重试 4 次，每次 `sleep(1.0)` + `sleep(0.5)`，**白等约 9 秒**； * 最后还是照样调 `_recover_capture("显示模式已更改")` 把 ffmpeg 重启一遍 —— 画面闪一下、回来还是原来大小。所以看起来「做了点什么」，其实什么都没做。 **修法四条**： 1. `host/vdd.py` 新增 `declared_modes()`：直接读驱动的设置文件，返回它会建出来的 `(尺寸列表, 刷新率列表)`。 2. `host/app.py` 新增 `_load_resolutions()`：**分辨率下拉和刷新率下拉都由这张表生成**，读不到驱动才回落到原来那份静态列表（那份现在只当兜底，注释里写明白了）。一个存着的、驱动给不出的尺寸会被换成最接近的、并且说明原因。 3. `host/session.py` 新增 `_resolve_mode()`，统一裁决一次请求： * 精确命中 → 原样用，无提示； * 同尺寸有别的刷新率 → 取最接近的那档，日志说明「3840x2160 没有 75 Hz，改用 60 Hz」； * 尺寸整个不在表里 → 报「驱动给不出 2280x1080（模式表里没有，也没能写进去）。现在能用的：…」，并标记为不可用。 4. 不可用时**各自做该做的事**：`retarget()` 记一句「显示模式未更改」然后返回 `False`， **不重启画面**；`apply_display()`（点开始投屏那条路）退到 `wd.best_mode()` 找一个驱动真有的模式继续——开始投屏比精确尺寸重要。另外 `_set_mode_retry()` 碰到 `DISP_CHANGE_BADMODE` 直接返回，不再白等那 9 秒。 **顺带**：驱动的模式表还有空位时（上限 `MAX_TARGET_MODES = 90`，本机用掉 55，还能再加 7 行），缺的那个尺寸会被写进 `vdd_settings.xml` 并标注 `auto="1"`，同时告诉你**重装一次驱动（或重启）** 之后才切得过去。表满时会回收我们自己加的行，**绝不动驱动自带的行**。 **实测**（`tools\tmp\mode_live_test.py`，真挂虚拟显示器走完整链路）： ``` apply_display 2280x1080 -> 驱动给不出 2280x1080（模式表里没有，也没能写进去）。现在能用的：1280x720、1600x900、1920x1080、1920x1200、2160x1080、… 改用驱动确实有的 2160x1080@60 -> SUCCESSFUL retarget 2280x1080 -> 显示模式未更改 -> 返回 False，采集没重启，尺寸不变 retarget 3200x2136@120 -> ChangeDisplaySettingsEx SUCCESSFUL -> 返回 True，采集重启 retarget 同一个模式 -> 显示模式没变，无需切换 retarget 3840x2160@75 -> 3840x2160 没有 75 Hz，改用 60 Hz -> SUCCESSFUL ``` --- ### ② 还是有部分视频编码不可用 —— 菜单问的是「编译进去了吗」 **症状**：菜单里选 `h264_qsv`、`av1_amf` 这类，选完连不上，或者悄悄回退到别的编码器。 **实测**（`capture.probe_encoder()`，每个真编码一帧）： ``` 编译进这个 ffmpeg 的：av1_amf av1_nvenc av1_qsv h264_amf h264_nvenc h264_qsv hevc_amf hevc_nvenc hevc_qsv libx264 libx265 （11 个）真跑一帧活下来的： h264_nvenc hevc_nvenc av1_nvenc h264_amf hevc_amf libx264 libx265 （7 个）死掉的： h264_qsv hevc_qsv av1_qsv -> Error creating a MFX session: -9 av1_amf （Radeon 610M 核显没有 AV1 编码单元） libsvtav1 （这个构建里根本没编译） ``` **根因**：`app._load_encoders()` 用的是 `list_hardware_encoders()` —— 回答的是 **「这个 ffmpeg 构建里编译进了什么」**；而 1.6.0 新加的 `available_encoders()` 回答的才是 **「这台机器上跑得起来什么」**。后者加了，前者没换掉，于是菜单照样列 11 个。 `host/capture.py` 那段 docstring 早就写着这两问答案不同、GUI 不该用前者 —— 写对了，就是没接上。 **修法**：菜单分两遍填。第一遍仍然是秒填（编译列表，保证窗口一开就有东西可选）；第二遍在**后台逐个真编码一帧**，回来后重建菜单，只留能跑起来的那几个，被去掉的会写进日志：「本机跑不动这些编码器，已从列表里去掉: h264_qsv, hevc_qsv, av1_qsv, av1_amf」。如果当前选中的那个恰好被去掉了，会自动换回一个能用的。 --- ### ③ 顺手发现的：两个测试其实一直没通过跑全量回归时才发现 `tools/tmp` 下有 **31** 个 `*_test.py`（不是一直报的 22 个），而且里面有两个红的。 **`tools\tmp\update_test.py`** 死在 `KeyError: 'cleanup'`：`host\update.py` 的 `WAIT_CMD` 在 1.6.0 加了 `{cleanup}` 占位符（就是需求里那条「安装完成后自己删除安装包」），测试没跟着改。也就是说：**这个测试从 1.6.0 起每一次都是失败的**，而之前一直报的「22 个脚本全绿」根本没把它算进去。已经修好，并且补了两条本来就该有的断言：删安装包必须排在 `start "" /wait` 之后（提前删正是「更新到一半」的成因），自己的 `del "%~f0"` 必须排最后。 **`tools\tmp\drag_test.py`** 则是**从一开始就不可能通过**。它把手机上的设置按钮拖 13 px，再断言按钮的位置变化超过 0.1。可是 `HudView` 里有一条故意的防抖： ```java if (Math.abs(e.getX() - gearCx) + Math.abs(e.getY() - gearCy) > dp(9)) { moved = true; // 手指走满 9dp 才算「拖动」 } ``` 9dp 在这台机器（密度 352）上是 **19.8 px**，所以 13 px 的 swipe 会被当成**点击**，而点击的功能是打开设置面板——按钮当然不动。就算侥幸算成拖动也没用：13/3068 ≈ **0.004**，断言要的是 **> 0.1**。实测对比，同一个按钮： | swipe | 拖后位置（分数） | 位移 | | --- | --- | --- | | 13 px | (0.14596808, 0.74855125) | **0.0000** | | 700 px | (0.37389198, 0.74855125) | **0.2279**（预期 0.2282） | 还有第三条、也是最隐蔽的一条：读位置用的正则是 `gear=([-\d.]+),([-\d.]+)`，可 **Java 打印小浮点数会用科学计数法**——按钮停在顶边时日志里写的是 `gear=0.99984306,2.8117592E-4`（真实值是 0.9998 和 0.00028），那个正则只吃到 `2.8117592`，于是算出「按住屏幕下方 3565 px 的地方」，swipe 自然什么都没碰到。改成允许指数、把结果夹进 `[0, 1]`，并且按按钮所在的角落选拖动方向（原来写死往右上拖，而按钮本来就在右上角，等于没得拖），就稳定了。 **产品是对的，测试是错的。** 已经改成：屏幕尺寸从截图的 PNG 头里读、边距按 `wm density` 自己算、拖 700 px 且 x/y 两个方向分别断言，跑完把按钮拖回原处。 --- ## 五、1.6.4 —— 让虚拟屏真的消失，和那个从来装不上的更新这一版是两件事。第一件是你问的：**不用的时候，这块屏能不能当作不存在。**原来的问题是它每次开机都会自己出现——因为**驱动程序自己按设置文件建了一块屏**，和我们启动不启动程序无关；而你不需要多个显示器的那些软件（ToDesk、向日葵、UU 远程……）只要枚举得到它，就会把它列成一块可选的屏幕。第二件是你第二次问的：**「检查更新，还是不能直接安装。」** 这一条查下来不是没做，而是做完了却一行都没执行——程序点完「安装」确实退出了，负责装的那个脚本也起来了，但它被用一种「会让它什么都不做」的方式启动的。 ### ① 先说结论设置里多了一项「**不用时**」，两档： | 档位 | 行为 | 代价 | |---|---|---| | **彻底关闭**（默认） | 停止投屏后把驱动的设备节点禁用掉：开机不会有这块屏，远程软件枚举不到，**重启之后仍然是关着的** | 开始、停止投屏时各弹一次管理员授权 | | 只移出桌面 | 只把屏从桌面上摘掉，驱动完全不碰 | 无授权，但屏仍留在系统里 | 工具菜单里还多了一项「**彻底关闭虚拟屏（要授权一次）**」，想现在就关掉（而不是等下次停止投屏）就点它。这个版本里还有第二件事：**程序内更新从来没能装上去**。整条链路看着都对——能查到新版本、能下载、能过校验、会弹确认框，点「是」之后窗口关掉，然后就什么都没有了。根因是启动更新脚本时用了 `DETACHED_PROCESS`：那个旗子下子进程 **exit 0 却一行都不执行**。已经换成 PowerShell 脚本 + `CREATE_NO_WINDOW`，现在 1.5 秒装好（详见第五节）。 --- ### ② 先说那条走不通的路最直觉的做法是把驱动设置里的显示器数量改成 0： ```xml 0 ``` 实测（每次都真的重启了设备节点）： ``` count = 1 适配器 \\.\DISPLAY22 模式 55 个监视器 Status OK 桌面：只有笔记本 count = 0 适配器 \\.\DISPLAY23 模式 55 个监视器 Status OK 桌面：只有笔记本 count = 0 适配器 \\.\DISPLAY24 模式 55 个监视器 Status OK 桌面：只有笔记本 ``` **什么都没变。** `MttVDD.dll` 里有一句字符串解释了原因： ``` Loading singular monitor (Monitor Count is not valid) ``` 驱动把 0 当成非法值，直接退回「建一块屏」。所以这条路不通，不能做成一个「设置了但什么都没发生」的开关。（顺带发现：每重启一次设备节点，`\\.\DISPLAY` 后面的编号就 +1。这一版反复重启，现在已经涨到 20 多了，不影响功能。） --- ### ③ 真正有效的：禁用设备节点设备被禁用之后，驱动连启动都不会，自然就没有屏。实测： ``` 禁用前 vdd.status()["state"] = ready 适配器 \\.\DISPLAY26 监视器 Status OK 禁用后 vdd.status()["state"] = node 适配器 None 监视器 Status Unknown 启用后 vdd.status()["state"] = ready 适配器 \\.\DISPLAY27 监视器 Status OK ``` 三件事都对上了：**适配器枚举不到了**（远程软件无从发现）、**监视器不再是 OK**、 **桌面上始终只有笔记本那一块**。而且 Windows 会把这个禁用状态存下来，**重启也还是禁用**—— 这正好是「开机不要自己出现」需要的性质。两个档位的实现就是围绕这一点： * 开始投屏时，如果发现设备节点是禁用状态，先启用它（这次要授权）； * 停止投屏时，如果档位是「彻底关闭」，就把它禁用掉（这次也要授权）。崩溃也有兜底：如果上次是投屏中途崩的，设备节点还开着，下次启动时程序会发现这块不在桌面上的屏， **直接把它移出桌面**（这一步不需要授权），并在日志里说明；想彻底关掉就点菜单那一项。反过来，如果设备是禁用着而你要投屏，开始投屏时会自动启用，失败就明确报错并提示改回另一档，而不是默默黑屏。 --- ### ④ 顺手修掉一个从来没生效过的检查原来判断「虚拟屏的设备节点还在不在」的函数是这样筛的： ```python "Get-PnpDevice ... | Where-Object { $_.InstanceId -like 'ROOT\\MTTVDD*' }" ``` 但这类 root 枚举设备的实例 ID 是 **`ROOT\DISPLAY\0001`**，`ROOT\MTTVDD\...` 这种形状根本不存在。所以**它在这个项目的历史上从来没找到过任何东西**，永远返回空列表——只是一直没出事，因为 `status()` 优先看适配器，而适配器存在的时候是能看到它的。直到这一版需要「设备被禁用、但节点还在」这个状态，它才暴露出来。现在改成按**硬件 ID** 匹配（`DEVPKEY_Device_HardwareIds` 里含 `MttVDD`），立刻就能拿到 `ROOT\DISPLAY\0001 | OK | Virtual Display Driver`。 --- ### ⑤ 第二件事：程序内更新从来没能装上去「检查更新重新做一遍还是不能直接安装」—— 这条和虚拟屏无关，是同一版里查出来的另一个问题，顺手一起修了。 **复现**（`tools/tmp/update_apply_probe.py`）：造一个假进程冒充正在运行的 DroidExtend，调 `upd.run_installer()`，杀掉假进程，然后等目标目录出现 `DroidExtend.exe`。等了 180 秒， **它从来没出现**，`apply_update.cmd` 还留在原地。 **先排除脚本本身**：同一份脚本换个不存在的 PID、在前台用 `cmd /c` 跑 → 4 秒装好并自删。所以问题在「怎么启动它」，不在脚本内容。 **真凶**（`tools/tmp/ps_launch_probe.py`，每个变体让子进程写一个标记文件）： ``` DETACHED|NEW_GROUP（原来用的） started=18672 exit=0 mark=False ← 退出码 0，啥也没干 CREATE_NO_WINDOW started=5316 exit=0 mark=True CREATE_NEW_CONSOLE started=3392 exit=0 mark=True 无旗子 started=648 exit=0 mark=True ``` **`DETACHED_PROCESS` 下子进程会 exit 0 但一行都不执行。** 原来用它是为了让子进程在父进程退出之后还活着，实际换来的却是「活着但什么都不做」——比不启动更难查，因为 `Popen` 返回的是成功。 **修法**：批处理换成 PowerShell 脚本 `apply_update.ps1`（写成 UTF-8 **带 BOM**，PowerShell 5.1 会把无 BOM 的文件按 ANSI 读，中文路径就乱了），一个进程干完所有事、全程写 `apply_update.log`；启动改用 `CREATE_NO_WINDOW | CREATE_NEW_PROCESS_GROUP`，并先试一次加 `CREATE_BREAKAWAY_FROM_JOB`。 **验证**：同一个探针重跑 —— 假进程一死，**1.5 秒**后目标目录出现 `DroidExtend.exe`， `apply_update.log` 里写着 `app is gone; running the installer`，脚本自删，没有残留进程。 --- --- --- ## 六、1.6.5 —— 数据目录被测试劫持，卸载也不关程序这一版是 1.6.6 的前半段：先把「数据到底放在哪」这条路走通，再决定收进安装目录。 ### ① 更新目录为什么自己变程序把设置存在「数据目录」里，目录位置靠一个指针文件记着，顺序是 `%DROIDEXTEND_HOME%` → `%LOCALAPPDATA%\DroidExtend\data_dir.txt` → 程序目录。出事的那台机器上，这个指针被写成了 `C:\Users\15530\AppData\Local\Temp\de_bom_target_c9uhsnz0` —— 一个**测试残留的沙箱**。投毒的人是我：`settings_bom_test.py` 为了验证「带 BOM 的设置文件不会丢设置」，调了 `paths.set_data_dir()`，而它写的是**真实的**指针。于是装好的程序有整整一天是从 `%TEMP%` 里读设置。后果是延迟发作的：只要 Windows 清了 TEMP（或者那个目录被删掉），程序就退回程序目录， **所有设置一起回落到默认值**——你看到的就是「更新目录又变了」。现场还留着 22 个 `de_bom_target_*` 目录，每跑一次全量回归就留下一个。 **修法**：`data_dir()` 现在会**忽略落在 `%TEMP%` 下的记忆目录**；指针本身也写进 `%DROIDEXTEND_HOME%`（测试全都设这个变量，所以再也不可能碰到真实指针）。你原来那份设置已经从沙箱里捞出来放到 `D:\DroidExtend\settings.json`（里面的 `update_dir` 是 `D:\Download`），坏指针已删除，21 个残留沙箱也清掉了。 ### ② 就算设置没丢，更新目录也只生效一半下载下来的安装包放在你选的目录，但 `run_installer()` 调 `update_dir()` 时**没传参数**，所以 `apply_update.ps1` 和 `apply_update.log` 永远落在 `%TEMP%\droidextend_update`。 **修法**：`run_installer(..., work_dir="")`，`host/app.py` 把设置里的 `update_dir` 传进去。现在安装包、脚本、日志三样都在你选的那个目录里。 ### ③ 卸载为什么关不掉程序 `DroidExtend.iss` 里写着 `CloseApplications=no`，整个文件也没有 `[Code]`、没有 `AppMutex`、没有 `[UninstallRun]`。所以托盘常驻时卸载：程序还在跑，文件删不掉，卸载「成功」了但目录里还留着东西。现场证据很直接：卸载之后 `D:\DroidExtend` 只剩一个 `tools\` 目录（`adb.exe`、两个 DLL、一个 `adb.log`）——正好是运行中的程序握着的那几个文件。 `CloseApplications=yes` 也救不了：它发 WM_CLOSE，而「关闭窗口」在这个程序里是**缩到托盘**，等于什么都没发生。 **修法**：`.iss` 新增 `[Code]` 段，`PrepareToInstall` 和 `CurUninstallStepChanged(usUninstall)` 都先跑 `taskkill /F /IM DroidExtend.exe /T`，最多重试 8 次；退出码 128（表示没在跑）算成功。 ### ④ 顺手修的一个误报日志里有一句 `没能彻底关掉（设备已禁用，但虚拟屏还在（20 秒内没消失））`。设备节点其实已经禁用了，只是适配器那一行还在枚举——下次开机它不会起来，所以这本来就算成功。现在 `set_enabled(False)` 在「等不到适配器消失、但设备确实已禁用」时返回成功，并说明「这块屏要等系统松手（或下次开机）才从列表里消失」。 --- ## 七、1.6.6 —— 一切数据收进安装目录，只留一个实例 ### ① 数据不再东放西放数了一遍，除了安装目录里的 `DroidExtend.exe` 和 `_internal\`，程序原来还会往外写七处：数据目录指针（`%LOCALAPPDATA%\DroidExtend\data_dir.txt`）、设置、日志、更新脚本与更新日志（`%TEMP%\droidextend_update\`）、两个提权用的临时 PowerShell（`%TEMP%\`）、驱动安装与切换的结果日志。现在**全部落在安装目录里**： ``` <安装目录>\ DroidExtend.exe _internal\ settings.json 设置的唯一位置 DroidExtend.log 日志 vdd_install.log 驱动安装结果 vdd_off.log 虚拟屏开关结果 updates\ 下载的安装包 + apply_update.ps1 + apply_update.log tmp\ 提权用的临时 PowerShell ``` 配套的三个动作： * **指针机制整个删掉。** 数据目录不再「可以搬来搬去」，就是安装目录本身。「文件 → 更改数据目录…」菜单项也删了——它是数据散开的入口。 * **旧数据自动搬回来。** 启动时读旧指针，把别处的 `settings.json` 和日志拷回来（已存在不覆盖），再删掉指针；顺手清掉 `%TEMP%` 里的更新脚本和提权脚本残骸。 * **卸载点名删。** `[UninstallDelete]` 逐条列出这些文件和目录——Inno 只删「自己装的文件」，不点名就会留着。 ### ② 卸载真的干净了上次卸载之后还剩 `tools\platform-tools\` 里三个文件加一个 `adb.log`。不是 Inno 删不掉，而是 **它们归 adb 的守护进程所有**：程序起过 adb 之后，`adb.exe` 会派生一个不随窗口退出的 server 进程，一直占着那几个文件。改成三处一起：安装前和卸载前都跑 `KillAppAdb()`（只杀**安装目录下**的 adb，不动 Android Studio 装的），程序退出时自己调 `adb.kill_server()`，`[UninstallDelete]` 覆盖整个 `{app}\tools`。 ### ③ 卸载最后的报错框消掉了那个框里写的是： ``` Runtime error (at 7:852): 内部错误: Unknown constant "userprofile"。 ``` 卸载其实**已经做完了**，崩在最后一句：清扫脚本里用了 `ExpandConstant('{userprofile}\…')`，而 Inno Setup 根本没有 `{userprofile}` 这个常量，`ExpandConstant` 遇到不认识的常量直接抛异常。改成 `GetEnv('USERPROFILE')`，并把 `.iss` 里所有常量逐个核对过（只剩 `{app}` / `{autodesktop}` / `{group}` / `{localappdata}` / `{sys}` / `{uninstallexe}`）。清扫脚本还改成**先等 `unins000` 进程消失**再动手（最多 30 秒），不再和 Inno 抢文件，也就不会再报「部分元素无法删除」。`<安装目录>-backup` 这种兄弟目录**故意不删**——那很可能是你自己的备份。 ### ④ 只允许一个实例再双击一次 exe 会多一个进程、多一个托盘图标，两个实例还可能抢同一块虚拟屏。现在用命名互斥量 `Local\DroidExtend.single` 卡住：抢不到就**直接退出**（不会闪一下窗口），并尽量把已经在运行的那个窗口叫到前面；它正缩在托盘里时，提示「程序已经在运行了，双击托盘图标」。 --- ## 升级建议 * **已经中招过的机器**（虚拟屏开机自己回来）：升级后进工具菜单点一次「清理残留的虚拟屏」。 * **虚拟屏默认是「彻底关闭」**：第一次停止投屏会弹一次授权框，它要禁用驱动的那块设备节点。不想每次授权就把设置里的「不用时」改成「只移出桌面」。 * **数据位置固定了**：1.6.6 起设置、日志、下载的更新包、更新脚本都在安装目录里，别处的旧设置会在启动时自动搬回来。卸载就是把整个目录删掉。 * **「文件 → 更改数据目录…」没有了**：那个按钮本来就是数据散开的入口。 * **装在旧目录上的**：安装程序会沿用原来的目录；卸载完那个目录会整个消失。 * **只会启动一个实例**：再双击 exe 不会多出进程和托盘图标，而是把已经在运行的那个叫到前面。 ## 验证 `tools/tmp/` 下 **38 个回归脚本**，其中与这几版直接相关的： ``` encoder_matrix.py 7 个可用编码器全部 PASS（真跑一帧再拆包验证） touch_test.py 25/25 坐标四角映射、自动解卡、release 语义 touch_batch_test.py 23/23 位置合并只留最新、事件一个不丢、跨接收边界重组 double_click_test.py 27/27 缝合规则与「不许乱缝」的每一条 retarget_test.py 32/32 运行中改分辨率、幂等、重试到第 4 次 install_dir_test.py 25/25 安装程序复用旧目录、/DIR= 与 PowerShell 顺序 privacy_layout_test.py 23/23 真 Tk 窗口，按钮在正文里且压到 300 px 仍滚得到 settings_bom_test.py 24/24 带 BOM 不再丢设置；旧指针被忽略 notice_test.py 37/37 含「旧协议下 dy 恒为 0」的证明 db_roundtrip_test.py 4/4 挂屏 → 摘屏往返后 Recent 回到干净值 log_toc_test.py 19/19 两份日志的目录锚点、表格、代码块 mode_menu_test.py 76/76 两个菜单真的按驱动表 / 真探测结果生成 mode_live_test.py 19/19 真挂虚拟屏，走真的 ChangeDisplaySettingsEx vdd_off_test.py 63/63 两档选择 / 设备开关六条分支 update_test.py 更新脚本的每一项：等 PID、有上限、装完重启、删包、自删 datadir_guard_test.py 45/45 单一目录 / 没有指针 / 旧数据迁移 / 更新目录落点 single_instance_test.py 14/14 同进程两次、跨进程、释放后重取、唤起窗口 uninstall_sweep_test.py 11/11 还原卸载用的 PowerShell 真跑一遍删目录 + 常量守卫 frozen_check_test.py 解开内嵌 PYZ，查新代码真的被打进 exe 了 ``` **程序内更新是端到端跑过的**，不是只跑了单元测试：造一个假进程冒充正在运行的程序，杀掉它，然后看安装是否真的发生——`started; waiting for the running app to exit` → `app is gone; running the installer` → `installer exit code 0` → `done`，装出来的 exe 和刚构建的那份哈希一致。 **真机验证**（小米 24091RPADC，Android 16，2136×3200）：点击 `['DOWN','UP']`、长按 `['DOWN','UP','RCLICK']`（503 ms 触发）、拖动 `['DOWN']+27 个 MOVE+['UP']`、抖动点击一个 MOVE 都没有、连点两下两次按下相隔 125.6 ms 且抬起落在按下点。 **这台机器上有个环境问题**：任何版本的 Inno 安装器都会在 0.1 秒内 exit 1（「无法创建目录 `%TEMP%\is-XXXX.tmp`。错误 5: 拒绝访问」），同一个账户用 PowerShell `mkdir` 同一个目录却成功 ——所以「装一次再卸载」的端到端验证改由脚本级测试加用户真机反馈完成。 ## 校验 | 文件 | 大小 | SHA256 | |---|---|---| | `DroidExtend-Setup-1.6.6.exe` | 36585166 bytes | `B7667DA4F9E304647DCED50E513E14465D7382323DFE316C8F3925906541CF52` | | `DroidExtend.apk` | 210774 bytes | `235B499BC4A2002067E5822FAD259A75F82411DC340DB426AC6A7301A3604EAC` | 下载的每一步都要过五道检查（官方域名、官方校验和、字节数、SHA256、文件头是 `MZ`）， **任何一条不过就不装**，并当场告诉你哪一条没过。 **这个项目没有代码签名证书**，安装包始终是「未签名」。程序不会假装它是签过名的：确认框里直接写明完整性靠校验和保证、不靠签名。 ## 已知限制 * **没有声音**，只投画面。 * 只在 **Windows 11 + NVIDIA（NVENC）** 上实测过。代码里有 `h264_amf` / `libx264` 兜底，编码器检测也是真跑一帧，但**没在 AMD / Intel 机器上验证过**。 * 必须装**内核级虚拟显示驱动**（会弹一次 UAC）—— 这是"真扩展屏"绕不开的前提。 * APK 用自动生成的**调试密钥**签名，不适合上架应用商店。 --- 完整过程（每个坑的根因、实测数据、以及写错的每一次）记在仓库里： * [开发日志.md 第 20 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.0：十四条需求与八个真 bug * [开发日志.md 第 21 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.1：触控，先把数字量出来 * [开发日志.md 第 22 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.2：双击打不开文件，坑在 Windows 里 * [开发日志.md 第 23 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.3：两个菜单都问错了问题 * [开发日志.md 第 24 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.4：让虚拟屏真的消失 * [开发日志.md 第 25 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.4 之二：程序内更新从来没能装上去 * [开发日志.md 第 26 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.5：更新目录会自己变，卸载也不关程序 * [开发日志.md 第 27 节](https://github.com/Blank2007/DroidExtend/blob/main/%E5%BC%80%E5%8F%91%E6%97%A5%E5%BF%97.md) —— 1.6.6：一切数据收进安装目录，只留一个实例 * [CHANGELOG.en.md](https://github.com/Blank2007/DroidExtend/blob/main/CHANGELOG.en.md) —— 同一份日志的英文版 **这个项目的全部代码、文档和提交信息，都是 AI 编码代理（DeepSeek Harness / deepseek-flash）写的。** 人类负责提需求、插上真机、在需要管理员权限时点「是」，以及验收。

Sunbelt Computer Software

PL/B Language Development and Support