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

🔴 问题 1：iOS 8.4.1.6 冷启动点击离线报警推送后未进入回放 ｜ 负责人：欧阳荣、谭伟、陈宝旺

1. 现象与覆盖范围

• 现象描述：用户收到 App 离线报警通知，点击通知进入 App 后没有直接打开报警对应视频；退出并重新启动 App 后，视频才能正常看到。反馈原文为「app出现报警点击通知进app打不开需要关闭应用在进才能看到视频」。
• 涉及反馈：257576（iOS 8.4.1.6 / iPhone 系统 18.6.2 / 河南商丘夏邑 / 08:07:23，Logan 与 OBS 日志均可下载）
• 覆盖维度：1 平台（iOS）× 1 版本（8.4.1.6）× 1 机型 / 系统（iPhone 18.6.2）× 1 地区（河南商丘）＝ 4 个记录维度
• 严重度评分：70 / 100（反馈量 10 / 共性 30 / 关键度 30）
• 反馈量 10：窗口内直接同类反馈 1 条；另有 257460 位于窗口起点 17:00:02，已在上一期作为同族问题分析，本期按重复案例处理
• 共性 30：单条反馈本身覆盖平台、版本、机型 / 系统、地区 4 个可核验维度；神策证据进一步覆盖 10,450 名 iOS 用户
• 关键度 30：报警消息进入回放属录像回放链路，取 30
• 关联但不重复计入：257460（iOS 8.4.1.6 / iPhone 26.6 / 河南驻马店）「报警视频打开好卡、点不开、划不动」已在上一期问题 1 与任务 T-20261014-090651-44e1 中记录；本期仅将它作为「报警入口稳定性」的延续信号，不重复计算反馈量。

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

• 事件可用性：DeviceVideoPlayback 在 2026-10-15 有 19,804,911 次 / 5,046,024 用户，2026-10-16 截至 09:00 有 4,124,411 次 / 1,874,602 用户；事件链路正常，下面的异常不是无数据造成。
• 场景分布（10-15 全量 / 10-16 截至 09:00）：

• iOS 版本标识：当前 OBS 日志明确打印 app_version=8.4.106，反馈平台展示为 8.4.1.6，可确认为同一 iOS 构建的两种版本表示，不是两套版本。
• 关键异常：10-16 截至 09:00，「离线推送进入回放」在 iOS 8.4.106 上：
• 会话 14,420 次 / 10,450 用户
• 平均首帧 81,496.683 ms
• <= 3 秒 14,006 次
• > 10 秒 131 次
• > 60 秒 62 次
• 当日样本最大 first_frame_time_ms 达 168,000,700 ms
• 同期对照：Android 8.4.1.6「离线推送进入回放」为 79,171 次 / 52,768 用户，平均首帧 1,009.709 ms，仅 20 次 > 10 秒、0 次 > 60 秒。
• 趋势：iOS 8.4.106 的离线推送回放在 10-09 ~ 10-16 每日均出现超过 60 秒的长尾，单日 >60 秒 为 326 / 321 / 277 / 327 / 273 / 338 / 291 / 62 次，呈持续状态而非当日单点。
• 证据边界：>60 秒 样本占 iOS 离线推送总会话约 0.43%，不等于「所有用户点击通知都打不开」；但这些极端值说明该入口存在会持续卡在首帧等待的长尾。神策没有「通知回调是否送达」「Push 打开是否成功」事件，因此不能直接用该指标证明反馈 257576 的直接根因。

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

• 当前问题时段（257576，Logan gzip 1,041 行；OBS zip 内 Log1.txt 90,988 行）
• 08:06:07.764：app_version=8.4.106
• 08:06:07.766：AppDelegate -- configRootVC - didFinishLaunchingWithOptions
• 08:06:07.788：应用已登录，开始设备列表与 WebSocket 初始化
• 08:06:08.057：重新注册 APNs device token
• 08:06:08.176：取得信令 token
• 08:07:21.611：开始上传反馈日志
• 08:07:22.221：打包并提交反馈日志
• 关键缺口：该冷启动片段内未出现 didReceiveNotificationResponse、decodedString、收到离线推送消息、[KMPRouter] openOfflinePushPlaybackPage 或 PlayBackPage。
• 同用户历史成功片段（OBS Log0.txt，9 月 26 日）

