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

🔴 问题 1：HarmonyOS 1.1.2.3 多用户离线与核心视频链路失效 ｜ 负责人：李国涛

1. 现象与覆盖范围

• 本窗口共有 10 条独立反馈，用户分别描述“有电显示离线”“总显示离线”“看不到实时画面”“监控看不了”“监控时有时无”“设备启动中但连不上”“高清视频打不开”“插卡摄像头无法查看回放”。
• 涉及反馈：258918、258931、258938、258963、258981、258986、258994、259004、259008、259012。
• 覆盖 HarmonyOS 1.1.2.3、9 个 HUAWEI 机型：ALN-AL80、HBP-AL00、CHZ-AL00、CLS-AL00、VDE-AL10、LMR-AL10、JUY-AL80、ADA-AL00、BRA-AL00；覆盖辽宁、河北、新疆、海南、吉林、河南、山东 7 个省级地区。
• 258994 只写“离线”，单独看信息较弱；258918 明确“有电显示离线”，258986 写明“总显示离线”，259012 明确设备启动后仍无法联网，三者共同构成同一版本上的持续性离线现象。其余反馈补足实时画面与回放链路。
• 严重度评分：100 / 100。反馈量 30（10 条独立反馈）、共性广度 30（平台、版本、9 个机型、7 个地区）、业务关键度 40（设备在线、实时查看和录像取证均为核心能力）。
• 去重判定：与任务 T-20260926-115214-fdf9“核查 HarmonyOS 设备已联网但列表显示离线”同域。本期新增 1.1.2.3 的 10 用户聚集和代码级状态粘滞证据，更新既有任务，不重复创单。

2. Sensors 证据

• DeviceVideoPlayback 是当前版本唯一可稳定查到的核心查看事件：2026-10-22 至 10-23 共 1,086,417 PV / 326,878 UV。
• 2026-10-22 完整日共 907,238 PV，其中成功 884,078、失败 23,160，失败率 2.553%。
• 2026-10-23 截至本次查询共 179,481 PV，其中成功 173,372、失败 6,109，失败率 3.404%，较前一日完整日上升 0.851 个百分点。该日为未完整日，只能作为风险方向，不能直接外推全天。
• 2026-10-23 的失败码主要为 SA106006 3,935 PV、SA106012 573 PV、SA106008 571 PV、SA106010 354 PV、SA106001 334 PV、SA106007 220 PV。
• 1.1.2.3 在上述日期未查询到可用的 SiotDevConnectResult、MonitorFrameResult 或 NvrDeviceVideoPlayback 数据，因此离线发生率和预览首帧失败率无法按事件量化。这是观测缺口，不代表这些链路没有发生问题。
• 反馈平台 clientId 尚未映射到神策 distinct_id，以上为同版本大盘证据，不能逐条归到 10 名反馈用户。

3. Logan 与附件

• 10 条核心反馈均未提供 Logan，无法直接读取 TPS_MSG_P2P_OFFLINE、devIsOnline、p2pLastHeartTime、lastHeartTime 和各播放接口返回值。
• 因此本期只能确认“同一版本、同一核心链路、短窗口多用户聚集”，不能把 10 条反馈强行合并为一个服务端或设备端根因。
• 已保留 258921 之外的核心反馈作为下一轮回访对象；离线类应优先采集设备 SN、固件、网络类型和服务端在线态快照，播放类应采集 ts_AddWatchEx 返回值、首帧耗时与 onError。

4. 代码定位

