zijunchiang/opendance-android
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity
35 Commits 2 Branches 4 Tags
main
Commit Graph
12 Commits
Author SHA1 Message Date
zijunchiang c0d0937023 fix(reconnect): 合规接收端被周期性误判「链路已死」（v0.2.2）+ 可注入计时覆盖退避封顶 
一、测试抓到的真实缺陷（T-AND-017）
契约 §3.6 明确：「接收端收到任何一帧都算活动，ping **无需额外应答**即可保活，
pong 只用于诊断」—— 即"合规但不回 pong"的接收端是**合法**的。
但 PoseWebSocketClient.onOpen 里写的是 lastPongAtMs = timing.nowMs()，
于是心跳循环的守卫 if (lastPongAtMs > 0 && silentFor > limit) **恒为真**：
对任何接收端都会「判定链路已死 → 主动断链 → 重连」，默认参数
（heartbeatIntervalMs=5000）下即**每 15 秒断一次**，正是用户抱怨的「频繁重连」。

为什么以前没暴露：我们自己的接收端（Windows PoseServer）**会**回 pong
（T-WIN-020 实测 9 次 ping 全部收到 pong），这条路径在自家联调里永远走不到。

修复：onOpen 复位 lastPongAtMs = 0L（0 = 本连接还没收到过 pong），
只有「曾经回过 pong、之后又不回了」才判定链路已死 —— 这正是该诊断本来的意图。

二、可注入计时 Timing（时钟 + 等待）
契约 §7.1 的退避序列 0.5s→1→2→4→8→15s 封顶若要端到端验证，真实等待约 30 秒；
「连续 3 个心跳周期没收到 pong」也要等几十秒。抽成接口后：
  * 生产默认 SystemTiming = 真实时钟 + 真实 delay，行为与抽取前完全一致
    （10 处 System.currentTimeMillis() 与 2 处 delay() 改走 timing）；
  * 测试注入「可控时钟 + 立即返回的等待」，毫秒级跑完整条序列。

三、新增 4 项 JVM 用例（PoseWebSocketBackoffTest，无需设备）
  * 退避序列在 15 秒封顶且不无限增长：连续失败下断言第 1..8 次等待分别落在
    500/1000/2000/4000/8000/15000/15000/15000 的 ±20% 区间内，且真实耗时 < 5 秒；
  * 等待走注入实现：前三次重连真实耗时 < 1.5 秒（真实退避需 3.5 秒）；
  * **合规但从不回 pong 的接收端不会被判定链路已死**（修复前此处失败）：
    走过 6 个心跳周期仍为 streaming、无「判定链路已死」日志；
  * 曾经回过 pong 之后停止回复时判定链路已死并重连：诊断仍然有效。

实测：./gradlew :app:testDebugUnitTest → 7 个测试类 / 68 项用例 / 0 失败（原 64）。
build/verify.sh 全绿（签名、APK 元数据 0.2.2/202、native 体检、ABI、R8、dex）。
版本号 0.2.1/201 → 0.2.2/202。

写测试踩的两个坑（已写入任务文档）：
  1. 不要在瞬时重连下读 stats.nextRetryMs（等待立即返回后已被清零，与重连循环竞争），
     等待时长应取注入实现记录的事实；
  2. 虚拟时钟需要一个真实让出点（FakeTiming.await 里 2ms 真实 delay），
     否则心跳循环会在网络回调落地前把时钟推过阈值。
 2026-09-18 02:34:54 +08:00
zijunchiang 6dfd90f7ca fix(reconnect): 上一次会话的关闭码污染下一次会话（v0.2.1）+ 重连链路的真实 WebSocket 集成测试 
ReconnectPolicyTest（11 项）验的是**纯函数**「给定关闭码应该怎么退避」，而 ⑦
「连接频繁重连」的缺陷往往出在**调用点**。新增 PoseWebSocketReconnectTest（8 项）：
用 MockWebServer.withWebSocketUpgrade 在 JVM 上起**真实** WebSocket 服务端
（能按 §3.2 回 welcome、按 §3.6 回 pong、按指定关闭码关连接），无需设备即可覆盖
「该重连的」与「不该重连的」两条分支。Robolectric 只用来提供 android.os.Build 桩。

它抓到的真实缺陷（本版修复）：
  上一次会话的关闭码会污染下一次会话，导致重新开始推流后失去自动重连能力。
  复现：第一次连接被对端以 1001 关闭（按 §7 不重连，正确）→ 用户再点「开始推流」
  → 这一次是网络层失败（服务端还没起来），按 §7 **应当**重连 → 但 connect() 只重置了
  reconnectCounter 与 lastPongAtMs，**没有清 lastCloseCode** → scheduleReconnect()
  仍按 1001 判定 → 直接 stopped，**再也不会自动重连**。
  测试失败信息（修复前）：
    ✗ 上一次 1001 关闭后重新连接，遇到网络失败仍应按策略重连
      AssertionError: 当前 state=STOPPED，lastCloseCode=1001，attempts=0