> [L29] 离线推送 -- didReceiveNotificationResponse - ... decodedString: {"bizType":"offline_alarm",...}
> [L44] [KMPRouter] openOfflinePushPlaybackPageBySelectingAlarmTab schedule select alarm tab then open playback, delay=0.10
> [L111] [KMPRouter] openPlaybackPage devId=45104370 ... fromOfflinePush=1 fromAlarmReplay=1
> [L918] hrv_callWithMethod:playVideoByTime, params={"time":"20260926144228",...}
> [L951] FC_P2PNvrReplayByTime success! result:0

• 同一用户在 9 月 26 日、9 月 27 日、9 月 30 日多次成功通过通知进入 PlayBackPage，说明代码中的通知 → 报警 Tab → 回放路由历史可用。
• Logan 结论：当前会话能确认 App 被冷启动、APNs token 正常注册，但没有通知响应回调与 KMP 回放路由。最可能的断点是系统通知响应未进入现有 content 处理分支，或进入后被 shouldHandlePushInViewController 条件拦截；现有日志未覆盖这两个判断结果，因此不能只凭“缺少回调”确证根因。

4. 代码定位（详细）

• 涉及模块：iOS 推送入口与 KMP 回放路由
• 关键类与锚点：

1. 通知响应入口

• AppDelegate.m:503-562：userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:
• AppDelegate.m:508：仅当 content.userInfo 包含 "content" 时进入离线报警 JSON 解码
• AppDelegate.m:520-551：Base64 还原 → STRemotePushModel → 按 bizType 分流；offline_alarm 进入 ReceivePushMessage
• AppDelegate.m:554-558：无 "content" 字段时只按标题和正文调用旧入口，不会携带报警 deviceId / alarmTime

2. 推送消费与页面路由

• AppDelegate.m:1074-1121：ReceivePushMessage:Title:，解析成功后保存 lineoffPushMsg，并调用 KMPRouter
• KMPRouter.m:458-499：openOfflinePushPlaybackPage，依次校验推送模型、设备列表是否就绪、导航控制器是否可用，再调用 openAlarmPlaybackPageWithParams
• KMPRouter.m:503-535：先切换报警 Tab，0.1 秒后进入回放；以 devUid|alarmTime 作为请求键防止重复打开
• 调用链：

APNs 通知 → didReceiveNotificationResponse → dict["content"] 解码 → ReceivePushMessage → saveLineoffPushMsg → KMPRouter.openOfflinePushPlaybackPageBySelectingAlarmTab → openAlarmPlaybackPageWithParams → PlayBackPage

• 关键分支：
• dict["content"] 缺失会走标题 / 正文回退，报警定位参数丢失。
• popModel.devUid 为空或 alarmTime 无法转成毫秒时间戳时，offlinePushPlaybackPageData 返回空，路由直接消费消息而不打开回放。
• 设备列表未就绪属于暂时失败，保留未读态等待后续重试；设备已就绪但目标设备不在账号则永久失败。
• shouldHandlePushInViewController 返回 NO 时，不会调用 KMPRouter，但当前日志未打印该分支结果。
• 代码缺口：AppDelegate.m 未检索到 UIApplicationLaunchOptionsRemoteNotificationKey 冷启动兜底处理。当前依赖 iOS 10+ 的 userNotificationCenter:didReceiveNotificationResponse: 回调；如果该回调缺失，现有代码没有从 launchOptions 二次提取报警推送的路径。
• 修复方向锚点：

1. 在 didFinishLaunchingWithOptions 与 didReceiveNotificationResponse 同时记录通知来源、userInfo key、bizType、deviceId、alarmTime 和路由结果，先补齐可观测性。
2. 对冷启动增加 launchOptions[UIApplicationLaunchOptionsRemoteNotificationKey] 兜底解析，或在通知响应缺失时从待处理推送模型中恢复。
3. 为 shouldHandlePushInViewController 的拒绝分支补日志和可重试状态，避免通知被静默吞掉。
4. 将 KMP 路由失败结果回传到原生入口，便于区分「已请求打开但回放失败」与「从未请求打开」。

5. 根因结论

