Seetong · Report

🎯 Seetong 问题雷达 09:00 第255期

时间窗口：2026-10-25 17:00:41～2026-10-26 09:00:31（Asia/Shanghai）

📌TL;DR 核心要点

  • 🟠 iOS 8.4.1.6 的 KMP 回放页出现“进入后点不动或卡死”复发。本窗口新增两名独立用户；反馈 259584 的 Logan 能确认报警推送成功进入 PlayBackPage，首轮云回放也能在约 1 秒内完成解析、解码和首帧渲染，但随后 59 秒内页面被连续创建 3 次，并出现一次 2304×1296 与 3840×2160 参数不一致的解码错误。现有代码仍允许解析后 1.2 秒无首帧时直接回报成功，并把播放错误与正常结束混为同一结束事件，严重度 70 / 100，根因置信度 中。
  • 反馈 259584：2026-10-25 21:33:46，iOS 8.4.1.6，iPhone 系统 27.0.1，河南濮阳，原文为“一打开录像回放或者报警回放软件直接卡死”，并提供了 Logan 和附件。
  • 反馈 259586：2026-10-25 21:45:42，iOS 8.4.1.6，iPhone 系统 17.6.1，山东聊城，原文为“点进去基本失灵，点都点不动卡死了”，未提供 Logan。

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-26）。

#问题（严重度降序）严重度平台版本负责人问题原因
1HarmonyOS `1.1.2.3` 多用户离线与核心视频链路失效
21 期 · 175 条反馈
100Android · HarmonyOS1.1.1.11 / 8.4.1.6 / 1.1.2.3唐胜、陈宝旺、冉博麟、谭伟HarmonyOS 客户端把 P2P 瞬时离线写成本地持久状态，并在后续在线判断中优先使用这个旧值，可能导致设备已恢复在线却仍显示离线；回放离线态和播放错误透传不足则放大了用户的“看不到画面”体验。
2Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6唐胜、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
3HarmonyOS 画中画状态导致切换设备后仍显示前一路画面
1 期 · 3 条反馈
90HarmonyOS1.1.1.11 / 1.1.2.3张跃译多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。
4升级后回放体验整体退化
5 期 · 20 条反馈
85Android · HarmonyOS · iOS8.4.1.6 / 1.1.2.3 / 8.3.14.2唐胜、许源、欧阳荣、谭伟8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
5KMP 回放页未申请屏幕常亮，回放中手机自动息屏
12 期 · 31 条反馈
84Android · HarmonyOS8.4.1.6 / 8.4.1 / 8.4.2唐胜、陈宝旺、许源、欧阳荣KMP 回放页的屏幕常亮能力已在代码中完整实现（KMP 公共层 → 桥接层 → Android 宿主层齐备），但承载该实现的提交只落在 feature_v8.4.2 一条分支上，feature_v8.4.4、master、hotfix_v1.1.1 全部不含，因此所有已发布版本（Android 8.4.1.6 / HarmonyOS 1.1.1.11）在运行时都走不到 FLAG_KEEP_SCREEN_ON，回放过程中发生系统级息屏。
6Android 实时预览无首帧却被标记为“视频播放中”，并无限重试
6 期 · 14 条反馈
80Android · iOS8.4.1.6 / 8.4.1.4唐胜、欧阳荣、谭伟、张威预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；add_watch_result=-1 后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。
7SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断
3 期 · 9 条反馈
80Android · HarmonyOS · iOS8.4.1.6 / 1.1.1.11唐胜、张威、陈宝旺设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。
8iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算
2 期 · 8 条反馈
80Android · iOS8.4.1.6 / 8.3.11.3 / 8.4.106陈宝旺、欧阳荣、谭伟iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。
9iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
10Android `8.4.1.6` 在线状态不一致导致卡录像无法打开
1 期 · 1 条反馈
80Android8.4.1.6张威客户端继续使用一份已陈旧约 8 小时的在线缓存，同时又允许单次 P2P 离线事件直接覆盖设备状态；状态模型没有区分云端心跳、P2P 连通和播放出帧，导致用户看到“在线但录像打不开”，且回放页缺少可恢复路径。

问题 1：iOS 8.4.1.6 KMP 回放页卡死复发 ｜ 负责人：欧阳荣、谭伟、陈宝旺、位冬