• 涉及模块：seetong-app-harmony/feater/deviceList、feater/playDevice、basic/src/main/ets/utils。
• DeviceViewModel.ets:1184-1196：doMsgCallBack 收到 TPS_MSG_P2P_OFFLINE 后调用 setDeviceStatus(devId, false)，把 localDevice.isConnect 写成 false。
• DeviceViewModel.ets:1943-1971：setDeviceStatus 在 isConnect != undefined 时只比较本地布尔值；只要本地已经是 false，不会用服务端新的 devIsOnline=1 做二次校正。当前源码中未找到将该字段恢复为 undefined 的统一路径。
• DeviceUtils.ets:175-186：isOnLine 在 isConnect != undefined 时直接返回本地值，优先于 remoteDevice.devIsOnline。这使一次 P2P 离线可能长期覆盖后续服务端在线结果。
• ReplayPage.ets:155 与 :3887：isOffline 被读取用于展示离线态，但注释明确写着“目前未赋值”，回放页没有完整离线状态写入路径。
• AutoPlayDeviceView.ets:21-43：快速预览调用 playDevice 后忽略返回值，只监听首帧事件；首帧不到时缺少超时失败态。
• DeviceServiceImpl.ets:5493-5548：ts_AddWatchEx 的细分返回值被折叠成布尔结果，上层拿不到 -1/-6/-10 等错误语义。
• ViewPageUtil.ets:270-298：部分未知错误分支没有可见提示，可能让失败表现成长转圈或被其他网络提示覆盖。
• 调用链可归纳为：P2P 离线回调 → setDeviceStatus(false) → localDevice.isConnect 固定为 false → 后续设备列表与在线判断优先读取本地状态 → 服务端 devIsOnline=1 不生效；播放失败又与首帧超时、错误码折叠和提示缺失叠加。

5. 根因结论

• 置信度：现象 🟢 强；离线状态机缺陷 🟢 强；10 条反馈可由单一根因解释 🟡 中。
• 一句话根因：HarmonyOS 客户端把 P2P 瞬时离线写成本地持久状态，并在后续在线判断中优先使用这个旧值，可能导致设备已恢复在线却仍显示离线；回放离线态和播放错误透传不足则放大了用户的“看不到画面”体验。
• 关键证据链：同版本 10 名独立用户跨 9 个机型、7 个地区集中在离线与查看链路；当天回放失败率较前一日完整日上升；代码中离线写入、本地状态优先和缺少服务端在线态二次校正形成闭合路径。
• 明确不下的结论：不把所有“回放无内容”和“不录像”直接归为同一客户端缺陷。它们仍需设备固件、存储状态和服务端录像索引证据；当前根因结论只覆盖可解释的在线态粘滞部分。

6. 建议下一步

• 分配给：HarmonyOS 设备列表与 SDK 联动负责人；代码历史锚点为陈宝旺，回放链路负责人配合。沿用任务 T-20260926-115214-fdf9，状态保持 P1 / captured。
• 将 P2P 状态与服务端在线态拆成两个带时间戳的字段，禁止一个无限期覆盖另一个；P2P 离线后启动有限时长复核，服务端持续在线或再次收到心跳时应恢复为在线。
• 统一 setDeviceStatus 的状态源优先级和过期规则：本地连接态只覆盖一个短窗口，超时后回落到 devIsOnline + lastHeartTime/p2pLastHeartTime，并把最终来源写入埋点。
• 为 ReplayPage.isOffline 建立唯一写入源，区分设备离线、通道离线、无录像、SD 卡异常和播放首帧超时，不再复用同一个“网络断开”提示。
• 回访 10 条反馈，补齐设备 SN、固件、网络类型、故障时刻和服务端在线态；复现 P2P 离线后切网恢复、前后台恢复、断电重启、连续预览和卡回放各 20 次。
• 为 SiotDevConnectResult、预览首帧和回放首帧补齐 HarmonyOS 1.1.2.3 上报，要求包含 requestId/devId/error_code/duration/close_reason，否则下一期仍无法区分客户端状态错误和设备侧异常。

🟠 问题 2：iOS 8.4.4.1 报警消息设备筛选后闪退 ｜ 负责人：欧阳荣、唐胜

1. 现象与覆盖范围

