Seetong · Report
🎯 Seetong 问题雷达 17:00 第246期
时间窗口：2026-10-21 09:00:26～2026-10-21 17:00:32（Asia/Shanghai）
TL;DR 核心要点
- 🔴 Android 8.4.1.6 实时预览在设备在线、add_watch_result=-1 且持续无首帧时，界面仍显示“视频播放中”，并以 10 秒间隔无限重试。反馈 258728 的 Logan 中，首次请求到设备返回成功耗时约 208.8 秒，期间两次失败埋点分别持续 99.302 秒、80.234 秒，和用户“三分钟以上”的描述吻合。严重度 80 / 100，现象置信度强，根因置信度强，继续任务 T-20260923-170444-60dc。
- 🟠 HarmonyOS 1.1.2.3 的 KMP 报警桥接没有向页面提供视频地址或可回放能力，云端状态被固定为 false，只能稳定传递缩略图。两名独立用户共提交 3 次“报警没有视频”或“报警视频打不开”，覆盖 2 个机型、2 个省级地区。严重度 80 / 100，现象置信度强，根因置信度中，累计任务 T-20261021-170533-1339。
- 258728：Android 8.4.1.6、vivo V2436A、广东东莞，反馈“打开 APP 观看实时监控的时候，反应太慢需要三分钟以上”。
最近一个月 Top 问题
按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-21）。
| # | 问题（严重度降序） | 严重度 | 平台 | 版本 | 负责人 | 问题原因 |
|---|---|---|---|---|---|---|
| 1 | Android 8.4.1.6 及 HarmonyOS 1.1.1.11 单设备随机离线、P2P 恢复失败 19 期 · 160 条反馈 | 100 | Android · HarmonyOS | 1.1.1.11 / 8.4.1.6 / 1.1.2.3 | 陈宝旺、唐胜、冉博麟、谭伟 | 257582、257639 已确认是服务端心跳长期停更并伴随 P2P 离线，App 只是按离线状态展示；问题更可能在设备端、设备网关／P2P 服务或固件恢复机制，而不是 Android 播放器单点故障。 |
| 2 | Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达 1 期 · 3 条反馈 | 90 | Android · iOS | 8.4.1.6 | 唐胜、许源 | 现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。 |
| 3 | HarmonyOS 画中画状态导致切换设备后仍显示前一路画面 1 期 · 3 条反馈 | 90 | HarmonyOS | 1.1.1.11 / 1.1.2.3 | 张跃译 | 多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。 |
| 4 | 升级后回放体验整体退化 4 期 · 18 条反馈 | 85 | Android · iOS | 8.4.1.6 / 8.3.14.2 | 唐胜、许源、欧阳荣、谭伟 | 8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。 |
| 5 | KMP 回放页未申请屏幕常亮，回放中手机自动息屏 11 期 · 29 条反馈 | 84 | Android · HarmonyOS | 8.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，回放过程中发生系统级息屏。 |
| 6 | Android 实时预览无首帧却被标记为“视频播放中”，并无限重试 5 期 · 12 条反馈 | 80 | Android · iOS | 8.4.1.6 / 8.4.1.4 | 唐胜、张威、谭伟、欧阳荣 | 预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；add_watch_result=-1 后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。 |
| 7 | SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断 3 期 · 9 条反馈 | 80 | Android · HarmonyOS · iOS | 8.4.1.6 / 1.1.1.11 | 唐胜、张威、陈宝旺 | 设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。 |
| 8 | iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算 2 期 · 8 条反馈 | 80 | Android · iOS | 8.4.1.6 / 8.3.11.3 / 8.4.106 | 陈宝旺、欧阳荣、谭伟 | iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。 |
| 9 | iOS 8.1.2.4 微信登录授权码重复提交触发 30100225 1 期 · 3 条反馈 | 80 | iOS | 8.1.2.4 / 8.1.204 / 8.4.106 | 待定 | 微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。 |
| 10 | iOS 老版本微信登录空授权码触发 30100222 1 期 · 1 条反馈 | 80 | iOS | 8.1.3.5 / 8.1.305 / 8.1.503 | 位冬 | 微信授权回跳在当前旧版 iOS 上返回了空 code，客户端没有把它视为失败边界，仍向服务端提交空授权码，最终稳定触发 30100222。 |
🔴 问题 1：Android 实时预览无首帧却被标记为“视频播放中”，并无限重试 ｜ 负责人：唐胜
现象与覆盖范围
- 258728：Android
8.4.1.6、vivoV2436A、广东东莞，反馈“打开 APP 观看实时监控的时候，反应太慢需要三分钟以上”。 - 反馈只有一个独立用户，但同一条 Logan 连续覆盖两个长时间失败会话，且设备在埋点中被判定为在线。它不是瞬时点击慢，而是“请求已失败、画面未出、状态却已宣称播放中”的状态机错误。
- 严重度评分：80 / 100。反馈量 10（1 名用户）、共性广度 30（Android、
8.4.1.6、vivoV2436A、广东地区四个维度）、业务关键度 40（实时监控是核心主链路）。 - 去重判定：账本已有
T-20260923-170444-60dc，原任务针对8.4.1.4的“预览加载反复重试与首帧缺失”。本期在8.4.1.6再次命中同一状态机问题，更新任务证据，不另建重复任务。
神策证据
- 截至 2026-10-21 17:00，Android
8.4.1.6的MonitorFrameResult为 18,367,558 PV / 4,489,337 UV，明确失败 473,528 PV，失败率约 2.578%。 - 近 7 天失败率依次为 2.698%、2.739%、2.771%、2.685%、2.653%、2.628%、2.578%，大盘没有新增尖峰。因此本期不是“平台级整体恶化”，而是稳定存在的长时间无首帧长尾路径。
- 同版本、同机型
V2436A当日有 27,657 PV。由于反馈平台的clientId没有映射到神策distinct_id，无法用用户 ID 做一对一追踪；用户级事实以 Logan 为准，神策只用于大盘与机型背景判断。 MonitorFrameResult的关键成功条件应以首帧为准。当前 Logan 中的两条失败埋点均为isOnline:true、isPreviewSuccess:false，说明“设备在线”和“预览成功”是不同状态，不能用在线状态替代首帧成功。
Logan 关键日志
- 反馈 ID：258728。Logan 共 5,053 行、115,686 字节。
16:03:01.933：LibImpl-addWatch ... add_watch_result=-1, portId=0, playing=false, play=true。16:03:01.935：紧接着出现PreviewPlayerView-setVideoInfo msg: 视频播放中，但此时没有首帧，playing=false也没有被用于状态门禁。16:03:11.956至16:06:05.735：同一设备每 10 秒重新执行一次addWatch，add_watch_result持续为-1，状态文案仍被覆盖为“视频播放中”。16:04:41.230：previewMonitorData screen_model ret:true, isPreviewSuccess:false, isOnline:true getPreviewDuration:99302，明确失败时长 99.302 秒。16:06:05.940：再次记录isPreviewSuccess:false, isOnline:true getPreviewDuration:80234，明确失败时长 80.234 秒。16:06:30.757：设备端onMsgRspAddWatch ... nResult=0返回；相对16:03:01.933的首次请求已过去约 208.8 秒，与用户描述的“三分钟以上”对应。日志窗口内没有出现MSG_RECEIVER_MEDIA_FIRST_FRAME，不能把该响应当作已经出图。
代码定位
- 模块：Android 设备列表与预览，
Seetong5.0ForSeetong/Seetong5.0/device_list/src/main/java/com/seetong/devicelist/view/VideoPlayerView.kt。 VideoPlayerView.kt:632-638：只有MSG_RECEIVER_MEDIA_FIRST_FRAME才进入真正的首帧处理。VideoPlayerView.kt:411-434：onRecvFirstFrame才切换PlayState.PLAYING、隐藏等待层并显示渲染窗口，说明首帧是唯一可靠的业务成功信号。VideoPlayerView.kt:729-751：设备状态消息无论首帧是否已到，都会直接调用setVideoInfo；因此失败提示可被后续状态文本覆盖为“视频播放中”。VideoPlayerView.kt:761-770：onAddWatchResp在add_watch_result != 0时虽然写入错误提示，但没有持久状态或首帧门禁，后续重试和状态消息能够再次覆盖它。VideoPlayerView.kt:807-876：startAutoResumePlay每 10 秒调用doRenderTimeout，条件满足后直接停止并重开取流；没有次数上限、退避或“连续无首帧后明确失败”的终止分支。VideoPlayerView.kt:338-340：清空信息时直接设置video_play_tip，进一步放大了“请求尚未成功但页面先显示播放提示”的错位。
根因结论
- 置信度：🟢 强。
- 一句话根因：预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；
add_watch_result=-1后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。 - 关键证据链：Logan 的
add_watch_result=-1、isPreviewSuccess:false、无首帧消息与代码中的首个首帧分支、状态消息覆盖、无上限重试完全互相印证。
修复建议与验证
- 将
onRecvFirstFrame作为唯一的PLAYING和成功埋点入口；首帧前保持“连接中”或“第 N 次重试”，不得被普通状态消息覆盖。 - 为自动重试增加最大次数和退避，例如 10 秒、20 秒、30 秒，3 次仍无首帧后进入可操作的失败态，保留重试按钮并展示设备 ID 与错误码。
- 将每次预览请求编号，首帧、错误、超时和重试回调都携带
requestId/devId/attempt，拒绝旧请求回调覆盖新会话。 - 回归在线设备进入预览、快速切换通道、4G 弱网、设备刚上线、切前后台各 20 次；3 秒内无首帧必须明确显示进度，10 秒内未恢复必须退出“播放中”状态。
🟠 问题 2：HarmonyOS KMP 报警桥接丢失视频能力，报警项只能呈现图片 ｜ 负责人：谭伟、欧阳荣、唐胜、许源
现象与覆盖范围
- 258735：HarmonyOS
1.1.2.3、HUAWEIMIA-AL00、山东日照，“报警里怎么没有报警视频了”。 - 258738：同一用户两分钟后再提交，“报警信息怎么是图片了，不是视频了”。
- 258684：HarmonyOS
1.1.2.3、HUAWEIHBN-AL00、广东深圳，“报警的视频怎么打不开”。 - 三人次反馈归并为 2 名独立用户，覆盖 2 个机型、2 个省级地区；同一用户短时重复提交不重复放大反馈量。
- 严重度评分：80 / 100。反馈量 20（3 条记录、2 名独立用户）、共性广度 30（HarmonyOS、同一版本、2 个机型、2 个地区）、业务关键度 30（报警取证与历史核查）。
- 去重判定：近 24 小时没有同根因的 Harmony KMP 报警桥接任务。历史报警视频问题主要覆盖 iOS、Android 原生路径或参数透传，不与本期 Harmony 宿主字段缺失重复。新建
T-20261021-170533-1339。
神策证据
- 已核对 2026-10-21 的神策事件清单，不存在
AlarmMessage等可直接量化报警卡片视频能力的业务事件。因此不能把报警视频缺失伪装成已有埋点下降。 MonitorFrameResult只覆盖预览/回放首帧，不代表报警列表是否展示视频入口；SiteMessageClick只覆盖消息点击，不能证明报警卡片媒体类型。- 本期证据边界明确：现象量来自 3 条反馈，根因来自 Harmony 宿主桥接与跨端契约代码，神策只能提供“缺少该业务观测点”的反证。建议后续新增报警卡片能力字段，而不是用无关事件替代。
代码与契约证据
seetong-app-harmony/basic/src/main/ets/model/StModel.ets:844-855的AlarmListBean只有thumbnailAddress等字段，没有videoUrl、videoLink、canPlayback或云录像类型。seetong-app-harmony/settongLibrary/src/main/ets/modules/STAlarmModule.ets:31-51的AlarmMessageQueryItem同样没有视频地址和可播放能力字段。STAlarmModule.ets:530-557的mapAlarmItem只映射缩略图；isCloudReplay使用常量DEFAULT_IS_CLOUD_REPLAY=false，replayTypeText也使用固定默认值。STAlarmModule.ets:136：DEFAULT_IS_CLOUD_REPLAY = false。这意味着 Harmony 宿主不可能根据真实报警记录向 KMP 告知云回放类型。- 跨端对照：iOS
KMPAlarmModule.m:711会依据thumbnailName或videoLink推导isCloudReplay，并在:731导出videoLink；AndroidAlarmBridgeApiImpl.kt:320与:411也保留videoUrl契约键。Harmony 桥接缺失该能力，属于三端字段契约不对称。
根因结论
- 置信度：🟡 中。
- 一句话根因：Harmony 将首页报警页切换为 KMP
AlarmMessagePage后，宿主STAlarmModule仍只映射旧的原生缩略图字段，没有把视频地址、云录像状态和可播放能力传给 KMP；页面因此无法可靠展示报警视频入口。 - 关键证据链：两名独立用户出现相同版本、相同“只有图片/视频打不开”症状；Harmony 模型和 bridge 源码同时缺少视频字段，且云状态固定为
false。当前缺少 KMP 页面点击现场日志，因此根因定为中置信度，而不是已闭环缺陷。
修复建议与验证
- 先确认 Harmony 消息服务返回的原始告警协议中可用的视频字段和云录像标识，避免仅凭页面层猜测字段名。
- 扩展
AlarmListBean与AlarmMessageQueryItem，补齐videoUrl、videoLink、isCloudReplay、canPlayback、replayTypeText；所有默认值必须来自真实记录，禁止把云端状态固定为false。 - 若后端列表不下发视频 URL，应至少向 KMP 传递
devId + alarmTime + alarmType + requestId，由 KMP 发起明确的按时间回放，并为卡片提供可点击播放图标和可区分的失败态。 - 回归云端报警、卡报警、纯图片报警、无录像权限、录像过期五类数据；每类都要验证“图片存在”“视频入口存在或明确不适用”“点击后 3 秒内进入播放或给出具体原因”三个断言。
- 回访反馈 15006911728、13699867147，并补采覆盖报警列表点击与回放启动时段的 Harmony 日志。
本期扫描明细
| 分类与处置 | 反馈数 | 反馈 ID 或说明 |
|---|---|---|
🟣 普遍网络提示 -102 | 52 | 以“请检查手机网络，重启 App”模板为主，按规则排除，HTML 自动折叠 |
| 🔴 Android 预览无首帧 | 1 | 258728，进入问题 1 |
| 🟠 Harmony 报警视频缺失或打不开 | 3 | 258735、258738、258684，进入问题 2 |
| 🟡 回放、卡顿、熄屏等既有问题 | 6 | 258667、258668、258704、258705、258717、258719；均为单点或已有任务跟踪 |
| 🟡 离线、设备状态异常 | 4 | 258680、258687、258692、258697；258692 与 258697 为同一用户重复提交 |
| 🟡 升级、存储、全屏入口 | 4 | 258669、258730、258731、258732；本期只有单点，未达到 60 分 |
| 🟡 报警列表加载失败或商业化争议 | 2 | 258713 为 iOS 单点加载失败；258664 为报警预览图收费诉求 |
| 🟡 登录、设备咨询、无效文本及其他 | 7 | 258665、258700、258709、258733；另有 3 条低信息短文本或纯咨询，不进入雷达 |
| 🟤 心愿单或低信息建议 | 3 | 心愿单接口另见下表；不计入缺陷雷达 |
| 🟢 用户操作或非产品问题 | 2 | 删除设备、联系维修等已交由用户操作或客服路径 |
心愿单亮点
| 心愿单 ID | 平台与版本 | 诉求 | 价值判断 |
|---|---|---|---|
| 5426 | Android / 8.4.1.6 | 希望增加红色投影灯 | ⭐ 设备能力诉求，需先确认硬件支持 |
| 5422 | Android / 8.4.1.6 | 增加商城并统一展示可购买设备 | ⭐⭐ 可减少跨 App 购买与兼容咨询 |
| 5425 | Android / 8.4.1.6 | 希望找到摄像头维修官方入口 | ⭐⭐ 售后入口可降低错误反馈量 |
数据源状态与待补证
- 反馈平台：✅ 正常。窗口内
total=84 / fetched=84 / complete=true，以上按主问题唯一归类。 - 心愿单：✅ 正常。
total=5 / fetched=5 / complete=true，其中 3 条具有产品价值，2 条为重复或无效文本。 - 神策：✅ 主查询成功，得到
MonitorFrameResult当日大盘、近 7 天趋势与失败分布；三项补充 SQL 查询发生超时，未用超时结果生成结论，也没有把缺失值填成 0。 - Logan：✅ 258728 日志完整下载并定位关键时间线；报警视频两条 Harmony 用户反馈没有提供 Logan，因此问题 2 根因只能定为中置信度。
- 代码仓：✅ Android、iOS、HarmonyOS 标准路径均存在；报警字段缺失和三端契约差异已直接定位。
- 友盟与 TAPD：⏭️ 未调用。本期核心问题不是崩溃/ANR，且已有用户级 Logan、神策或代码锚点，先由任务账本推进复现。
- 待补证：需要拿到 Harmony 报警列表点击后的 KMP 与宿主日志，确认
AlarmMessagePage消费何种媒体字段；需要回访 258728 记录设备型号、固件、内外网和后续三次重试是否恢复。
下一期 = 第247期 = 2026-10-22-H09.md（明天上午 09:00；窗口 今日 17:00～明日 09:00）