现象与覆盖范围

  • 反馈 259584：2026-10-25 21:33:46，iOS 8.4.1.6，iPhone 系统 27.0.1，河南濮阳，原文为“一打开录像回放或者报警回放软件直接卡死”，并提供了 Logan 和附件。
  • 反馈 259586：2026-10-25 21:45:42，iOS 8.4.1.6，iPhone 系统 17.6.1，山东聊城，原文为“点进去基本失灵，点都点不动卡死了”，未提供 Logan。
  • 两条反馈相隔 12 分钟，来自不同系统版本、地区和账号。症状都指向“进入回放后页面失去响应”，不是单纯无录像、设备离线或明确网络报错。
  • 同期 2026-10-19 已有 4 条、3 名独立用户报告 iOS 8.4.1.6 云回放卡顿或无法观看，跨 iPhone 系统 16.x／17.x／18.x。本次属于同一问题族的再次出现，不重复计算旧样本为新增反馈量。
  • 严重度评分：70 / 100。反馈量 10（本窗口 2 名独立用户）、共性广度 30（iOS、8.4.1.6、两个 iOS 系统版本、两个省级地区）、业务关键度 30（录像与报警回放主链路）。
  • 去重判定：超过 24 小时的详细分析可重新进雷达；沿用既有 P1 任务 T-20261020-090554-09c5，不新建重复任务。HarmonyOS 离线或回放异常、Android 回放息屏仍在 24 小时重复窗口内，本期只保留为延续线索。

神策证据

  • iOS 8.4.1.6 在 2026-10-25 的 DeviceVideoPlayback 为 2,602,692 PV，带明确业务错误码 71,619 PV，占 2.752%；2026-10-26 截至查询时为 496,566 PV / 18,013 PV，占 3.628%。
  • 同版本 CloudPlayback 在 2026-10-25 为 52,594 PV，非 200 业务码 25,000 PV，占 47.534%；2026-10-26 截至查询时为 10,123 PV / 5,059 PV，占 49.975%。
  • 10 月 25 日卡回放错误码前三为 SA106006 23,556 PV / 11,595 UV、SA106001 23,033 PV / 18,459 UV、SA106007 7,356 PV / 4,933 UV；云回放前三为 30600201 18,008 PV / 10,748 UV、SA106004 6,562 PV / 4,954 UV、SA106001 277 PV / 257 UV。
  • 上述业务码总量未出现断崖，且 SA106006／SA106001／SA106007 分别偏向时间轴、录像获取或设备离线，不能直接解释“页面点不动”。神策现有事件也没有主线程耗时、页面交互响应时间或 KMP 渲染队列字段，因此只能证明回放业务规模与错误背景，不能替代 Logan 对卡死现场的判断。
  • 按 iOS 8.4.1.6、2026-10-19 至 2026-10-26 观察，卡回放明确业务错误占比在 2.75%～3.63%，云回放非 200 业务码占比在 45.71%～49.98%。该比例在本次反馈窗口前后基本连续，不支持“服务端回放在同一时刻整体中断”，也不排除特定设备、片段或客户端状态机触发。

Logan 关键日志

  • 反馈 259584 的 Logan 共 140,809 行 / 762,137 字节，覆盖 2026-10-25 00:40 至 21:33；同条反馈附件 Log0.txt／Log1.txt 共 102,136 行。
  • 21:12:25 点击 人形侦测 - 大门外面 离线报警推送后，KMPRouter.m 记录 openPlaybackPage devId=45441989 fromOfflinePush=1 fromAlarmReplay=1 并创建 KMP PlayBackPage，内存约 85.955 MB；并非通知入口完全失效。
  • 21:12:28～29 依次出现 prepareVideo、playVideo、FFP_MSG_PREPARED、FFP_MSG_VIDEO_DECODED_START 和 FFP_MSG_VIDEO_RENDERING_START，画面尺寸 1920×1080，证明这一次云回放已实际出帧，不能把问题写成“所有回放均黑屏”。
  • 21:31:14、21:31:43、21:32:13 又分别创建 KMP PlayBackPage，内存依次约 268.815 MB、220.252 MB、206.049 MB。21:31:46 出现 decode error, width=2304, height=1296, param width=3840, param height=2160，说明至少一次会话发生视频参数与解码参数不一致。
  • 21:32:30 页面记录 stop for page disappear，21:32:31 完成 releasePlay、unbindView 和 onDestroy；21:33:02 旧进程 [29733] 进入后台，约 0.2 秒后新进程 [29740] 启动。日志没有 watchdog、未捕获异常或崩溃栈，因此当前不能区分用户主动重启与系统终止，只能确认现场发生了进程切换。
  • 反馈 259586 未提供 Logan，无法确认它是否经过同一条 KMP 路由、是否出现解码参数不一致或主线程阻塞。两名用户描述一致，但现有直接技术证据主要来自 259584。

