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

🟠 问题 1：HarmonyOS 1.1.1.11 回放／录像链路多点不可用，本窗口跨 6 机型聚集 7 条（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：HarmonyOS 1.1.1.11 用户在观看录像／回放环节集中受挫，措辞分三类：
• 录像类：「无法录像」（同一用户连续 2 条）、「录像播放不顺畅，又堵又卡还经常查不到图像。」
• 回放类：「卡回放老是卡死」、「回看打不开卡的要死」
• 查看类：「手机不能查看了」
• 涉及反馈 7 条独立（跨 6 机型、6 地区、时间跨 17:54 → 09:00）：

• 设备跨度：6 机型（HBP-AL00 / LMR-AL00 / BRA-AL00 / TLR-AL00 / PLA-AL10 / SGT-AL50）；6 地区（河北 / 天津 / 河南 / 黑龙江 / 江苏 / 上海）
• 版本跨度：全部 1.1.1.11（本窗口 Harmony 反馈共 27 条，其中回放／查看类 7 条，占比 25.9%）
• Logan 可用性：7 条全部 loganFileDownloadUrl 为空（HarmonyOS 上报链路未附带 Logan），是本问题无法升级为强置信度的直接原因
• 严重度评分：62/100（反馈量 20 / 共性 30 / 业务关键度 30 —— 回放属录像查看核心能力；反馈量未达 >5 阈值故记 20，共性因跨 5 机型 5 地区记满 30）
• 去重判定：与第 211 / 214 / 216 / 218 / 222 期「HarmonyOS 1.1.1.11 回放聚集」同域 → 沿用任务 T-20260926-170258-2226，不重复创单；但本窗口聚集密度（7 条）高于近 5 期单窗口均值（3 条），故仍进雷达

2. 神策证据（核心数据源）

• 大盘量级（跨端对照，2026-10-03 ~ 2026-10-09 DeviceVideoPlayback）：total_count 21,273,554 → 19,851,110（-6.7%），unique_users 5,225,141 → 5,037,535（-3.6%）——主链路量级稳定，无系统性崩塌
• 出图端失败占比（MonitorFrameResult，按 $os 拆分，2026-10-09）：

• HarmonyOS 失败占比 7 天趋势（无恶化信号）：

⇒ 失败占比当日最低（7.13%），7 天区间 7.13%~7.93% 平稳，无线上劣化趋势；说明本问题不是平台级回归，更可能是个别设备 / 个别网络 / 特定机型固件组合的低频聚集

• 失败原因字段不可用：MonitorFrameResult.fail_reason 在 2026-10-09 全端取值仅为 null（Android 6,608,388 / iOS 1,822,747 / HarmonyOS 1,402,280）与空串（Android 15 / HarmonyOS 1），该字段未有效上报，不能用于归因（列为待补证）
• 其他事件量级（2026-10-09，用于排除干扰）：MonitorWatchStep 398,453 / 225,716 人；SiotDevConnectResult 4,567,609 / 1,382,177 人；DeviceConnectResult 21,272,880 / 6,164,806 人 —— 连接类事件量级正常
• 观测盲区说明：NvrMonitorFrameResult（NVR 回放首帧性能事件）当日仅 unique_users=60，样本过小不足以做 HarmonyOS 回放耗时归因；MonitorScreenExit 当日取值为 0，不可用

3. Logan 关键日志（核心数据源）

• 本问题 7 条反馈全部无 Logan，无法执行 Stage 2b 的类名:行号级定位
• 已尝试的替代路径：HarmonyOS 反馈 loganFileDownloadUrl 为空字符串（非下载失败，是未上报）
• 对照样本（非本问题，属排除项）：
• 反馈 256347（vivo V2148A / Android 8.3.14.2）Logan 全量 310,100 行，错误统计 {'-102': 1228, '-101': 1152, 'ssl_connect': 2, 'EXCEPTION': 6117}，EXCEPTION 多为 BlackBox-startPlay 状态打印（ret:-224 / ret:-121 = NVR 通道未添加），与 Harmony 回放问题无关联，不作为本问题证据
• ⇒ 本问题证据等级：仅「反馈原话聚集」单源，置信度上限为「中」（聚集事实确凿，根因未定）

6. 代码定位（详细）

