xmz7891
|
25e7780272
|
单次请求失败不再立刻判离线,改成连续 3 次
实测单个请求有 2~4% 的偶发失败(4G 丢包打在一条隧道连接上,
或者那条连接正在重连)。原逻辑是一失败就 online = false,
于是界面上会闪一下已断开 —— 用户点按钮时正好撞上那一闪,
看起来就像又连不上了。
而链路其实 1.5~15 秒就自己恢复(客户端本来就有退避重试)。
改成连续失败 3 次才判离线(手表至少 4.5 秒、电脑至少 6 秒):
* 单次抖动完全不影响界面
* 真的断了仍然如实显示
这不是掩盖问题,而是把是否可用的判断从一次采样改成连续采样 ——
单点采样在有丢包的链路上噪声太大。
两边同步改:
android .../RelayTransport.java failStreak + OFFLINE_AFTER
windows/lanremote/relay.py _fail_streak + OFFLINE_AFTER
顺带记录 PC 端基准(真实用户视角,之前都是在设备上量的,
那等于把设备 4G 算了两遍):
公网可用率 98% 耗时 中位 911 P90 1889 P99 23868 ms
长轮询 5/6 耗时 60.8~62.1 秒
对比设备端(中位 1344 / P90 2563)—— 用户实际体验比设备端量出来的好。
|
2026-10-07 16:16:50 +08:00 |
|
xmz7891
|
aea78efe45
|
版本 1.8.1 -> 1.8.2
|
2026-10-07 15:44:49 +08:00 |
|
xmz7891
|
bf15a2ee61
|
静态资源交给 Cloudflare 边缘缓存(下载提速 41 倍)
实测基线:
ykxmz-setup-1.8.1.exe 只下到 237568/15067199 字节就停(17 KB/s)
ykxmz-watch-1.8.1.apk 201523 字节 / 66.8 秒 = 3 KB/s
ykxmz-server-1.8.1.zip 214900 字节 / 3.1 秒 = 67 KB/s
原因:relay 给所有响应都发 Cache-Control: no-store,
Cloudflare 完全不缓存 —— 每次下载/每张图都要穿隧道回 4G 源站。
改动:
/download/* no-store -> public, max-age=604800, immutable
文件名带版本号,同一名字内容永不改变,可以长缓存
/ -> public, max-age=60(挡住刷新重复回源)
/favicon.ico 已是 max-age=86400,保持不变
/shot/* 已是 max-age=86400,保持不变
/v1/* 保持 no-store(接口必须实时)
顺带修两个自己踩的坑:
1. _send() 无条件先发 no-store,再追加 extra 里的 Cache-Control,
结果是**两个 Cache-Control 头**,客户端只认第一个 ——
调用方传的缓存策略被吃掉。改成 extra 里有就不再发默认值。
2. do_HEAD 和 do_GET 的缓存头不一致:HEAD 对非 /shot/ 一律报 no-store。
下载器/代理用 HEAD 探测时会误判文件不可缓存。
现在 _head_info 给每个路由带上和 GET 完全相同的缓存头,
do_HEAD 也不再盲目覆盖。
结果(同一个测试口径):
setup.exe 17 KB/s(截断) -> 695 KB/s 完整 15 MB 41 倍
watch.apk 3 KB/s -> 101 KB/s 33 倍
server.zip 67 KB/s -> 87 KB/s
三个文件全部 cf-cache-status=HIT(不再穿隧道回源)
排查过程记一笔:我一开始用 curl -I 验证,
看到的全是 no-store —— 因为 **-I 发的是 HEAD**,
而 HEAD 走的是另一个分支。查了半天才发现是验证方法错了。
|
2026-10-07 15:44:48 +08:00 |
|
xmz7891
|
b1119d0da6
|
修「局域网连接被中转劫持」+ 长轮询 15s→60s
用户报两个问题:
1. 局域网能搜到电脑,IP/端口/配对码都对,点连接**没有任何反应**
2. 走中转 1426ms 延时,一会儿就 502
========== 一、局域网被劫持(真 bug)==========
MainActivity.connect() 里:
boolean usedLan = !relayUrl().isEmpty() ? false : true;
if (!relay.isEmpty()) {
reply = client.connectViaRelay(...); // 走中转
} else {
reply = client.connect(host, port, ...); // 才走局域网
}
**只看「中转设置里填没填地址」,填了就一律走中转,
完全无视用户填的局域网 IP 和端口。**
而中转单次超时是 40 秒 —— 用户点完就卡在「正在连接…」
四十秒,在他看来就是"没有任何反应"。
影响两条路:
* 「局域网连接」页面填 IP 直连(connectLanTyped)
* 首页「已配对的电脑」点一下重连(quickConnect)
修法:给 connect() 加 preferLan 参数。明确要走局域网时
**先直连(6 秒超时,局域网本该是毫秒级),失败再退回中转**,
保证最终能连上。
顺带两个体验改进:
* 设备列表里,保存的 IP 和手表不同网段时标「⚠ 地址可能已过期」
(用户截图里那个 192.168.2.64 就是过期地址,电脑早换成
192.168.10.103 了)
* quickConnect 判断出地址过期就跳过直连,直接走中转查最新地址 ——
省掉那 6 秒白等
========== 二、长轮询 15 秒 -> 60 秒 ==========
实测隧道每次请求要多花 1~2 秒(CF 边缘路由 + 回源):
本机直连 60 秒的 poll -> 60.0s
走公网同一个 poll -> 61.5~62.0s
这个开销是**按次数**收的:
15 秒一循环 -> 一天 5760 次/端,光路费 2.4~3.2 小时
60 秒一循环 -> 一天 1440 次/端,光费 0.6~0.8 小时
而且请求越频繁,撞上丢包/重连窗口的概率越大。
**不会让命令变慢**:长轮询是"有数据立刻返回"(device.event 唤醒),
拉长只是减少空转重开。实测 60 秒长轮询穿隧道 4/4 通过;
Cloudflare 单请求上限 100 秒,留了 40 秒余量。
三层同步改(客户端超时必须显著大于服务端 hold):
* relay/relay.py RELAY_POLL 默认 25 -> 60
* windows/lanremote/relay.py POLL_TIMEOUT 40 -> 90
* android .../RelayTransport.java POLL_TIMEOUT_MS 40000 -> 90000
========== 三、A/B 实测(还在跑更严谨的一轮)==========
短测发现基线 http2+4 虽然 100% 成功,但 **P90 是 16.8 秒**
(每 10 次有 1 次卡十几秒 —— 正是用户说的"没反应"),
而 quic+6 的 P90 只有 2.8 秒。正在用真实长轮询模式
跑 10 分钟对照确认。
|
2026-10-07 14:11:33 +08:00 |
|
xmz7891
|
49fdec1da8
|
1.8.0:隧道稳定性大修 + 中转管理后台重做
版本号 1.7.1 -> 1.8.0(8 个文件,13 处)。
写了个 bump_180.py 统一处理 —— 版本号散落在
Python / Java manifest / PowerShell / Inno Setup / 测试里,
手动改必漏;而且 .ps1 必须保留 UTF-8 BOM。
==================== 一、隧道稳定性(用户撞上 1033/502/530)====================
1) 4G 链路会**静默断开 TCP 连接**(不发 FIN/RST,双方都以为还活着),
Linux 默认要 2 小时才发现 -> 改成 keepalive 30 秒 + 每 10 秒探测。
实测 60 秒内发现并重连。
2) 隧道连接数 2 -> 4。只剩 1 条连接时跨机房回源会失败
(实测可用率 0/12,提到 4 条后 12/12)。
3) 掉电重启后恢复慢:原来开机 2 分 10 秒公网才可用。
根因是 systemd-networkd-wait-online 等一个不归它管的网络
(wlan0 是 NetworkManager 管的),干等 2 分钟超时失败,
把 network-online.target 一起拖住。
mask 掉它之后:启动 17.3 秒,掉电重启 24 秒公网可用。
4) 看门狗两次翻车都是我造成的,都修了:
a) 我先加了"确认故障立刻重启",但隧道重建 4 条连接要 30~60 秒,
MIN_RESTART_GAP=45 导致**还没建齐就被下一次重启打断**,
死循环,每 50 秒重启一次 -> 加 150 秒宽限期
b) 宽限期又带来"链路持续差时什么都不做"的问题
-> 增加"本次重启后建齐过吗"的判断:
建齐过又垮 = 真故障,立刻重启
从没建齐 = 还在努力,继续等
5) 顺手修:看门狗状态文件里的变量在函数定义前被引用,
set -u 下报 "BUILT: 未绑定的变量"。
==================== 二、中转管理后台重做 ====================
原来的管理页是几百行内联在 relay.py 的 f-string 里,
改一处样式要在一堆转义花括号里翻。拆成独立模块 relay/admin.py。
新设计(对齐官网那套白色简洁):
吸顶顶栏 -> 公网地址(最大权重,这是用户最需要复制的)
-> 四个数字卡 -> 设备表 -> 工具卡(体检 + 下载)
空状态给图标+引导文案;窄屏表格自动变卡片。
relay.py 从 2089 行缩到 1500 行左右。
修了三个我自己引入的 bug:
a) 响应头类型写错,浏览器把整页 HTML 当纯文本显示
(用户看到的是"一屏源码")。教训:200 不等于页面能看,
当时只验了状态码和字节数。
b) 顶栏用了固定 height:62px,装不下"标题+副标题+版本信息"两行,
内容被顶出容器 -> 标题看不见、徽章压在字上。
c) do_HEAD 没处理 /download/ 路径,HEAD 一个 APK 返回
Content-Length: 0 + text/plain,下载器会误判成空文件。
同时发现 _head_info 里对 bytes 调 .encode() —— 加 _as_bytes() 兜住。
==================== 三、其它 ====================
* 设备记录只增不减:实测一天攒 75 条僵尸,/v1/health 从几 KB 涨到 20KB。
加 DEVICE_TTL(6 小时)自动清,占用的配对码一起释放
(管理页曾显示"配对码占用 131"但一台设备都没有)。
* HEAD 请求支持(原来一律 501)。
* 官网新增产品展示:手表界面预览(颜色/布局与真实手表一致)、
电脑端真实截图、两种连接方式对比图。
* 加了一份 docs/免费托管方案.md(含一个纠错:上一版推荐的
ClawCloud Run 已在 2026-05-11 关停)。
==================== 验收 ====================
全量回归 33 个阶段全部通过
安装包完整周期 20/20(静默装入 7 秒、卸载 0.6 秒、无残留)
网页响应头 12/12
公网可用率 26/30 = 86%(底层 4G 丢包 30%,是这个上限)
发布产物 安装包 14.37MB / 服务端 0.20MB / 手表 0.19MB
|
2026-10-07 11:47:12 +08:00 |
|
xmz7891
|
de65654676
|
修 --quiet 卸载日志的两个问题(静态检查抓出来的)
1. run_agent.py 用了 Path 但没导入
静态检查报 "undefined name 'Path'"。它被 try/except 吞了,
所以卸载功能本身没坏,但**日志从来没写成过** ——
属于"看着没事、其实功能是死的",最容易被漏掉的那种。
2. 日志写到刚被删掉的数据目录里
原来是 Path(data_dir())/"uninstall.log",但 do_uninstall()
会把整个数据目录删掉,写完等于白写。
改到 %TEMP%\ykxmz-uninstall.log。
现在日志能正常落盘,内容长这样:
开始卸载 ykxmz
已停止其它 ykxmz.exe 实例(本进程 15572 除外)
没有开机自启项
已删除数据目录 ...
程序目录交给安装包的卸载器删除
卸载完成。
最终全量套件(33 个阶段):
30 PASS + 3 SKIP(锁屏) + 0 FAIL
新增的「安装包完整周期」PASS
|
2026-10-07 03:14:11 +08:00 |
|
xmz7891
|
c7c0484a27
|
修安装包卸载卡死的真凶:attach_console 在无控制台时阻塞
排查过程(一步步排除,记录下来免得以后重踩):
1. 现象:从控制面板卸载,进度条永远走不完。
2. 先怀疑 input():安装器用 runhidden 调 --uninstall,没有 stdin,
input() 会一直等。加了 isatty 保护 —— **没解决**。
3. 再怀疑 Popen 没重定向 stdio:_schedule_self_delete 起的 cmd
继承了父进程句柄,capture_output 会等管道 EOF。加了
DEVNULL 重定向 —— **还是卡**。
4. 又发现 _kill_running 用 taskkill /IM ykxmz.exe 把正在卸载的
自己杀了(--uninstall 就跑在 ykxmz.exe 里),
导致后面的"删自启/删数据"没执行。改成 /FI "PID ne self" ——
自启能删了,**卸载仍然卡**。
5. 最后看进程状态才定位:卡住的 ykxmz.exe 只有 **1 个线程、
0.16 秒 CPU、19MB 内存** —— 明显停在启动早期,根本没干活。
那就是 cli_uninstall 第一行的 attach_console():
它对 --windowed 程序调 AllocConsole(),再 open("CONIN$")。
在没有控制台的隐藏进程里,这一步**永久阻塞**。
修法:加 --quiet。安装包的卸载器用
ykxmz.exe --uninstall --keep-dir --quiet
--quiet 下完全不碰控制台(不 AllocConsole、不 input),
结果写进 uninstall.log 供排查。
实测:不带 --quiet 无限卡住;带了 **0.6 秒返回**。
顺带修的两处(也是实测发现的):
* 安装器关不掉以管理员身份运行的旧实例 -> Inno 弹"无法关闭所有
应用程序",静默下被压成"终止",**整个安装回滚**。
改成 PrepareToInstall 里自己 taskkill /F。
* 测试脚本把注册表路径写成 HKCU\...(少了冒号),
PowerShell 静默返回空,"开机自启"永远误报失败。
最终实测(test_installer_cycle.py,20 项):
静默安装 退出码 0,7.1 秒
配对码 正确写入 C:\ProgramData\ykxmz\data\settings.json
进程/端口 在跑,8765 监听
开机自启 已设置
静默卸载 1.2 秒
卸载清理 安装目录 / 数据目录 / 注册表 / 进程 / 自启 全部干净
20 项全通过
套件新增一个阶段:「安装包完整周期」。
|
2026-10-07 02:21:36 +08:00 |
|
xmz7891
|
df8056dd16
|
修四个安装/卸载卡死的 bug(都实测复现过)
1. 卸载里 input() 在无 stdin 时永久阻塞
从控制面板卸载**永远卡住不结束**。安装包的 [UninstallRun]
用 runhidden 调用,没有 stdin,input() 就一直等。
改成只在 sys.stdin.isatty() 时才等回车。
2. Popen 没重定向子进程 stdio,导致 capture_output 等管道 EOF
_schedule_self_delete 起的 cmd 继承了父进程的 stdout/stderr 句柄,
任何用 capture_output 调 --uninstall 的地方都会一直等,
表现为"程序卡死"(实测 90 秒不返回,改后 0.2 秒)。
Popen 加 stdin/stdout/stderr=DEVNULL。
顺带把延迟从 timeout 换成 ping —— timeout 在 DETACHED_PROCESS
下没有控制台会立刻失败,等于没延迟直接删。
3. _kill_running 用 taskkill /IM ykxmz.exe 把**自己**杀了
--uninstall 本身就跑在 ykxmz.exe 里,这条命令一发,
后面的"删开机自启""删数据目录"全都没执行。
现象:卸载看着完成了,HKCU 的自启注册表项还留着。
改成 /FI "PID ne <self>" 排除自己。
4. 安装器关不掉以管理员身份运行的旧实例 -> 整个安装回滚
Inno 自带机制只会"请求"对方退出,遇上常驻的服务进程关不掉,
弹"无法自动关闭所有应用程序",静默模式下被压成"终止",
安装直接回滚 —— 用户看到的是"装了没反应/还是旧版本"。
改成 PrepareToInstall 里自己 taskkill /F,关掉 Inno 那套。
另外修了两个卸载残留:
* 安装目录留个空壳 -> [UninstallDelete] 加 dirifempty
* ProgramData\ykxmz 没删 -> 加进 [UninstallDelete]
还有一处 Inno 写法陷阱(踩了三次):
注释里写 [区段名] 或 {常量} 会让编译直接失败,
因为 [Code] 解析器连注释内容也处理。
加了 _build/check_iss.py 专门扫这个,并进全量套件。
实测结果:
静默安装 5 秒内退出,退出码 0,配对码正确写入,程序自动跑起来
静默卸载 0.7 秒退出(原来无限卡住)
全量回归 29 项全通过
卸载逻辑 11 项全通过
|
2026-10-07 01:19:11 +08:00 |
|
xmz7891
|
566d9e384f
|
阶段1+2:恢复 HTTP/2 加速 + 重做官网
阶段1 网络加速
- 发现隧道在跑 QUIC(ExecStart 丢了 --protocol http2),
实测 QUIC 可用率 48% vs HTTP/2 80%+,是重大性能回退。
恢复后公网延迟从 4141ms 降到 690ms(快 6 倍),可用率 92%。
- 优选 IP 结论:无效。hosts 覆盖确实生效了(日志里连的就是指定 IP),
但落点仍是 lax —— 运营商把所有 Cloudflare anycast 都路由到美西。
已清掉这段无效配置。
- BBR 不可用:设备是自定义内核 6.4.0-rc4-jsbsbxjxh66,
没编 tcp_bbr 模块也没配置项。改用 cubic + 调优:
TCP 缓冲 4MB、tcp_fastopen=3、tcp_slow_start_after_idle=0
(长轮询场景关键)、tcp_tw_reuse=1。
阶段2 官网重做
- 拆出独立模块 relay/landing.py(relay.py 已两千多行,
再塞 HTML 没法看)
- 信息结构参考成熟产品站:吸顶导航 / Hero / 九宫格功能 /
三步上手 / 下载 / FAQ / 页脚
- 保持白色简洁:底白、浅灰面板、细边框、大量留白
- logo 用内联 SVG(ICO 放 img 里实测是破图)
- 管理入口从官网移除(管理不对外开放)
过程中被自己的测试抓到两个 bug:
- 模块叫 site.py 会和 Python 标准库重名,import site 拿到的是标准库
- _logo() 里把 % 格式化和字符串拼接混用,直接抛 TypeError
|
2026-10-06 23:53:19 +08:00 |
|
xmz7891
|
81e923a0aa
|
1.7.1:修白屏 + 配对 + 官网管理页分家
手表端
- 修「连上后一片白屏」:initTabs() 从来没被调用过,
导致 tabDefs 为 null、selectTab 直接 return,
标签栏里只剩一个孤立的滑动指示器
- 应用名改成 ykxmz
被控端
- 修「设备已关闭新设备配对」:配对码本身就是密钥,
拿着正确的码就该放行。老逻辑"首台配对后自动关窗"会把
手表重装的人永久挡在外面
- 应用名改成 ykxmz
服务器端
- / 改成官网(公开,简洁介绍 + 下载)
- /zhingzhuanzhan 中转站管理(要登录),/admin 自动跳转
- 管理账号 xmz7891,可改
- 官网 / 登录页 / 管理页都加上 favicon
|
2026-10-06 23:08:07 +08:00 |
|
xmz7891
|
ce87ec1650
|
1.7.0:常规发布
- 版本号 1.7.0 -> 1.7.0
- 重建三端并打包
- 关键测试全过
|
2026-10-06 23:08:07 +08:00 |
|
xmz7891
|
4c88ca901f
|
1.6.2:常规发布
- 版本号 1.6.2 -> 1.6.2
- 重建三端并打包
- 关键测试全过
|
2026-10-06 23:08:07 +08:00 |
|
xmz7891
|
65dc2fad65
|
1.6.1:常规发布
- 版本号 1.6.1 -> 1.6.1
- 重建三端并打包
- 关键测试全过
|
2026-10-06 23:08:07 +08:00 |
|
xmz7891
|
07e96a9595
|
1.6.0:重写 README,面向老师 / 电教 / 开发者 / 普通用户
README
- 原来的 README 是开发者视角(在解释我为什么没做某功能),
而且通篇 AI 腔。这次按用户视角重写,讲怎么用。
- 开头就分流:老师 / 电教 / 开发者 / 普通用户,各看各的
- 定位改成教室电脑手表遥控,主场景是老师上课管教室那台电脑
- 加了电教专用一节:机房同传部署、脚本批量推、网络规划、权限收口
- 加了开发者一节:三端怎么编译、怎么跑测试、怎么打包
- 加了通信协议一节
- 常见问题、排错顺序、错误对照表都补全
版本号
- 1.5.0 -> 1.6.0(versionCode 107)
- 顺手写了通用的版本升级脚本 _build/bump_version_generic.py,
以后升版本一条命令就行,不用手改十几个文件
|
2026-10-06 23:08:07 +08:00 |
|
xmz7891
|
edac13dbe2
|
chore: 排除 dist/ 构建产物(改用 release 附件分发)
|
2026-10-06 19:01:39 +08:00 |
|
xmz7891
|
b62ac865ea
|
ykxmz 1.5.0:修复手表端 TLS 证书校验 + MTU 修复网络稳定性
被控端
- 修复 MTU 问题:夹 MSS + 路径 MTU 探测(公网可用率 48% -> 100%)
- 复用 HTTP 连接(免掉每次新建 TLS 的 30% 握手失败)
- 每分钟回头找局域网,自动切回快 400 倍的路径
- 画面心跳帧:静止时省流量,客户端仍知道流是活的
- 锁屏时给出可操作的提示
手表端
- 内置 GTS Root R4 / GlobalSign Root CA,修 SSLHandshakeException
- 连接错误翻译成人话(证书/时间/解析/超时分别提示)
- 经中转连上后用服务器报的地址刷新已配对记录
- 新增局域网连接页面、服务器延迟检测
服务器端
- 支持 chunked 请求体(修每 16 秒一次的连接错乱与大面积 502)
- 网络调优脚本 net-tune.sh(开机自动应用)
- 管理页:批量删除、网络体检、下载区
- 隧道改 HTTP/2 + 双连接
文档
- 许可协议 / 安装前必读 / 安装后须知(作者:小麦子)
|
2026-10-06 19:01:05 +08:00 |
|