代码定位

  • 涉及模块：Seetong5.0_ios/Seetong_tps/KMP/Router/KMPRouter.m、KMP/View/KMPCloudPlaybackVideoView.m、KMP/View/KMPPlayBackVideoView.m、Classes/TPS/View/IjkPlayerVideoView/IjkPlayerVideoView.m。
  • KMPRouter.m:299-317：PlayBackPage 每次都新建 STKuiklyRenderViewController 并直接入栈，入口没有按 devId + alarmTime + 当前页面 做单飞或重复点击门禁。短时间重复打开时会叠加 KMP 页面、IJK 状态机和视频资源。
  • KMPCloudPlaybackVideoView.m:544-578：playVideo 每轮都会重建播放器并登记请求序号，但页面本身的推栈尚未建立幂等保护；页面多发并不意味着播放器状态能安全并发收敛。
  • KMPCloudPlaybackVideoView.m:57、:490-505：解析完成后固定等待 1.2 秒，即使首帧仍未到达也调用 kmp_resolvePendingPlayCallback:YES。这会让业务层误以为播放已成功，页面可能仍卡在不可交互或无画面的状态。
  • IjkPlayerVideoView.m:722-749：IJKMPMovieFinishReasonPlaybackError 与 IJKMPMovieFinishReasonPlaybackEnded 进入同一结束回调；上层 KMPCloudPlaybackVideoView.m:862-896 随后使用同一完成事件，业务层无法区分正常结束、解码失败和播放错误。
  • KMPCloudPlaybackVideoView.m:684-722：releasePlay 与 unbindView 在主线程同步执行停止、清理过渡帧、取消回调和停止 IJK。正常路径可以完成，但缺少各阶段耗时与超时观测，无法判断哪一段在“点不动”时占用主线程。
  • 当前 feature_v8.4.2_lan 分支 HEAD 44ef9c45e 仍保留 1.2 秒成功兜底及错误／正常结束合流；近期提交没有针对本次“页面交互卡死”完成修复。主要代码责任人可定位到欧阳荣与谭伟。

根因结论

  • 置信度：🟡 中。两名用户的现象独立重复，代码存在明确的状态机缺口，但目前只有一条反馈有可读现场，且日志未捕获主线程阻塞或崩溃栈。
  • 一句话根因：iOS KMP 回放链路没有把“页面入口幂等、首帧确认、错误终态、资源释放”统一成唯一状态机；解析后无首帧仍可被标记成功、错误可被当成正常结束，重复进入还会叠加页面与播放器实例，最终表现为 loading 结束但页面仍不可操作或卡死。
  • 关键证据链：两名不同系统版本和地区的 iOS 8.4.1.6 用户均描述回放页点不动 → 259584 日志证明 KMP 页面可进入且曾成功出帧，但短时间连续创建 3 次并出现解码参数不一致 → 源码直证 1.2 秒无首帧可回报成功、错误与结束共用事件、路由无重复打开保护 → 友盟未记录同版本卡顿或崩溃尖峰，进一步说明需要客户端内部可观测性而不是只看 APM。
  • 明确不下的结论：不能据此认定所有 iOS 回放都会卡死，不能把 47% 的云回放非 200 业务码直接当作真实失败率，也不能把 259584 的进程切换认定为系统崩溃或用户主动重启。

建议下一步

  • 分配给：欧阳荣负责 iOS KMP 回放状态机与路由门禁，谭伟复核 IJK 错误透传和资源释放；沿用任务 T-20261020-090554-09c5，状态保持 P1 / captured。
  • 优先修复：PlayBackPage 以 devId + alarmTime + playbackMode 做入口单飞，页面存在或正在创建时复用现有实例；loading 只能在首帧、明确失败或最终超时三者之一结束时关闭，禁止 prepared_fallback 返回成功。
  • 错误分层：把 IJK 的 PlaybackError、正常结束、页面离场和用户停止拆成互斥事件，并透传 devId、请求序号、片段 URL、解码宽高、已播放时长、错误码和重试次数。
  • 响应性观测：记录 openPlaybackPage 推栈耗时、prepareVideo、playVideo、首帧、解绑、停止和页面离场耗时；主线程连续阻塞超过 500 ms 时上报专用 watchdog 事件，避免下一次仍只能依赖用户文字反馈。
  • 回归矩阵：iOS 8.4.1.6 真机覆盖 iPhone 系统 17.x／27.x、云回放与卡回放、报警推送冷启动、正常首帧、解析成功但无首帧、快速双击入口、连续进入退出 20 次、解码参数异常、前后台切换和弱网恢复；验收要求页面可交互、每个请求只有一个终态、退出后无残留播放器。
  • 回访：优先联系 259584／259586，补采第二次卡死发生时刻、是否点击返回无响应、是否强制结束 App，以及对应设备和回放时间点。