• 涉及平台：HarmonyOS 宿主 ~/seetong-app-harmony/（ArkTS）+ KMP 共享层 ~/seetong-kmp/
• 已定位的 HarmonyOS 常亮相关代码（仅作链路参照，本问题症状非常亮）：
• seetong-app-harmony/feater/playDevice/src/main/ets/view/ViewPage.ets:367 → ViewPageUtil.setKeepScreenOn(true); // 开启屏幕常亮
• seetong-app-harmony/feater/playDevice/src/main/ets/utils/ViewPageUtil.ets:133 → static setKeepScreenOn(value: boolean)
• ⇒ HarmonyOS 侧常亮能力独立实现（不经 KMP 桥接），与 Android 常亮缺陷不是同一条链路
• KMP 共享层回放链路（~/seetong-kmp）：
• modulePlayback/.../card/CardPlayBackPageLogic.kt:3146 → PlayBackPage.sendFastAction(speed: Int)
• 同文件 :2709 → 首帧回调后 if (card.currentSpeed != 0) sendFastAction(card.currentSpeed)
• moduleBase/.../nview/KMPPlayBackVideoView.kt:97 → playVideoAction(pDevId, action, seep, playTime)，仅在 this.devId == pDevId 时转发
• 调用链（回放入口 → 出图）：

PlayBackPage.pageDidAppear() → 准备回放参数 → playBackView.playVideoAction(devId, PLAY/FAST/SEEK, …) → renderView.callMethod("playVideoAction", …) → 原生 KMP 播放器 → 首帧回调 markPlaybackFirstFrame(devId) → showVideoMask=false

• 关键分支（待验证的失败可能路径）：

1. playVideoAction() 的 devId 一致性前置判断——若设备切换/通道换绑后 this.devId 未同步，指令被静默丢弃（无日志、无提示），外部表现即「点了没反应／卡死」
2. 首帧回调 markPlaybackFirstFrame 未触发时，页面停留在 showVideoLoading=true（外部表现「转圈／打不开」）
3. HarmonyOS 侧回放页面与 KMP 共享层的生命周期绑定是否在返回前台后重建（需 ArkTS 侧证据）

• 修复方向锚点：① 在 playVideoAction 的 devId != pDevId 分支补显式日志与失败提示（当前为静默）；② 给首帧回调补超时兜底（超时后退出 loading 并提示）；③ HarmonyOS 回放页补失败态埋点（当前端侧无对应事件）

7. 根因结论

• 置信度：🟡 中（聚集事实确凿，根因未定）
• 一句话根因：HarmonyOS 1.1.1.11 在回放／录像链路上出现跨 6 机型的用户聚集，但神策大盘失败占比 7 天平稳（7.13%~7.93%），无平台级劣化，故更可能是多因素叠加（个别设备联网态 × 特定机型 × 通道配置），而端侧 Logan 全量缺失使得具体断点无法确认
• 关键证据链：

1. 反馈原话 7 条跨 6 机型 6 地区（聚集强度）
2. 神策 MonitorFrameResult HarmonyOS 失败占比 7.13%（当日最低，排除平台回归）
3. 神策 fail_reason 字段未上报（归因能力缺口）
4. 7 条反馈 Logan 全空（证据链缺口）

• 明确不下的结论：不判定为「HarmonyOS 1.1.1.11 回放功能整体失效」——大盘数据不支持

8. 建议下一步

• 分配给：HarmonyOS 客户端负责人 + KMP 回放负责人（沿用 T-20260926-170258-2226 owner）
• 优先处理项：

1. 补齐 HarmonyOS 端 Logan 上报（回放/录像场景强制附带日志），这是根治「Harmony 反馈不可定位」的前置能力问题，优先级高于单次问题修复
2. 在 playVideoAction() 的 devId 不匹配分支补显式日志 + 用户可见失败提示（当前静默丢弃）
3. 给首帧回调补超时兜底（markPlaybackFirstFrame 未达时退出 loading）

• 验证方法：取本窗口 6 条机型的反馈用户，在 1.1.1.11 上复现「录像 → 回放 → 卡死/打不开」链路，抓端侧日志确认断点

🟠 问题 2：Android 云回放小窗口触发 App 冷启动重启（vivo V2148A / 8.3.14.2）（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户在云回放 / 录像场景下「点击查看录像小窗口」后，App 发生冷启动级重启（非闪退弹窗，而是回退到启动流程重新拉起）
• 涉及反馈：
• 256347｜vivo V2148A｜Android 8.3.14.2｜中国广东省深圳市｜2026-10-09 20:01:43｜「云回放，录像，点击查看录像小窗口，APP重启」
• 同用户 15989469220 当夜 3 次提交（256341 / 256342 为 1.1.2.1 的测试数据，256347 为正式反馈），诉求强度高
• 设备／版本跨度：1 机型 / 1 版本（vivo V2148A / 8.3.14.2）——共性广度弱，是本期严重度未进 70 分段的主因
• 严重度评分：58/100（反馈量 10 / 共性 10 / 业务关键度 30 —— 回放属核心能力，App 重启属严重体验中断；但因单机型单版本、无跨用户复制，量级与共性均记低分）
• 去重判定：首次进雷达（历史任务 T-20260922-170415-9496 针对「卡回放拖动卡顿」，症状不同，不沿用）→ 新建任务

2. 神策证据（核心数据源）