修复（PoseWebSocketClient.kt）：
  * connect()：清掉会话级关闭状态（lastCloseCode=0、lastCloseReason=""）；
  * onFailure()：记录 recordClose(0, …)（契约 §7 中 0=未收到关闭帧 → 应重连），
    顺带让界面「最近一次断开原因」显示本次失败而不是旧值。

用例清单：握手→streaming 与 welcome 保活参数解析、按协商间隔发 ping 收 pong、
1011 按退避重连且等待落在策略 ±20% 区间、成功后计数清零、1001/1002 不重连、
主动断开不重连、上一次 1001 后再连遇网络失败仍应重连（本次回归锁）、
服务端未启动时 1.5s 内 ≤3 次尝试（退避生效）。

实测：./gradlew :app:testDebugUnitTest → 6 个测试类 / 64 项用例 / 0 失败
（原 56 项）；build/verify.sh 全绿（签名、APK 版本元数据 0.2.1/201、native 库体检、
ABI、R8、dex）。版本号 0.2.0/200 → 0.2.1/201。

踩坑：第一版 MockWebServer 夹具的 101 响应没有回显 Sec-WebSocket-Protocol
（RFC 6455 要求），客户端记录的 negotiatedProtocol 为空导致断言失败 —— 那是
**夹具**不合规而非客户端问题，已在夹具里补上。写「真实对端」夹具时要按 RFC/契约
把服务端做对，否则会把夹具缺陷误判成产品缺陷。
 2026-09-17 05:44:03 +08:00
zijunchiang 7ebbaef631 feat(net,pose): 连接状态机与保活对齐 + MediaPipe 崩溃修复（T-AND-010/011/012） 
契约 websocket-keypoints 0.1.0 -> 0.2.0（向后兼容，子协议名与帧 version 不变；
先在 opendance-web 修改并提升版本，再同步三端快照）。

T-AND-011：连接状态异常、频繁重连（查实 3 个根因）
1. 保活用错了层：Windows 端有 5s 静默超时（只看应用层收到的帧），而本端只有
   OkHttp 的协议层 ping —— 它由底层库自动应答、**不暴露给应用层**，根本不能续命。
   画面里没人时 5s 必被踢、再重连，循环往复。
   - 契约新增 §1.1（welcome/config 声明 silentTimeoutMs 与 heartbeatIntervalMs，
     且心跳必须 < 静默超时的一半）与 §3.6（应用层 ping/pong）；
   - Windows 端超时 5s -> 15s、期望心跳 5s，并在 welcome/config 中下发；
   - 本端按声明发 ping，连续 3 个周期无 pong 才判定链路已死并主动重连。
2. 不该重连时也重连：契约新增 §7 关闭码策略，1000/1001/1002 与主动停止一律不重连。
3. frame_id 恒为 0：PoseDetector.detect() 算了 safeTimestamp 却忘了写回
   lastTimestampMs，接收端的丢包检测因此完全失效。已修。

其他对齐：
- 契约新增 §8 连接状态机 idle -> resolving -> connecting -> handshaking ->
  streaming -> degraded -> reconnecting -> stopped，两端同名便于对照日志；
  resolving 只对主机名生效，局域网直连 IP 直接进 connecting；
- 退避与抖动按 §7.1 冻结：0.5s -> 1 -> 2 -> 4 -> 8 -> 15s 封顶 + ±20% 抖动；
- 契约新增 §5 设备去重：hello 携带稳定 deviceId（ANDROID_ID 的 SHA-256 前 16 位，
  不含硬件序列号），Windows 端据此去重、旧连接以 1000 关闭；
- 新增 util/ConnectionLog（环形缓冲，最近 500 条：状态迁移 / close code /
  子协议协商 / 首帧时间 / 保活参数），运行页可一键导出（FileProvider）。

T-AND-012：MediaPipe 初始化崩溃（ExceptionInInitializerError: null）
- 诊断：新增 pose/PoseDiagnostics 展开 cause 链取真因（通常 UnsatisfiedLinkError）、
  区分 native 加载失败、比对设备 ABI 与 APK 内 ABI 并给出可执行结论；
- native 解压：packaging { jniLibs { useLegacyPackaging = true } }（AGP 8 release
  默认 extractNativeLibs=false，MediaPipe JNI 对它不兼容）；
- R8：补 -keepclasseswithmembernames 的 native 方法保留规则，并 -printseeds 输出
  seeds 供发布前核对（实测保留 20169 条 MediaPipe 条目）；
- 构建期新增 verifyReleaseAbi：release ABI 必须恰为 arm64-v8a/armeabi-v7a、
  每个 ABI 下必须有 MediaPipe native 库、模型资源必须存在；
