① 设备上显示什么
cart 页走的是你网站上那份现成的 xiancc.online/cart.html（源文件 xcc\public\cart.html）。它整页是给手机/电脑浏览的，推到 480×320 上只会显示其中一块，中间的切窗位置由「触摸坐标」决定。要换地址就改本页脚本顶部的 CART_URL。
② 扫描到的 plaiker 设备 -
扫描是 PC 主动广播（UDP 48899）找设备。旧固件不会应答，需要重烧带扫描功能的固件才会出现在这里；扫不到也不影响正常拉帧。
③ 会话与鉴权 key
plaiker.ino 里 RENDER_KEY 与这里必须相同，否则设备会被 403 拒绝。页面同源访问 plaiker.js（端口 8777）；若你是从主站 443 打开的，请改开 https://xiancc.online:8777/plaiker.html。
④ 云手机 / 网址
云手机默认走自建浏览器源：PC 上开一个无头 Chrome 打开红手指网页版（h5app.gc.com.cn 的 player-window），截它的图缩放到 plaiker 屏幕下发 —— 不需要 ADB。红手指第一次要手机号 + 短信验证码，登录态留在 browser-profile\<user>\ 里，登一次以后就不用再登。ADB 地址只在你有开放 ADB 的真机/实例时才填，填了才走 adb 抓屏。
⑤ plaiker 屏幕实时画面 -
画面即 plaiker.ino 正在显示的帧。点画面 = 相当于 plaiker 设备按了一下 SW 点击该坐标。
⑥ 会话状态 -
⑦ 编码器：画面怎么编出来 -
读取中…
实测（本机 UHD 620，1368×912 源 → 480×320，单帧）：纯 JS 约 130ms ·
ffmpeg 常驻约 10ms · QSV 约 47ms。
注意抓帧那一步常常比编码还贵（电脑桌面源用 PowerShell 抓屏，单帧要 1 秒多），
换编码器不一定能让帧率涨多少 —— 以这里显示的「抓帧 / 编码」两项实测为准。
QSV 在这类核显上反而更慢：源数据在内存里，要上传显存再把 480×320 读回来，这点搬运开销远超它省下的编码时间。
「自动」= 找到 ffmpeg 就用 ffmpeg，找不到退回纯 JS。任何模式失败都会自动降级，不会把画面卡死。
⑧ 原始像素直发（服务端直产 RGB565，设备不解 JPEG） 关
未启用：画面走 JPEG 通路。
关着的时候：plaiker.js 把画面压成 JPEG，设备自己解 JPEG（原来的通路）。
打开后：plaiker.js 在抓帧时多产一份 480×320 RGB565（每像素 2 字节、低字节在前）， 设备带 fmt=raw 拉帧时直接取走并推屏，设备端不再跑 JPEG 解码； 同时只要没人在看控制台，服务端连 JPEG 都不编了（省掉一帧约 190ms 的纯 JS 编码）。
代价：每帧 307200 字节（JPEG 约 16KB），局域网传输更重，WiFi 信号差可能卡顿。 关掉后 3 秒内自动退回 JPEG，不会把设备晾着。
为什么转换不放浏览器：源画面本来就产在 plaiker.js 这台机器上，浏览器只能先拉一张源 PNG 再传回来， 实测白多约 200ms 的搬运，而这一步纯 JS 只要约 20ms。
注意：屏上那 4 根 SPI 线的电平始终由 ESP32 产生，app 隔着 WiFi 只能把"数据"送过去。
打开后：plaiker.js 在抓帧时多产一份 480×320 RGB565（每像素 2 字节、低字节在前）， 设备带 fmt=raw 拉帧时直接取走并推屏，设备端不再跑 JPEG 解码； 同时只要没人在看控制台，服务端连 JPEG 都不编了（省掉一帧约 190ms 的纯 JS 编码）。
代价：每帧 307200 字节（JPEG 约 16KB），局域网传输更重，WiFi 信号差可能卡顿。 关掉后 3 秒内自动退回 JPEG，不会把设备晾着。
为什么转换不放浏览器：源画面本来就产在 plaiker.js 这台机器上，浏览器只能先拉一张源 PNG 再传回来， 实测白多约 200ms 的搬运，而这一步纯 JS 只要约 20ms。
注意：屏上那 4 根 SPI 线的电平始终由 ESP32 产生，app 隔着 WiFi 只能把"数据"送过去。