• 大盘量级（DeviceVideoPlayback，2026-10-09）：total_count = 19,851,110、unique_users = 5,037,535 —— 云回放主链路量级正常
• 相关操作事件（2026-10-09）：
• UCRemotePlaybackOperation（客户端远程回放操作）：total_count = 60、unique_users = 9 —— 该事件埋点覆盖极低（相对 5,037,535 日活），不具备统计意义，不能用于云回放问题归因
• MonitorScreenExit：total_count = 0 —— 该事件当日无数据，不可用
• 观测盲区（明确记录）：目前神策侧缺少「App 冷启动 / 进程重启」专用事件，无法用埋点量化该问题的发生频次；本期结论仅依赖 Logan + OBS 附件，属单源证据
• 用户侧其他信号：同用户 256341 / 256342（1.1.2.1）提交内容为「test测试数据，👌👌可删除数据」「测试数据」，判定为测试行为，已排除；但该用户在同一夜跨 Harmony 测试线与 Android 正式线均有活动，回访时需注意区分

3. Logan 关键日志（核心数据源，含类名:行号 + PID 证据）

• 反馈 ID：256347｜日志 seetong_293137b2-9cab-42ea-a39e-fc27255b2751_1791475200000_d83dc872-…｜1,931,653 字节 / 310,100 行（信息充分）
• 附件：OBS 压缩包 5cb148ab703e256f2efebc6138a25300.zip（5,383 字节，含 4 段 logcat）

关键发现 1：两次冷启动 PID 切换（重启的硬件级证据）

⇒ 19:53:35 → 19:59:47 的 6 分 12 秒内，进程从 PID 4809 变为 PID 16379，两次均为 LoadedApk: Unable to instantiate appComponentFactory 起始的完整冷启动序列（LoadedApk → SeetongLog: Logan not init → UMCrash 初始化 → Matrix.AnrTracer）

关键发现 2：冷启动序列原文（seetong_logcat_2.log）

[L2] 10-09 19:59:47.888 16379 16379 E LoadedApk: Unable to instantiate appComponentFactory
[L3] 10-09 19:59:47.888 16379 16379 E LoadedApk: java.lang.ClassNotFoundException: Didn't find class
     "androidx.core.app.CoreComponentFactory"
[L38] 10-09 19:59:48.381 16379 16460 E SeetongLog: Logan not init...Please initialize Logan first
[L39] 10-09 19:59:48.395 16379 16459 E UMCrash : ==================可接入免费的网络分析能力!!!===================
[L47] 10-09 19:59:48.407 16379 16379 I         : [App version:]********
[L56] 10-09 19:59:48.418 16379 16469 I Matrix.AnrTracer: anrTrace, final mAnrBeatTime:400, mAnrBeatRate:400

关键发现 3：日志中不存在崩溃栈

• 全 4 段 logcat 无 FATAL EXCEPTION / AndroidRuntime / signal / SIGSEGV 记录
• 同期 Logan 全窗口异常统计：{'-102': 1228, '-101': 1152, 'ssl_connect': 2, 'EXCEPTION': 6117}，其中 EXCEPTION 多为 BlackBox-startPlay 状态打印（如 [L7273] LibImpl-addWatch,devId=…,add_watch_result=-1、[L7275] BlackBox-startPlay end... ret:-224 = NVR 通道未添加）
• 另见 [L7266] PreviewPlayerView-setVideoInfo msg: NVR通道未添加 devid=47935468-CH-6 —— 该用户存在NVR 多通道配置（devChannelCount: 64、devChannelStates 含 02/22 异常位）

⇒ 重启并非由 Java 崩溃栈引起（无 FATAL），符合「系统级进程终止 / 内存压力 / 原生层 fatal signal 未落 logcat」三类成因。必须补 logcat -b crash 与 tombstone 才能定因（列入待补证）。

6. 代码定位（详细）

• 涉及模块：Android 宿主 ~/Seetong-App-Android/（原生 app 模块）+ KMP 共享层 ~/seetong-kmp/
• 关键类（云回放链路）：
• moduleBase/.../nview/KMPCloudPlaybackVideoView.kt:113 → playVideoAction(devId, action, seep, callback)
• modulePlayback/.../cloud/CloudPlayBackToolbar.kt:362 → cloud.playbackViewRef?.view?.playVideoAction(currentDevId, NVR_ACTION_FAST, actionSeep) { … }
• 调用链（用户描述路径）：

云回放页 → 录像列表 → 点击「查看录像小窗口」 → 小窗播放器初始化 → playVideoAction(...) → renderView?.callMethod("playVideoAction", …)

• 关键分支（待验证的失败可能路径）：