- 未换库：诊断指向集成配置而非 MediaPipe 本身，保留 33 点契约零成本。

T-AND-010：版本号展示与单一来源
- 版本唯一来源 versionName（= project.yaml 的 version）；versionCode 按
  10000*主+100*次+修订 递增（0.2.0 -> 200）；
- 契约版本改为构建期解析 contracts/VERSION 后注入 BuildConfig（六项各自独立
  递增，原先的单个 CONTRACT_VERSION 常量已失真）；界面不再手写任何版本号；
- 新增 checkReleaseConsistency 并挂到 preBuild，三者不一致直接 BUILD FAILED。

README/DSH/THIRD_PARTY/tasks 同步更新（含「导出连接日志」「保活参数」
「最近断开原因」等新增可观察项与排查表）。

测试：56 项全部通过（新增 ReconnectPolicyTest 11 项、PoseDiagnosticsTest 12 项）；
build/verify.sh 全通过（单元测试 -> 构建 -> 签名/ABI/native/seeds/dex 校验）
 2026-09-17 01:10:06 +08:00
zijunchiang 264786134c docs: 新增「初次部署（从零跑起来）」；去混淆字符与真实内网信息 
- README.md / README.txt 新增初次部署章节：前置条件（JDK 17 / SDK 34 / Gradle 8.9）、
  获取代码与本地配置（local.properties 不入仓）、Debug/Release 构建、装到手机与相机权限、
  连接配置（只连 Windows 客户端，默认 8765 / /pose）、第一次跑通、自检清单、常见问题
- 单测数量按实际（30 项）修正
- 三库同源契约：':=' 写法修回、去掉真实 MariaDB 版本串
- 全文去除易被 Gitea 判为「模棱两可 Unicode」的字符
- 本机 JDK 路径与内网示例地址改占位符 / RFC 5737 文档网段
 2026-09-15 21:33:27 +08:00
zijunchiang e9ea1b5811 fix(android): 修复进入推流页立即闪退（未捕获 Error） 
用户反馈：扫描到客户端后点击「开始推流」立刻闪退。

根因：PoseDetector.initialize() 只 catch (Exception)，而 MediaPipe 初始化
失败会抛 UnsatisfiedLinkError / NoClassDefFoundError / ExceptionInInitializerError
—— 这些都是 Error，不是 Exception，会直接冒泡成进程崩溃。

证据（对照实验）：新增 Robolectric 组合测试后
  改回 catch (Exception)：5 项测试 2 项失败
    - java.lang.UnsatisfiedLinkError: no mediapipe_tasks_jni in java.library.path
    - java.lang.NoClassDefFoundError: Could not initialize class ...PoseLandmarker
  改为 catch (Throwable)：5 项全部通过

修复与加固：
- PoseDetector / CameraController 全部改为捕获 Throwable，失败只提示不崩溃
- 移除 accompanist-permissions 0.34.0（2024-02 发布，会传递引入
  compose animation-core 1.6.0，与 Compose BOM 存在版本偏斜风险），
  改用平台 Activity Result API
- MediaPipe 回调在相机线程：所有 Compose 状态写入统一 post 回主线程
- WebSocket 连接、相机启动、单帧分析全部包上失败保护
- 新增 CrashLogger：未捕获异常落盘到 filesDir/crashes/，
  并在连接页直接展示堆栈（免去连 adb 抓 logcat）
- 新增 ScreenCompositionTest（Robolectric）：真实组合三个页面，
  覆盖「进入页面即崩溃」这一类缺陷，共 30 项单元测试
 2026-09-14 22:43:03 +08:00
zijunchiang 8f0eeb7697 feat(android): T-AND-007/008 连接页/运行页/关于页 + 骨架叠加 2026-09-14 20:40:16 +08:00
zijunchiang 5737a66afd feat(android): 设置持久化（推流参数与连接信息） 2026-09-14 20:40:16 +08:00
zijunchiang d27845ef43 feat(android): T-AND-005/006 WebSocket 推流 + 主机发现 2026-09-14 20:40:16 +08:00
zijunchiang 30c316a1cc feat(android): T-AND-003 MediaPipe Pose 端侧推理 2026-09-14 20:40:16 +08:00
zijunchiang 7a8dcfba25 feat(android): T-AND-002 CameraX 采集（KEEP_ONLY_LATEST） 2026-09-14 20:40:16 +08:00
zijunchiang 94ec0a68d9 feat(android): T-AND-004 239 字节帧编解码 + 跨端金标准向量测试 2026-09-14 20:40:16 +08:00
zijunchiang 2f6212d5bf feat(android): T-AND-001 工程骨架（AGP 8.7.3 + Gradle 8.9 + Compose） 2026-09-14 20:40:16 +08:00