• 258921：2026-10-22 18:11，iOS 8.4.4.1、iPhone、iOS 15.6.1、广东，反馈“18.05。 app闪退”。
• Logan 旧进程 11126 在 18:05:35 完成设备筛选，18:05:39 后停止写入；新进程 11403 于 18:05:43 启动，并显示 AppLaunch。这符合用户描述的 18:05 闪退与随后重新打开 App。
• 涉及反馈：1 条、1 名独立用户，但直接造成进程中断，不应按普通 UI 小问题降级。
• 严重度评分：70 / 100。反馈量 10（1 条独立反馈）、共性广度 30（iOS、8.4.4.1、iPhone、广东）、业务关键度 30（报警筛选属于消息查看和取证入口）。

2. Sensors 与友盟证据

• 2026-10-22，iOS 8.4.4.1 在当前 24 小时前的同日样本中记录到 1,630 条事件 / 12 UV，说明该版本确有线上或外部测试流量。
• Sensors 的 AppCrashed 在 8.4.4.1 下只查询到 Android 堆栈，没有 iOS 崩溃原因；因此不能把 Android 的 MainActivity2 方向错误套用到本问题。
• 友盟 APM 对该版本的 7 天和今日崩溃统计均返回 errorCount=0，但同时没有任何 iOS 样本证据。结合 Logan 的 PID 切换，判断为该构建未覆盖到 APM，而不是“没有发生闪退”。
• 当前没有可用的 iOS 原生崩溃栈，无法判断是 Swift/Kotlin 崩溃、原生列表对象生命周期错误，还是系统内存压力终止进程。

3. Logan 关键日志

• 反馈 ID：258921，Logan 文件 51e301fd-...log.gz，附件 Log0.txt 74,382 行、Log1.txt 2,159 行。
• Log0.txt:74182，18:05:06.900：MMKV onMemoryWarning，清理 seetong_kmp 内存缓存。
• Log0.txt:74184，18:05:08.543：第二次 onMemoryWarning。
• Log0.txt:74378-74380，18:05:35：设备筛选确认 deviceId=26080595，列表从 oldRowCount=128 重建为 newRowCount=2。
• Log0.txt:74382，18:05:39.288：旧进程最后一条 WebSocket 心跳后日志终止。
• Log1.txt:1-7，18:05:43：新进程 11403 重新出现启动流程、AppLaunch 和根控制器初始化；PID 与旧进程 11126 不同。
• 日志没有 NSException 或 SIGABRT 堆栈，因此“列表重建触发闪退”是当前最接近现场的可疑链路，不是已完全证实的唯一根因。

4. 代码定位

• 涉及模块：seetong-kmp/moduleMessage/src/commonMain/kotlin/com/seetong/modulemessage，iOS 宿主为 Seetong-App-iOS/.../KMP/KuiklyVC/STKuiklyAlarmMsgVC.m。
• AlarmMessagePage.kt:1081-1100：设备筛选确认后立即更新页面状态，调用 vm.applyDeviceFilter。
• AlarmMessagePage.kt:145-178：applyUiState 检测筛选条件变化后执行 listViewRef = null 和 listRenderGeneration++。
• AlarmMessagePage.kt:2048-2058：renderContent 通过 vbind({ pageState to listRenderGeneration }) 销毁并重新创建 AlarmMessageListView。
• 调用链为：设备筛选点击 → onDeviceFilterConfirmed → uiState 更新 → shouldRecreateListForFilterChange → 旧列表引用置空 → listRenderGeneration 变化 → AlarmMessageListView 整体重建。
• 高风险边界：当前列表有 128 行、12 个筛选项，同时刚经历两次内存警告；筛选结果虽只有 2 行，仍会先销毁大列表再重建，且下拉遮罩与列表引用在同一帧内切换。

5. 根因结论