• 置信度：🟡 中
• 一句话根因：当前冷启动没有留下通知响应回调或 KMP 回放路由证据，用户实际停留在普通启动链路；最可能的缺口是冷启动通知回调 / 参数分支未被当前处理逻辑承接或没有兜底，但尚不能确认是 APNs payload 缺 content、回调未到、视图条件拦截还是路由失败。
• 关键证据链：
• 当前 Logan：didFinishLaunchingWithOptions 出现，didReceiveNotificationResponse / PlayBackPage 缺失。
• 同用户历史 OBS：9 月多个日期同一 offline_alarm payload 可完整走通通知 → KMP 回放。
• 神策：iOS 8.4.106 离线推送回放每日存在超过 60 秒的长尾，且当天 62 次 >60 秒，说明该入口确有不稳定信号。
• 反馈原话与 Logan 观察互相吻合：关闭 App 再进入后能看到视频，指向冷启动入口而不是视频解码或设备离线。
• 明确不成立的推断：不得写成「iOS 8.4.1.6 报警回放整体失效」。10-16 09:00 前 iOS 8.4.106 仍有 14,006 次离线推送回放在 3 秒内出图，且历史日志多次成功。

6. 建议下一步

• 分配给：欧阳荣（AppDelegate.m:503-562、AppDelegate.m:1074-1121、KMPRouter.m:458-535 及 2026-10-09 离线推送修复提交的主要维护者）
• 优先处理项：

1. 真机复现「杀进程 → 点击 offline_alarm 通知 → 冷启动」，同时抓取 launchOptions、didReceiveNotificationResponse、ReceivePushMessage、openOfflinePushPlaybackPage 全链路日志。
2. 为缺失通知响应的冷启动增加 launchOptions 兜底，并验证 payload 中 content / 旧标题正文两种形态。

• 验证方法：Android 至少 1 台与 iOS 至少 2 台真机，分别在杀进程、后台、前台三态点击人形侦测报警通知；验收标准为无需重启即可进入对应 deviceId 与 alarmTime 的报警回放，且神策新增的通知入口成功 / 失败事件可区分。

🟠 问题 2：Android 8.4.1.7 KMP 回放页关闭窗口无效 ｜ 负责人：唐胜、陈宝旺

1. 现象与覆盖范围

• 现象描述：用户在 Android 8.4.1.7 的 KMP 回放页看到播放界面后，无法关闭回放窗口；反馈原文仅 8 个字「回放关闭不了窗口」，未说明是左上角返回按钮、系统返回键还是页面内弹层。
• 涉及反馈：257578（Android 8.4.1.7 / Redmi M2012K11AC / 广东江门新会 / 08:35:50，Logan 与 OBS logcat 均可下载）
• 覆盖维度：1 平台（Android）× 1 版本（8.4.1.7）× 1 品牌 / 机型（Redmi M2012K11AC）× 1 地区（广东江门）＝ 4 个记录维度
• 版本状态：8.4.1.7 在本窗口仅 1 条反馈；神策 10-15 ~ 10-16 也仅记录到预览场景 13 次 / 6 用户，尚无足量覆盖，属于新版本早期信号。
• 严重度评分：70 / 100（反馈量 10 / 共性 30 / 关键度 30）
• 反馈量 10：窗口内直接反馈 1 条
• 共性 30：平台、版本、品牌 / 机型、地区 4 个记录维度；但只有单一样本，样本广度不足
• 关键度 30：录像回放类，取 30

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

• 事件可用性：DeviceVideoPlayback 链路在 Android 8.4.1.6 上数据充分，但 Android 8.4.1.7 当前几乎无覆盖：

• 8.4.1.7 未出现「报警列表进入回放 / 离线推送进入回放 / 设备列表进入回放」场景事件。
• 同日 Android 8.4.1.6 回放链路基线正常：预览页面进入回放 2,384,522 次，离线推送进入回放 79,171 次、平均首帧 1,009.709 ms，报警列表进入回放 71,564 次、平均首帧 1,095.496 ms。
• 关键缺口：DeviceVideoPlayback 没有“关闭回放 / 页面退出结果 / closePage 调用结果”字段，无法从服务端回答有多少关闭请求失败。本问题不能以 8.4.1.6 的成功率替代 8.4.1.7 结论。

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

• 反馈 257578（Android 8.4.1.7 / Redmi M2012K11AC，156,418 bytes / 9,820 行）
• 回放页创建：

> [L2668] 08:33:04.032 KMP_SCAN_TRACE-onCreate page=PlayBackPage data={"devId":"47073890-CH-1",...,"fromPreviewPlayback":true,"canRotate":true}

• 页面初始化与常亮：