1. 小窗模式下的播放器实例生命周期——若小窗创建了第二个 KMPCloudPlaybackVideoView 实例，而未释放原实例的 Surface / 原生解码器，可能触发原生层资源冲突
2. devId 一致性判断（moduleBase/.../KMPPlayBackVideoView.kt:105 if (this.devId == pDevId)）在小窗切换时未同步 this.devId，导致指令错投
3. 宿主侧与小窗相关的 UI 抢焦点 / SurfaceView 重挂载路径（需 Android 宿主 app 模块对应 Activity 证据）

• 修复方向锚点：

① 核对小窗播放器的创建与释放是否成对（当前仅见 releasePlay() 在「页面销毁或切换设备时」调用）；
② 在小窗入口补 devId 绑定同步；
③ 补 logcat -b crash 采集能力，否则此类重启永远只能靠 PID 推断

7. 根因结论

• 置信度：🟡 中（重启事实确凿，触发点未定）
• 一句话根因：用户在执行「云回放 → 录像 → 点开录像小窗口」路径后，App 进程于 19:59:47 完成第二次冷启动（PID 4809 → 16379），但全量日志中不存在 Java 崩溃栈，故排除 Java 层异常，指向系统级进程终止或原生层 fatal；具体触发点需 logcat -b crash + tombstone 补证
• 关键证据链：

1. OBS logcat PID 切换（4809 → 16379，间隔 6 分 12 秒）
2. 两段完整冷启动序列（LoadedApk → UMCrash 初始化）
3. 反馈原话「点击查看录像小窗口，APP重启」与时间窗吻合（反馈提交 20:01:43，重启 19:59:47，间隔 116 秒）
4. fail_reason / MonitorScreenExit / 冷启动埋点三处均无神策数据（反证：不能靠埋点定性）

8. 建议下一步

• 分配给：Android 宿主（云回放小窗）+ KMP 回放负责人
• 优先处理项：

1. 拿 256347 的 OBS 附件与本次分析对照，用 adb logcat -b crash 复跑该路径，判定是否 native crash / 系统 kill
2. 核对小窗播放器实例的创建—释放配对
3. 回访用户 15989469220 确认机型、复现步骤与设备通道配置（该用户设备为 64 通道 NVR，devChannelStates 含异常位）

• 验证方法：vivo V2148A / 8.3.14.2 上按「云回放 → 录像 → 小窗」路径连续复现 ≥10 次，观察是否触发进程重启

本期扫描全量（全部沉淀到知识库）

汇总：扫描 128 条 / 进雷达 2 条 / 排除 126 条（🟢 无效 9 🟡 配置·咨询 6 🟣 网络 77 🟤 建议·商业化 34）

排除项补充说明（登录失败 30100222 / 30100225）：

• 本窗口 2 条反馈：256422（iOS 12.5.7 / 8.1.2.4 / 30100222）、256304（iOS 17.2.1 / 8.1.2.4 / 30100225）
• 神策口径（Login 事件按 error_code 拆分，逐日拉取规避分页截断）：

• ⇒ 两码均属低量常驻（30100225 呈缓降趋势，30100222 个位数），无突发，与两条 iOS 反季节版本（8.1.2.4）用户相符，判定为个别用户第三方授权态失效，不进雷达
• 代码锚点：Seetong-App-iOS/.../NetworkManager/STResponseModel.h:106/109；调用方 STLoginService.m:131 +requestThirdWithParams:OnSuccess:onFailure:

数据源状态汇总

待补证

• 问题 1（HarmonyOS 回放聚集）：
• 7 条反馈均无 Logan，需先解决 HarmonyOS 端回放/录像场景的 Logan 上报缺失（能力缺口，优先级最高）
• 神策 MonitorFrameResult.fail_reason 全端为空，需埋点侧确认字段是否已停用或口径变更
• NvrMonitorFrameResult 当日仅 60 人，样本不足，无法做 HarmonyOS 回放首帧耗时归因
• 需取 256418（BRA-AL00）/ 256406（PLA-AL10）/ 256358（SGT-AL50）三名用户复现，并记录 playVideoAction 的 devId 前置判断是否命中
• 问题 2（云回放小窗重启）：
• 需 adb logcat -b crash + tombstone 复跑，确认是 native crash 还是系统级 kill（当前仅能靠 PID 推断）
• 需核对小窗播放器实例创建—释放配对（KMPCloudPlaybackVideoView）
• 需回访用户 15989469220，其设备为 64 通道 NVR（devChannelStates 含 02/22 异常位），需确认是否与多通道配置相关
• 窗口连续性：本期为 09:00 正期，窗口起点取上一期 H17 报告头部（2026-10-09 09:00:00 ~ 2026-10-09 17:04:00）的结束时刻 17:00:00，两期首尾相接、无重叠、无遗漏；本期 run 实际时刻为 09:00，窗口右端取该实际时刻

下一期 = 第224期 = 2026-10-10-H17（今天下午 17:00；本期为 09:00 正期，窗口 昨日 17:00 ~ 今日 09:00）