• 置信度：现象 🟢 强；筛选与进程中断时序相关 🟢 强；具体触发根因 🟡 中。
• 一句话根因：设备筛选触发报警懒列表整体重建，在大列表、下拉遮罩和内存压力叠加时发生进程退出；当前缺少原生崩溃栈，尚不能确认是列表对象生命周期、KMP 状态重建还是系统内存终止。
• 关键证据链：用户明确报闪退 → 日志记录两次内存警告 → 设备筛选后 128 行列表整体重建 → 4 秒内旧 PID 停止 → 8 秒内新 PID 启动。
• 明确不下的结论：不把友盟 0 条当作未崩溃。APM 无该构建样本，且 Sensors 没有 iOS AppCrashed 记录，两个聚合源都不能反驳现场 Logan 的 PID 切换。

6. 建议下一步

• 分配给：iOS 与 KMP 报警消息负责人；代码历史锚点为欧阳荣，数据埋点近期改动涉及唐胜。新建任务 T-20261023-090823-a4dd，状态 P1 / captured。
• 保留现场并补采原生崩溃栈、ips 文件、内存峰值、VM 压力和 Xcode Organizer 崩溃记录；Logan 必须同时上传最后一次 KMP 回调、对象释放和新旧页面 generation。
• 将筛选更新改为列表实例内的数据替换，避免先 listViewRef=null 再整表重建；若必须重建，至少延迟到下拉遮罩完全关闭和当前触摸事务结束后执行。
• 为设备筛选增加状态代次和单一 owner 校验，旧代次的 item click、模态收起回调、列表 ref 回写必须丢弃，防止筛选期间旧视图事件落到已清空引用。
• 回归 100、500、1,000 条报警，连续切换设备、日期、类型筛选各 20 次，并覆盖低内存、前后台切换、下拉打开时点选、快速连点和缩略图加载中切换。
• 增加 alarm_filter_apply_start/end、list_recreate_start/end、memory_warning、process_session_id 埋点，用来量化该交互是否在其他 iOS 用户上复现。

本期扫描全量

已折叠 1 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。

反馈接口返回 total=112 / fetched=112 / complete=true / pages=3。上表按主问题唯一归类，合计 112 条。网络提示包含中文、英文、俄文和越南文模板；同一用户短时间重复提交不放大独立用户数。

心愿单与数据源状态

• 反馈平台：✅ 正常。total=112 / fetched=112 / complete=true / pages=3，逐条分类覆盖全部 112 条。
• 心愿单：✅ 正常。total=7 / fetched=7 / complete=true。
• Sensors：✅ 主查询成功。完成 DeviceVideoPlayback 的 7 天趋势、10 月 23 日失败码和版本分布；1.1.2.3 的 SIOT、预览首帧和 NVR 回放事件无可用数据，已作为观测缺口写明。
• Logan：⚠️ 部分可用。258921 的 Logan 和 OBS 日志可直接证明旧 PID 停止后新 PID 启动；问题 1 的 10 名 HarmonyOS 用户均未提供 Logan，根因置信度因此保持中等。
• 友盟：⚠️ 已查询。iOS 8.4.4.1 的 APM 崩溃统计为 0，但该构建缺少可用 iOS 样本，不能据此排除 258921 的现场闪退。
• 代码仓：✅ seetong-app-harmony、seetong-kmp、Seetong-App-iOS 均在标准路径，当前分支 feature_v8.4.2，工作区干净。已完成设备在线态、报警列表重建和 HarmonyOS 播放错误透传的调用链定位。
• TAPD：⏭️ 未调用。本窗口没有新的 BUG 单号，两项问题已有任务账本承载，先用日志和本地复现补齐根因。
• 任务账本：问题 1 更新 T-20260926-115214-fdf9；问题 2 新建 T-20261023-090823-a4dd。
• 待补证：问题 1 需服务端 devIsOnline/lastHeartTime/p2pLastHeartTime 与 10 名用户端 P2P 日志；问题 2 需 iOS 原生崩溃栈、内存曲线和 128 行列表筛选的稳定复现。

下一期 = 第250期 = 2026-10-23-H17.md（今天下午 17:00；窗口 今日 09:00:46～17:00）