> [L2764] PlayBackPage created, portraitWidth: 392.72726, portraitHeight: 825.4545
> [L2792] PlaybackScreenAwake-Screen awake request page=PlayBackPage enabled=true
> [L2847] PlaybackScreenAwake-Screen awake applied=true

• 回放启动与下层应答：

> [L3097] KMPPlayBackVideoView: playVideoByTime devId=47073890-CH-1, time=20261016071843, alarmType=268435455, audioEnable=1
> [L3101] RecordPlayerView-startReplay: devId=47073890-CH-1, date=20261016071843, recordType=268435455
> [L3162] LibImpl-onNvrReplayResp, act=0,have audio=1,video codec=H265

• 后续页面栈：

> [L4515] KMP_SCAN_TRACE-onCreate page=AccountManagePage
> [L4616] KMP_SCAN_TRACE-onCreate page=SystemSetPage
> [L4705] KMP_SCAN_TRACE-onCreate page=ImprovePage
> [L5551] KMP_SCAN_TRACE-onCreate page=MessageCenterPage

• 关键缺口：日志内没有 closePage、finish、onDestroy 或可识别的关闭按钮事件；能看到用户后续进入其他 KMP 页面，无法判断回放页是被正常压栈、被关闭失败，还是关闭后 Activity 仍停留在栈底。
• 反馈 257578 的 OBS logcat（2,451 行）：
• 文件从 08:33:42.898 开始，时间为回放页首次创建后约 38 秒。
• 可看到 WelcomeActivity 超时线程、MainActivity2、KuiklyRenderActivity 与 KEYCODE_BACK 事件，但未覆盖首次点击关闭的准确时刻，不能作为直接失败证据。
• 结论：两路日志可证明回放已启动出流，不能证明关闭调用到达原生桥接。

4. 代码定位（详细）

• 涉及模块：Android KMP 宿主容器、原生桥接、KMP 回放页
• 关键类与锚点：

1. 关闭页桥接

• KMPBridgeModule.kt:856-858：closePage(params) 仅执行 activity?.finish()，无日志、无 Promise / callback、无 isFinishing 结果
• KRRouterAdapter.kt:19-21：框架路由关闭同样只执行 (context as? Activity)?.finish()
• KuiklyRenderActivity.kt:564-572：closePages(pageNames) 按页面名查找 Activity 后调用 finish()

2. 返回键处理

• KuiklyRenderActivity.kt:288-295：注册 OnBackPressedCallback，若无框架消费则关闭当前 callback 后再次调用 dispatcher
• KuiklyRenderActivity.kt:410-419：dispatchKeyEvent 在 ACTION_UP 再次调用 kuiklyRenderViewDelegator.onBackPressed()；未消费时再委托 super.dispatchKeyEvent
• 风险点：一次系统返回键可能先后经过 dispatchKeyEvent 与 OnBackPressedCallback 两套入口；如果前端某次返回 true 但没有真正执行关闭，事件会被吞掉，表现为“点了没反应”

3. 检测到页面仍在活动

• KMP_SCAN_TRACE-onCreate page=PlayBackPage
• PlaybackScreenAwake applied=true
• RecordPlayerView-startReplay 与 onNvrReplayResp act=0
• 调用链（界面关闭按钮，推断）：

PlayBackPage 关闭按钮 → KMPBridgeModule.closePage → activity?.finish() → KuiklyRenderActivity.onDestroy

• 调用链（系统返回键）：

KeyEvent.ACTION_UP → dispatchKeyEvent → kuiklyRenderViewDelegator.onBackPressed → [消费则返回 true]；[未消费则 super → OnBackPressedCallback → onBackPressedDispatcher → finish]

• 关键缺口：
• closePage 未记录 pageName、调用来源、Activity 是否为空、调用前后 isFinishing。
• 无 KMP 前端页面源码，无法确认关闭按钮是否一定调用了 closePage；当前仓库只看到原生桥接。
• 无关闭失败的统一错误回调，用户点击后前端无法显示失败或回退。
• 修复方向锚点：

1. 在 KMPBridgeModule.closePage 增加结构化日志与回调，记录 pageName、activity null、isFinishingBefore/After。
2. 统一返回键处理为单一路径，消除 dispatchKeyEvent 与 onBackPressedDispatcher 的双重消费风险。
3. 在前端关闭按钮点击处补埋点，区分「未调用桥接」「桥接收到但未 finish」「Activity 已 finish 但 UI 未消失」。