本期扫描全量

分类与处置反馈数反馈 ID
🟠 iOS KMP 回放卡死，进入问题 12259584、259586
🔁 24 小时内已分析问题族15Android 回放息屏 1：259619；HarmonyOS 离线、无画面或回放异常 14：259527、259557、259559、259570、259573、259585、259592、259603、259604、259608、259609、259618、259639、259640
🟡 单点功能、离线、录像或固件异常15259523、259530、259536、259540、259542、259593、259597、259611、259617、259626、259629、259633、259637、259638、259643
🟤 咨询、建议或无效文本4259549、259558、259565、259615
已折叠 1 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
反馈接口返回 total=126 / fetched=126 / complete=true / pages=3。上表按主问题唯一归类，合计 126 条；259521 是窗口内首条，259646 是末条。259603／259604 与 259639／259640 分别为同一用户短时重复提交，仍按记录数保留在全量表中。

心愿单亮点

心愿单 ID平台与版本诉求价值判断
5517Android / 8.4.1.6同一录像机切换不同通道时，保留刚浏览的回放时间，而不是回到约一小时前⭐⭐⭐ 直接影响多通道回看效率，可与本期回放状态持久化一并评估
5519HarmonyOS / 1.1.2.3设备断电时主动通知，便于野外汇看场景及时发现异常⭐⭐⭐ 与低功耗设备、报警和通知可靠性直接相关
5514Android / 8.4.1.6支持手机远程配置国标参数，减少必须到局域网电脑操作的成本⭐⭐⭐ 工程安装与运维效率诉求明确
5511Android / 8.4.1.6增加分享人员访问日志，包含查询时间和次数⭐⭐ 有利于设备共享后的安全审计，但需确认服务端权限模型
心愿单接口返回 total=16 / fetched=16 / complete=true / pages=1；其余为低信息量、重复或无明确产品化价值的建议。

数据源状态与待补证

  • 反馈平台：✅ 正常。完整拉取 126/126 条，并断点后的时间窗口内记录全部纳入分类。
  • 心愿单：✅ 正常。完整拉取 16/16 条。
  • 神策：⚠️ 部分可用。DeviceVideoPlayback／CloudPlayback 业务量和错误码查询成功；现有事件没有主线程阻塞、页面点击响应、KMP 状态机终态或卡死标记，不能直接量化本问题发生率。
  • 友盟：⚠️ 未形成有效旁证。iOS 8.4.1.6 的今日与近 7 天卡顿类型、崩溃类型均为 0；这只能说明 APM 未捕获相应异常，不能排除页面无响应。
  • Logan：⚠️ 部分可用。259584 的 Logan 与附件可读，确认 KMP 路由、播放器创建、解码错误和进程切换；259586 未提供 Logan，不能把两人的现场强行归为同一代码分支。
  • 代码仓：✅ 已只读核对 Seetong-App-iOS 当前 feature_v8.4.2_lan 分支，工作区无未提交改动；在线包与当前分支的逐文件二进制对应关系仍需发布侧确认。
  • TAPD：⏭️ 未调用。当前为功能性回放问题，先用客户端日志、神策和代码链路定界，不以历史 Bug 搜索替代直接证据。
  • 待补证：259586 的现场日志；259584 卡死瞬间是否出现主线程 watchdog；两次反馈对应设备、片段和网络类型；prepared_fallback 是否曾在真实用户上先于首帧完成；当前线上包是否包含 KMPRouter 入口单飞修复。

下一期 = 第256期 = 2026-10-26-H17.md（今天下午 17:00；窗口 2026-10-26 09:00:31～17:00）

🗂️历史期次

查看全部历史期次（近 90 天）→

由 OpenClaw 统一报告渲染器生成 · 最新更新时间：2026-10-26 09:13 · 数据以同名 Markdown 原始报告为准