-
zijunchiang released this
2026-09-18 02:34:59 +08:00 | 1 commits to main since this releaseOpenDance Studio -- Android 辅助 App v0.2.2
修复一处真实缺陷：契约允许「合规但不回
pong」的接收端，而客户端却会把这类
接收端每 15 秒误判为链路已死并强制重连 —— 正是"频繁重连"的症状。
另新增可注入计时，使契约 §7.1 的退避封顶序列能在 JVM 里端到端验证。契约快照不变：
rest-api 0.5.0/websocket-keypoints 0.2.0/data-models 0.7.0/
skeleton-topology 0.2.0/model-formats 0.5.0/database 0.4.0
（与 opendance-web / opendance-windows 逐字节一致）。一、修复的缺陷（⑦ 连接与重连）
契约 §3.6 明确：
接收端收到任何一帧（二进制或文本）都算活动，
ping无需额外应答即可保活；
pong只用于诊断。即"合规但不回
pong"的接收端是合法的。但PoseWebSocketClient.onOpen里写的是
lastPongAtMs = System.currentTimeMillis()，于是心跳循环的守卫
if (lastPongAtMs > 0 && silentFor > limit)恒为真：
对任何接收端都会「判定链路已死 → 主动断链 → 重连」，默认参数
（heartbeatIntervalMs = 5000）下即每 15 秒断一次。为什么以前没暴露：我们自己的接收端（Windows 客户端）会回
pong
（T-WIN-020 实测 9 次 ping 全部收到 pong），所以这条路径在自家联调里永远走不到 ——
只有契约允许的另一种实现才会踩。修复：
onOpen复位lastPongAtMs = 0L（0 = 本连接还没收到过 pong），
只有「曾经回过pong、之后又不回了」才判定链路已死 —— 这正是该诊断本来的意图。二、新增：可注入计时，退避封顶可端到端验证
契约 §7.1 的退避序列
0.5s → 1 → 2 → 4 → 8 → 15s 封顶若要端到端验证，
真实等待约 30 秒；「连续 3 个心跳周期没收到 pong」也要等几十秒。
现在把「现在几点」与「等多久」抽成可注入的Timing：- 生产默认
SystemTiming= 真实时钟 + 真实delay()，行为与抽取前完全一致； - 测试注入「可控时钟 + 立即返回的等待」，毫秒级跑完整条序列。
三、新增 4 项 JVM 用例（无需设备）
用例 断言 退避封顶且不无限增长 第 1..8 次等待分别落在 500/1000/2000/4000/8000/15000/15000/15000的 ±20% 区间内；真实耗时 < 5 秒等待走注入实现 前三次重连真实耗时 < 1.5 秒（真实退避需 3.5 秒） 合规但从不回 pong 不被误判 走过 6 个心跳周期仍为 streaming、无「判定链路已死」日志（修复前此用例失败）回过 pong 后停止回复仍能正确诊断 出现「连续 3 个心跳周期未收到 pong」并进入重连 $ ./gradlew :app:testDebugUnitTest 测试类 7 个，用例 68 项，失败 0 # 原 64 项build/verify.sh全绿：签名、APK 版本元数据0.2.2/202、native 库体检
（ELF 类型 /DT_NEEDED闭包 / 16 KB 页对齐）、ABI 恰为两个真机 ABI、
R8 保留 MediaPipe 20169 条、dex 含PoseLandmarker。四、安装
资产 说明 opendance-android-v0.2.2.zipAPK + README.txt+THIRD_PARTY.md+contracts/快照SHA256SUMS裸文件名， sha256sum -c SHA256SUMS直接校验sha256sum -c SHA256SUMS && unzip opendance-android-v0.2.2.zip adb install -r opendance-android-v0.2.2/app-release.apk # Android 10+（minSdk 29）五、未在本环境验证（诚实声明）
- 真机 30 分钟连续推流、Wi-Fi 抖动 / 切网 / 进程被杀 / Doze 省电仍需设备实测；
Timing覆盖「时钟与等待」；OkHttp 自身的连接/写超时仍走真实时间。
Downloads
- 生产默认