5. 根因结论

• 置信度：🔴 弱
• 一句话根因：当前只能确认 KMP 回放页成功创建并出流、用户随后进入其他页面，无法确认关闭请求是否到达 closePage；最可疑点是关闭桥接缺少结果反馈，以及返回键存在双重消费路径，但尚未形成直证。
• 关键证据链：
• Logan 证明 257578 在 08:33:04 创建 PlayBackPage。
• 下层 onNvrReplayResp act=0 证明播放链路已启动，问题不在首个出流请求。
• 反馈原文只描述关闭窗口失败，与关闭桥接 / 返回键路径直接相关。
• 当前代码中 closePage 仅 finish 且无日志，无法自证调用成功或失败。
• 明确不成立的推断：不得写成「8.4.1.7 回放页完全无法退出」。后续日志显示用户已进入账号管理、系统设置和消息中心等页面，说明页面栈并非绝对卡死；问题可能仅限于某个关闭按钮、弹层或返回键分支。

6. 建议下一步

• 分配给：陈宝旺（KMP 宿主返回键处理与桥接维护者）；唐胜配合确认 PlayBackPage 关闭按钮前端调用与页面状态
• 优先处理项：

1. 在 closePage 和返回键两条路径补全链路日志、调用来源、Activity 状态和最终 finish 结果。
2. 复核 dispatchKeyEvent 与 onBackPressedDispatcher 的双重处理，确保一次返回只执行一次关闭决策。

• 验证方法：使用 8.4.1.7 真机分别验证播放页左上角关闭、系统返回键、手势返回和页面内弹层关闭；每次记录前端按钮事件、桥接调用、finish 结果与最终可见 Activity。回归卡回放、云回放和报警回放三种入口。

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

Markdown 保留全部反馈；HTML 呈现时渲染器会自动折叠 🟣 普遍性网络问题。以下分组覆盖窗口内 122 条反馈。

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

本期重点反馈明细（非网络类，按时间倒序）

HarmonyOS Logan 覆盖情况（第 14 期连续零覆盖）

本窗口 HarmonyOS 的 257577、257528、257512、257503、257469、257553 均无 Logan。断电不能回放、无报警消息、画面异常等问题无法进一步定位。

近期问题延续

任务账本联动

数据源状态汇总

心愿单亮点

待补证

1. iOS 冷启动通知回调缺口：需要复现「杀进程 → 点击 offline_alarm 通知」，同时记录 launchOptions、userInfo key、didReceiveNotificationResponse、ReceivePushMessage、KMPRouter 与 PlayBackPage。当前日志只能确认缺失，不能确认缺失发生在系统回调还是 dict["content"] 分支。
2. iOS 通知点击埋点缺失：需要新增通知到达 / 点击 / 路由成功 / 路由失败事件，才能把神策 DeviceVideoPlayback 的长尾与具体通知入口对齐。
3. iOS 长尾数据校验：first_frame_time_ms 出现 8.65 亿毫秒等极端值，需确认是否存在 App 挂起后恢复时才补报的时间差；否则该字段不能直接对外表述为“用户等待了 10 天”。本期只把它作为长尾信号，不作为用户体验时长。
4. Android 8.4.1.7 closePage 调用结果：当前日志没有 closePage、finish 或页面销毁记录；需补结构化日志后复现。
5. Android 返回键双路径复核：KuiklyRenderActivity.dispatchKeyEvent 与 OnBackPressedCallback 对同一返回事件存在重复处理可能，需要 owner 确认是否符合 Kuikly 框架预期。
6. KMP 前端关闭按钮源码：当前工作区只有 Android 宿主与桥接，PlayBackPage 关闭按钮是否调用 closePage 需在 KMP 前端仓库核对。
7. HarmonyOS Logan 连续 14 期零覆盖：需服务端与客户端共同定位上报链路断点；在补齐前，HarmonyOS 回放、报警、断电恢复问题均只能维持弱置信度。
8. 断电恢复跨端线索：257577（HarmonyOS）与 257540（Android）均为供电恢复后设备不可用，需回访确认设备是否重新上线、是否恢复出厂、指示灯与网络状态；不能仅凭反馈文案归因 App。

下一期 = 第236期 = 2026-10-16-H17（今天下午 17:00；窗口 今日 09:00 ~ 17:00）