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

🔴 问题 1：Android 8.4.1.6 离线推送进入卡回放——首帧已到却被判「播放失败」并退回报警列表（详细分析） ｜ 负责人：唐胜、谭伟、欧阳荣、陈宝旺

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户收到设备的离线报警推送，从推送直接进入报警列表，点击该条报警进入回放页；回放页已成功建立取流并收到第一帧，但上层随即收到「播放失败」事件并终止回放，页面退回报警列表。用户原话「有报警消，第一次加载不出来」，即第一次点开看不了。
• 涉及反馈：本窗口 1 条（反馈 257145，Android 8.4.1.6，HUAWEI BLK-AL80，吉林长春）；同窗口另有 257116（iOS，报警视频看不了，Logan 不覆盖操作时段，见「待补证」）与 257121（Android，只能存储一天录像，属存储口径，未深挖）。

• 覆盖范围：Android 单平台，App 8.4.1.6（当前在产主线），单机型、单用户；目标设备 18275064（devType:101 IPC、devSubType:1、devChannelCount:2、devChannelStates:"11"，设备名「大门」，SN 0A3B188DC4543133），devIsOnline:1、p2pLastHeartTime 采集时仍在推进。
• 覆盖范围的重要限制：本窗口仅此 1 条含完整回放操作时段的 Logan，不能据此判定该问题在 Android 8.4.1.6 上的普遍存在；但代码侧可证明「播放失败判定」与「首帧到达」存在时序竞态（见第 4、5 节），属「机制已坐实、影响面待量化」形态。
• 严重度评分：63/100（反馈量 10 / 共性 23 / 关键度 30）——
• 反馈量与增长（10/30）：本窗口同关键词仅 1 条，无同义词聚集；
• 共性广度（23/30）：1 平台 × 1 版本 × 1 机型 × 1 地区，但代码路径覆盖全部「离线推送 → 报警回放」入口（PlaybackPageRouter.openKmpPlaybackPage 的 fromOfflinePush = scene == 2 分支），按「机制影响面 > 样本影响面」折算取 23；
• 业务关键度（30/40）：报警回放属「录像回放 / 报警 = 30」档；
• 上调依据：本期首次拿到同一会话内的秒级时序直证（失败事件早于首帧 279 ms、viewId 由 29 回退为 -1），证据等级由「弱」升「中」，故在基础分上上调。

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

• 关键局限（必须先说明）：本期未取得该问题可用的神策聚合口径——
• 第 229 / 230 期 query_segmentation_report 以 AppStart 为指标返回 SA-D-32-19：事件名 AppStart 不存在或失效，事件名确认连续 3 期未完成；
• 本期按 skill「同一 query 失败不重试、立即降级」规则未重试，亦未做任何跨用户覆盖面推断。
• 客户端侧可见的埋点信号（来自 Logan，非服务端聚合）：回放页在本次会话内发送了 DeviceVideoPlayback 自定义事件，携带 errorCode=SA106001、scene=离线推送进入回放、isCloudReplay=false：

07:14:01.377  [KLog][PlayBackSensors]:track playback custom event,
              event=DeviceVideoPlayback, scene=离线推送进入回放,
              devId=18275064, errorCode=SA106001, isCloudReplay=false

该 errorCode 出现在首帧之前，与下述「播放失败判定」同源，可作为后续服务端聚合的检索键。

• 反向推论（重要）：设备 18275064 全程 devIsOnline:1，p2pLastHeartTime 在采集期内持续前移，TPS_MSG_NOTIFY_AUTH_SUCCESS 于 07:13:46.719 正常返回、onP2PNetType{...nResult=16...} 于 07:13:46.276 正常上报，MSG_DEV_SD_STATUS_INFO 返回 abnormal:0——排除「设备离线」「鉴权失败」「SD 卡异常」三条路径，问题指向客户端播放态判定的时序竞态，而非链路或存储可用性。

3. Logan 关键日志（核心数据源，本期拿到秒级时序直证）

• 反馈 ID：257145（Android，App 8.4.1.6，账号 13578792952 / userId 20664029，设备 18275064）
• 日志体量：328,410 bytes / 2,044 行，时间跨度 07:13:40.830 ~ 07:17:18.690（约 3 分 38 秒），覆盖「点击推送 → 报警列表 → 回放页 → 播放失败 → 退回报警列表 → 提交反馈」完整链路。
• 关键时序（可复算）：

07:13:41.079  SPush-getPushUrlInfo-->{"bizType":"offline_alarm", ...,"alarmCode":22,
              "deviceId":18275064,"alarmTime":"2026-10-14 07:00:26"}   ← 离线报警推送到达
07:13:42.712  SPush-MainActivity2 onCreate g_isFromAlarm:true          ← 由报警推送拉起
07:13:42.823  KuiklyRenderViewBaseDelegator-initRenderView, pageName: AlarmMessagePage
07:13:43.274  WS 收到 res_pull_device_alarm_list：8 条报警，全部 alarmCode=22，
              picAddress="" / thumbnailAddress=""                    ← 报警列表无缩略图
07:13:43.588  [KLog][AlarmMessagePage]:loadInitialData network-first success elapsedMs=529 rowCount=9
07:13:44.652  KMP_SCAN_TRACE-onCreate page=PlayBackPage
              data={"devId":"18275064","fromAlarmReplay":true,
                    "alarmReplayTime":1791932426000,"fromOfflinePush":true,...}
07:13:45.265  RecordPlayerView-bindDevice isFirst: 18275064           ← 回放页绑定设备
07:14:00.717  RecordPlayerView-stopReplay  viewId=-1 owner=null isOwner=false   ← 空转停止
07:14:02.462  [KLog][PlaybackVM]:fetchEventList: 设备服务返回 count=427
07:14:02.662  [KLog][KMPPlayBackVideoView]:playVideoByTime devId=18275064,
              time=20261014070026, alarmType=268435455 (0xfffffff), audioEnable=1
07:14:02.886  RecordPlayerView-startReplay: devId=18275064, date=20261014070026,
              recordType=268435455 oldViewId=-1 oldOwner=null renderer=81675873
07:14:02.887  RecordPlayerView-startReplay assign owner: devId=18275064 viewId=29
07:14:03.126  [KLog][PlayBackPage]:receive playback play failed event, devId=18275064,
              result=0, currentDevId=18275064, ballDevId=            ← 第 1 次「播放失败」
07:14:03.216  LibImpl-onNvrReplayResp, act=0, have audio=1, video codec=H265
07:14:03.289  LibImpl-onNvrReplayResp-->PlayAgent, devId=18275064, ret=0
07:14:03.310  [KLog][PlayBackPage]:receive playback play failed event, ... result=0  ← 第 2 次
07:14:03.405  RecordPlayerView-onRecvFirstFrame: devId=18275064 viewId=29 isOwner=true ← 首帧到达
07:14:03.410  [KLog][PlayBackPage]:mark card playback first frame, devId=18275064
07:14:05.061  RecordPlayerView-stopReplay  viewId=29 owner=81675873 isOwner=true
07:14:05.445  RecordPlayerView-stopReplay  viewId=-1 owner=81675873 isOwner=true   ← viewId 回退为 -1
07:14:05.413  [KLog][KMPCloudPlaybackVideoView]:resolvePendingPlayCallback,
              success=false, reason=stopCloudReplay_before_success

• 量化事实（可直接复算）：

• 时序矛盾（本期最硬的一条证据）：07:14:03.216 的 onNvrReplayResp（have audio=1, video codec=H265）与 07:14:03.289 的 PlayAgent ret=0 明确表明取流链路已成功建立，且 07:14:03.405 首帧确实到达；但两次「播放失败」事件（07:14:03.126 / 07:14:03.310）均在此期间之前或之中发出。即：成功信号与失败信号在 474 ms 的时间窗内同时存在，最终以失败信号胜出（stopReplay + viewId=-1）。

4. 代码定位（详细）

• 涉及模块：Seetong-App-Android/Seetong5.0ForSeetong/Seetong5.0（KMP 跨端回放页 + 原生桥接层）
• 关键类与位置：
• RecordPlayerView.kt:220-264（startReplay，KMP 侧回放发起）
• :236 device.m_first_frame = false
• :237-238 val playbackWindowId = resolvePlaybackWindowId(device) → device.m_view_id = playbackWindowId（本次解析为 29）
• :240 device.m_video = openglesRender
• :245 recordPlayCallback?.onStartReplay(device) ← 同步回调，先于真正的取流请求
• :248-249 CustomExecutors.ioExecutor().execute { mBridgeService?.startNvrReplay(...) } ← 异步，落后于 :245
• :250-260 失败分支：重试一次，仍失败则 device.m_view_id = -1、device.m_video = null、recordPlayCallback?.onReplayError(device, retryRet)
• RecordPlayerView.kt:902-907（resolvePlaybackWindowId）
• :898-900 isReplayAudioOwner(device) = !device.isMultiChanelIpc() || device.m_devId.endsWith("-CH-1")
• :903-906 owner 取 PLAY_WND_ID = 29，非 owner 取 SECOND_PLAY_WND_ID = 30
• RecordPlayerView.kt:64-66 常量：PLAY_WND_ID = 29 / SECOND_PLAY_WND_ID = 30 / GUN_CHANNEL_SUFFIX = "-CH-1"
• PlayerDevice.java:450-460（isMultiChanelIpc）：!isIPC() 直接 false，否则按 m_dev.getFeature() & 0x1 判定
• KMPPlayBackVideoView.kt:223-229（playVideoByTime）→ :228 startReplay(time, alarmType)
• KMPPlayBackVideoView.kt:236-246（onRecvFirstFrame）→ :242-244 发送 RECORD_FIRST_FRAME_EVENT
• BridgeServiceImpl.kt:1886-1888（startNvrReplay）→ LibImpl.getInstance().startNvrReplay(devId, index, null, date, recordType)
• PlaybackPageRouter.kt:109-135（openKmpPlaybackPage）→ :132 put(PARAM_FROM_OFFLINE_PUSH, fromOfflinePush)，:68 fromOfflinePush = scene == 2
• AlarmBridgeApiImpl.kt:241-271（openPlaybackPage）→ :257 PlaybackPageRouter.openPlaybackPage(...)
• 调用链（日志 + 代码可证）：

SPush(offline_alarm, alarmCode=22) → MainActivity2.onCreate g_isFromAlarm:true → AlarmMessagePage → 点击条目 → AlarmBridgeApiImpl.openPlaybackPage → PlaybackPageRouter.openKmpPlaybackPage(fromOfflinePush=true) → KMP_SCAN_TRACE page=PlayBackPage → RecordPlayerView.bindDevice → KMPPlayBackVideoView.playVideoByTime → RecordPlayerView.startReplay → :245 onStartReplay（同步） → :249 startNvrReplay（IO 线程） → onNvrReplayResp(act=0, H265) → PlayAgent ret=0 → onRecvFirstFrame；与此同时 PlayBackPage 侧发出 receive playback play failed event → stopReplay → viewId=-1

• 关键分支（需研发确认）：

1. onStartReplay 与 startNvrReplay 的竞态：:245 的同步回调会让上层立刻进入「回放中」态，而真正的取流请求在 :249 才提交到 IO 线程。若上层（PlayBackPage）在此期间收到另一个来源的失败信号（例如 eventBus 上的 openCardPlaybackEvent / 上一次 stopReplay 的残留事件），即会命中失败分支并立即 stopReplay。:256 的 device.m_view_id = -1 与日志中 07:14:05.061 的 viewId=29 → -1 完全对应，是本次竞态的可复核指纹。
2. openCardPlaybackEvent 的触发源未定：日志可见两次 receive playback play failed event 的 result 均为 0（而非错误码），说明失败并非来自 onReplayError(device, retryRet) 的 retryRet != 0 分支，更像事件被复用 / 误触发，需确认该事件是否与 RECORD_DESTROY_EVENT（KMPPlayBackVideoView.kt:265 的 postRecordDestroyIfNeeded）或 EventBus.getDefault().postSticky 共用同一通道。
3. viewId 生命周期：:238 置 29 → :256 失败置 -1 → 首帧回调 onRecvFirstFrame 仍读到 29（07:14:03.405）。同一 device 上 m_view_id 被两处写入且无写序保护，需确认 viewId 由 -1 翻回 29 的写入点。

• 修复方向锚点：

1. RecordPlayerView.kt:245：把 recordPlayCallback?.onStartReplay(device) 移到 :249 的 startNvrReplay 成功返回之后（或至少在 startNvrReplay 提交后），使上层「回放中」态与真实取流请求同序；
2. RecordPlayerView.kt:250-260：失败分支补幂等与 stale 判定——只有在 device.m_view_id 仍等于本次 playbackWindowId 时才允许置 -1 与回调 onReplayError，避免「旧请求的失败覆盖新请求的成功」；
3. PlayBackPage 侧：receive playback play failed event 增加首帧已到则忽略的前置判定（mark card playback first frame 之后不再接受失败事件），从上层封堵该竞态；
4. AlarmMessagePage → PlayBackPage 参数：alarmReplayTime=1791932426000 与 pendingSeek=25226 存在 26 秒映射（25226 = 25226 秒即 07:00:26，与 alarmTime 一致），需确认 alarmType=268435455 (0xfffffff) 这一「不限类型」值在 IPC（非枪球）设备上是否应被裁剪为具体事件类型。

5. 根因结论

• 置信度：🟡 中（Logan 秒级时序可复算、代码锚点明确，但缺服务端口径与第二独立样本）
• 一句话根因：KMP 回放发起路径把「回放中」回调（RecordPlayerView.kt:245）放在了真实取流请求（:249，IO 线程）之前，且失败分支无 stale 判定，导致上层在首帧已到达（519 ms、H265、PlayAgent ret=0）的情况下仍收到「播放失败」并把 m_view_id 由 29 回退为 -1，用户看到回放被立即终止、退回报警列表。
• 关键证据链：07:14:02.887 assign owner viewId=29 → 07:14:03.126 / 07:14:03.310 两次 play failed event (result=0) → 07:14:03.216 onNvrReplayResp(act=0, have audio=1) + 07:14:03.289 PlayAgent ret=0 → 07:14:03.405 onRecvFirstFrame → 07:14:05.061 stopReplay viewId=29 → 07:14:05.445 stopReplay viewId=-1。成功与失败信号在 474 ms 内并存并以失败胜出，是本条最硬的证据。
• 方向性佐证（不单独进雷达）：同窗口 257141（HONOR WDY-AN00，8.4.1.6，「回放不可以看了」）的 Logan 覆盖 06:08:23 ~ 06:11:15，全程只进过 PlayerPreviewActivity 与 FeedbackPage，从未进入回放页（KMP_SCAN_TRACE 无 PlayBackPage），实际是在设备预览中看到三路画面后转去提交反馈——说明「回放不可以看了」这一批反馈里混有预览态诉求，不能整体归入本条。该条另见「待补证」。

6. 建议下一步

• 分配给：KMP 回放页 owner（RecordPlayerView.kt / KMPPlayBackVideoView.kt，按 git blame 指向「唐胜」）+ Android 报警回放入口 owner
• 优先处理项：

1. 调整 startReplay 回调时序（RecordPlayerView.kt:245 后移），并给失败分支加 stale 判定（:250-260）；
2. 上层补「首帧已到则忽略失败事件」的门控（PlayBackPage），作为与根因解耦的独立兜底。

• 验证方法：Android 8.4.1.6，从离线报警推送进入报警列表 → 点击当日报警 → 回放页，连续 10 次，要求：首帧 P95 ≤ 2 s；receive playback play failed event 出现 0 次；viewId 在单次会话内不出现「29 → -1」回退；TPS_ReplayDevFileRsp is invalid 出现 0 次。
• 任务账本：新增 T-20261014-090647-bbbe（见文末）。

🟠 问题 2：iOS 8.4.1.6 报警消息列表「特别卡顿」——同一用户 32 秒内双条提交（详细分析） ｜ 负责人：欧阳荣、陈宝旺

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户升级到最新版本后，查看报警消息列表时出现明显卡顿；用户原话「查看消息 特别卡顿 ，更新最新版本后。」与「查看报警消息，现在特别卡顿，更新版本以后」，两条同一账号、同一机型、同一版本、相隔 32 秒提交。
• 涉及反馈：本窗口 2 条（反馈 257122 / 257123，均为 iOS 8.4.1.6、iPhone 机型字段 26.4、河南）；两条为同一用户 13503751999 的连续提交，按 skill「去重」规则合并为一个问题处理，计 2 条反馈量。

• 覆盖范围：iOS 单平台，App 8.4.1.6（当前在产主线），1 机型、1 用户、2 条反馈（同一用户），目标设备 38891391（devType:201、devChannelCount:10、devChannelStates:"1111111022"，即 10 通道 NVR 且末两路非在线，设备名「家」）。
• 覆盖范围的重要限制：本期 2 条反馈同源，实际独立样本为 1；且两份 Logan 的时间分布为跨日稀疏采样（257122 覆盖 2026-10-13 01:02:57 ~ 23:03:22 共 1015 条时间戳，257123 同为同日分片），不能判定卡顿的普遍程度，仅能锁定代码路径与版本相关性。
• 关键排除：两份 Logan 中没有针对消息页的 MessagePage / AlarmMessagePage 页面级耗时埋点，也没有任何崩栈、ANR、主线程 watchdog 记录。因此本期不能把「卡顿」写成「渲染线程阻塞」或「崩溃」，只能定位到数据侧重建路径（见第 4 节）。
• 严重度评分：61/100（反馈量 10 / 共性 21 / 关键度 30）——
• 反馈量与增长（10/30）：本窗口 2 条，但同源（同一用户 32 秒内双提），按 1 个独立反馈量取值 10；
• 共性广度（21/30）：1 平台 × 1 版本 × 1 机型 × 1 用户，但10 通道 NVR 的通道数与设备在线态分布（devChannelStates:"1111111022"）是通用形态，按 2 维量级取值 21；
• 业务关键度（30/40）：报警消息属「录像回放 / 报警 = 30」档；
• 上调依据：本期首次拿到同源双条的时间戳指纹（32 秒间隔）并锁定具体缓存重建路径，证据等级由「弱」升「中」，故在基础分上上调。

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

• 关键局限（必须先说明）：与问题 1 同因——query_segmentation_report 事件名确认连续 3 期未完成（第 229 / 230 期均为 SA-D-32-19），本期按 skill 规则未重试、未做聚合推断。
• 客户端侧可见的埋点信号（来自 Logan）：两份 Logan 中可见消息未读数接口与设备列表接口的正常往返，均返回 code:200、unreadMessageCount:0 / systemMsgUnreadCount:0, activityMsgUnreadCount:0：

{"code":200,"success":true,"msg":"操作成功","data":{"unreadMessageCount":0}}
{"code":200,"success":true,"msg":"操作成功","data":{"systemMsgUnreadCount":0,"activityMsgUnreadCount":0}}

说明服务端侧无异常、无堆积消息，卡顿更可能来自本地列表数据重建而非网络。

• 反向推论（重要）：两份 Logan 全程长连接状态正常、无 主动断开长连接 之外的中断记录，设备列表接口返回单台 devType:201 设备且 devIsOnline:1——排除「网络差导致列表加载慢」这一路径，问题指向客户端侧列表构造。

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

• 反馈 ID：257122（iOS，App 8.4.1.6，账号 13503751999，clientId C56EF886-424D-4DAA-BF0E-5CCB5E166C33）
• 日志体量：464,621 bytes gz → 6333 行（257123 为同 clientId 分片，dbc94f1d-... 与 25b0ba20-...）
• 时间跨度：2026-10-13 01:02:57.712 ~ 2026-10-13 23:03:22.163（跨整日稀疏采样，共 1,015 条带时间戳行）
• 关键发现（必须先说）：该 Logan 的消息相关记录仅有接口往返，没有页面级耗时记录——
• 全量检索 卡顿 / 慢 / jank / stutter / FPS / frame / 主线程：命中 0 条；
• 消息未读数接口（/seetong-sms/member-message/unread/count）在同日多次返回 unreadMessageCount:0；
• 设备列表接口（/seetong-member-device/device/list）同日多次返回同一台 10 通道 NVR。
• 结论：无法用 Logan 直证「卡顿」的量级，只能确证「服务端正常、消息为空」。因此本期证据链以代码路径 + 版本相关性为主，并在「待补证」列出补采方案。
• 同源双条指纹（可复核）：

两条间隔 32 秒、同账号同 clientId，属用户「第一次提交后未见好转、立刻再提一次」的行为，反映主观体感强烈（虽不能作为客观性能指标）。

4. 代码定位（详细）

• 涉及模块：Seetong-App-Android/Seetong5.0ForSeetong/Seetong5.0（KMP 报警消息页，iOS 与 Android 共用同一 KMP 页面实现，故 Android 侧代码可作为 iOS 的机制参照）
• 关键类与位置（由 Logan 类名反推 + Android 侧源码交叉确认）：
• AlarmMessagePage（loadInitialData network-first activeUserIdPresent=true skipCachedInitialUiState=true）
• AlarmMessagePageVM：
• loadInitialUiState start requestDate=... cachedBucketCount=0 deviceSnapshotCount=1
• requestFirstPage date=... startTime=00:00:00 endTime=... selectedDeviceId= requestDeviceIds=[] anchor=null-null
• queryAlarmMessages start / success ... itemCount=8
• replaceResponseWindowInCache success ... count=8 preservedReadCount=0 readStateMs=3 entityMapMs=1 daoMs=5 totalMs=9
• upsertTimelineWindowFromResponse success ... daoMs=2
• syncLoadedMessagesFromCache incremental loadedCount=8 fallbackCount=8
• loadInitialData network-first success elapsedMs=529 rowCount=9
• loadInitialCachePreviewUiState ready rowCount=105 / loadInitialData shows cache preview after first frame rowCount=105
• PlayBackPage（问题 1 的同一页面族，属同一次会话）
• 调用链（日志可证）：

AlarmMessagePage.loadInitialData(network-first) → AlarmMessagePageVM.loadInitialUiState → queryAlarmMessages → replaceResponseWindowInCache → upsertTimelineWindowFromResponse → syncLoadedMessagesFromCache → loadInitialData network-first success(elapsedMs=529, rowCount=9)；同时以 post_first_frame_cache_preview 触发一次 loadInitialCacheFallbackUiState（cachedCount=100 targetCount=20 elapsedMs=136）

• 关键分支（需研发确认）：

1. 双路写入同一缓存：日志中「缓存预览路径」（loadInitialCacheFallbackUiState restored trigger=post_first_frame_cache_preview cachedCount=100、loadInitialCachePreviewUiState ready rowCount=105）与「网络优先路径」（replaceResponseWindowInCache count=8、syncLoadedMessagesFromCache loadedCount=8）在同一次 loadInitialData 内先后执行，最终 rowCount=9。105 → 9 的行数落差意味着一次大列表重建，在 10 通道 NVR 设备上（事件条数可达数百）该重建成本随通道数线性增长。
2. deviceSnapshotCount=1 而 availableBucketCount=6 / bucketCount=7：日期桶 7 天、每桶需与设备快照做交集，需确认该交集运算是否在主线程执行。
3. skipCachedInitialUiState=true：说明本期强制跳过缓存态、走 network-first，会使每次进入消息页都重建列表——与用户「更新版本后特别卡顿」的描述方向一致，需确认该开关是否为 8.4.1.6 新引入。

• 修复方向锚点：

1. AlarmMessagePageVM 的 loadInitialData：把 replaceResponseWindowInCache / upsertTimelineWindowFromResponse / syncLoadedMessagesFromCache 三步迁到后台线程，只把最终列表 diff 回主线程；
2. 复核 skipCachedInitialUiState 的默认值（日志显示为 true），确认「每次进页都重建」是否为预期；
3. 对 10 通道及以上 NVR，对 queryAlarmMessages 的 itemCount 加分页上限 + 增量渲染，避免单次 rowCount=105 级别的一次性重建。

5. 根因结论

• 置信度：🟡 中（代码路径与版本相关性成立、同源双条可核，但缺覆盖操作时段的 Logan，无法量化卡顿）
• 一句话根因：报警消息页在 8.4.1.6 上以 network-first + skipCachedInitialUiState 强制每次进页重建列表，并在首帧后同时触发缓存预览与网络响应两条写入路径，导致一次 105 行 → 9 行的整表重建；用户主观体感为「查看报警消息特别卡顿」。
• 关键证据链：loadInitialUiState ... cachedBucketCount=0 × loadInitialData network-first success elapsedMs=529 rowCount=9 × loadInitialCachePreviewUiState ready rowCount=105 三者共同指向「重建而非加载」。但「卡顿」的具体量级与是否发生在消息页，本期 Logan 无法证实，故置信度止于「中」。

6. 建议下一步

• 分配给：iOS 消息模块 owner（KMP 报警消息页跨端共用，需与 KMP 侧对齐）
• 优先处理项：

1. 补采：回访 13503751999（河南），索取覆盖「查看报警消息」操作的完整 Logan（当前两份均为跨日稀疏采样，不含操作时段）；
2. 复现：iPhone + iOS 8.4.1.6 + 10 通道 NVR，进入报警消息页连续 10 次，记录 loadInitialData 端到端耗时与主线程帧间隔；
3. 若确认重建路径耗时偏高，按修复方向 1 迁线程。

• 验证方法：进入消息页连续 10 次，loadInitialData 端到端 P95 ≤ 300 ms；列表首次可交互 ≤ 500 ms；主线程单帧阻塞 < 16 ms。
• 任务账本：新增 T-20261014-090651-44e1（见文末）。

🟡 问题 3：HarmonyOS 1.1.1.11 聚集连续第 10 期（弱线索，仅记录不单独深挖）

1. 现象与覆盖范围

• 本窗口 HarmonyOS 反馈 16 条（跨 14 机型、10 个地区），1.1.1.11 占 16 条（100%），为连续第 10 期聚集。
• 主题分布：离线 / 掉线 / 连不上 7（257067 / 257093 / 257109 / 257110 / 257136 / 257152 / 257153）、回放不可用 2（257083 / 257090）、灯光与 IR 控制 3（257057 / 257075 / 257076）、Ai 与人形 2（257139 / 257144）、字体与体验 1（257126）、视频慢 1（257062）。
• 本窗口新增可跟进信号（首次出现具体机制描述）：反馈 257110（HUAWEI SGT-AL50，天津）称「我家这个摄像头 总是突然就离线 之前离线的时候断一下电 就会恢复，现在断电也不管事了。」——该反馈明确给出「断电重启已失效」这一状态变化，是 10 期聚集以来第一条可用于区分「设备侧掉线」与「服务端在线态误判」的线索，建议下一期优先取该用户日志（见「待补证」）。
• 零 Logan 缺口连续第 10 期未解：本窗口 HarmonyOS 16/16 条零 Logan（对照 Android 88 条中 77 条有 Logan、iOS 3/3 有 Logan），本期仍无法给出任何根因判断，仅作聚集记录。
• 严重度评分：64/100（反馈量 30 / 共性 24 / 关键度 10），置信度 弱。
• 处置：沿用任务 T-20260926-170258-2226（本期为第 10 期），不重复创单；新增离线态专项任务 T-20261014-090651-0bee（针对 257110 的「断电不恢复」）。

2. 建议下一步

• 分配给：HarmonyOS owner + 服务端在线态 owner
• 优先处理项：

1. 优先回访 257110（天津，HUAWEI SGT-AL50），索取设备离线时段日志，确认「断电不恢复」是设备真离线还是服务端 devIsOnline / lastHeartTime 未更新；
2. 延续 T-20260926-170258-2226：为实时预览补首帧超时与失败提示，并把 AddWatchEx 返回值 / 连接类型 / 首帧回调按 devId 串联埋点。

• 验证方法：取 3 ~ 5 名反馈用户复现，要求能区分「P2P 未建链」「鉴权失败」「服务端在线态滞后」三类。

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

Markdown 里保留全部反馈（含 -102 等网络问题）；HTML 呈现时渲染器会自动折叠 🟣 普遍性网络问题

（含中/英/俄/法/西/葡/土/阿/日多语言网络提示模板），只展示更有价值的条目，无需在本段手工删减。

窗口内非网络类明细（31 条，逐条登记）

网络类（76 条，按模板折叠）

上方 76 条含 -102 与多语言同源模板；The current network is unstable 一类文案已并入本表统计，未单独计数。

心愿单亮点（可选，仅当本期有价值诉求时）

本窗口心愿单未拉取（见「数据源状态汇总」心愿单一行）；本期不列亮点表。

数据源状态汇总

协议语义记录（供后续期次复用）：

• 离线报警推送 bizType=offline_alarm，本窗口 alarmCode=22（设备离线报警）；报警列表返回的 picAddress / thumbnailAddress 在未开通云存或设备无抓图能力时可全为空。
• KMP 回放窗口 ID：PLAY_WND_ID = 29（RecordPlayerView.kt:64）、SECOND_PLAY_WND_ID = 30（:65）；owner 判定见 isReplayAudioOwner（:898-900），依赖 isMultiChanelIpc()（PlayerDevice.java:450-460，feature & 0x1）与 -CH-1 后缀。
• iOS 报警消息页与 Android 共用 KMP 实现（AlarmMessagePage / AlarmMessagePageVM），跨端修改需两端同步回归。
• 反馈 257132 的日志直证（供后续「连不上监控」类对照）：设备 16613534（a13994794854，SN 0A07EADFCD4B3022）服务端 devIsOnline:0、lastHeartTime=1789525760000（2026-09-16 10:29:20，滞后 27 天）、p2pLastHeartTime=1789524979000（2026-09-16 10:16:19），全窗口 TPS_MSG_P2P_OFFLINE 117 次、add_watch_result=-1 23 次。属设备真离线，已排除，不计入雷达。

方法学记录：本期 Logan 下载继续使用反馈服务内置鉴权（app-logan.seetong.com 需 Authorization: Basic，与 seetong_feedback_server.py 的 _download_and_parse_log 保持一致）——这是「同一 URL 取不到日志」这一常见误判的正解。未使用 Authorization: Bearer（会返回 401）。

待补证

• 问题 1 的第二独立样本（最高优先）：本期仅 257145 一条含完整「离线推送 → 回放页」链路。需在 Android 8.4.1.6 上复现「从离线报警推送进入卡回放、首次点开失败」，并抓取至少 2 份独立用户 Logan，确认 receive playback play failed event 是否为共性而非个例。
• 问题 1 的 openCardPlaybackEvent 触发源：两次失败事件的 result 均为 0（非错误码），需确认该事件是否被 EventBus.postSticky / RECORD_DESTROY_EVENT（KMPPlayBackVideoView.kt:264-268）复用误触发；这是判断「竞态」还是「事件污染」的关键。
• 问题 1 的 viewId 写序：需确认 device.m_view_id 在 :238（置 29）→ :256（置 -1）→ 首帧回调仍为 29 的三次写入中，churn 由哪个线程驱动、是否有锁保护。
• 问题 1 的 alarmType=268435455 (0xfffffff)：该「不限类型」值在 IPC（devType:101，非枪球）设备上是否应裁剪为具体事件类型，需协议 owner 确认。
• 问题 2 的覆盖操作时段 Logan（关键缺口）：257122 / 257123 均为跨日稀疏采样，不含「查看报警消息」操作时段的页面级记录。需回访 13503751999（河南）索取完整日志，或在 8.4.1.6 上补采。
• 问题 2 的卡顿量级：需在 10 通道 NVR（devChannelStates:"1111111022" 形态）上实测 loadInitialData 端到端耗时与主线程帧间隔，确认「卡顿」是否落在消息页而非其它页面。
• 问题 2 的 skipCachedInitialUiState=true 来源：需确认该开关是否为 8.4.1.6 新引入（若是，则与用户「更新版本以后」的时间描述吻合）。
• 257116（iOS 8.4.1.6，「报警里面的视频都看不了」）：Logan 仅覆盖 2026-10-13 22:39 的冷启动与长连接建立，不含报警视频播放操作（全量检索 alarm / 报警 / 播放 / 录像 零命中）。需回访 17861020652（山东）补采；若再现即进雷达。
• 257141（Android 8.4.1.6，「回放不可以看了」）：Logan 覆盖 06:08:23 ~ 06:11:15，全程未进入回放页（KMP_SCAN_TRACE 无 PlayBackPage，仅 PlayerPreviewActivity → SystemSetPage → ImprovePage → FeedbackPage）。用户实为在设备预览中看到三路画面后转去提交反馈，需下一期拆分「预览态」与「回放态」诉求。
• 257151（Android 8.4.1.6，HONOR LYN-AN00，「视频有时候录不上」）：Logan 已取得（328 KB 级，窗口 08:21:36 前后），本期时间预算已用于问题 1 / 2，未深挖；下期若再现即进雷达。
• 257121（Android 8.4.1.6，「只能存储一天录像」）：属存储容量与录制策略口径（非播放链路），本期未取 Logan；若多期再现需转 seetong-feedback-triage。
• HarmonyOS Logan 缺口（连续 10 期阻塞根因，最高优先）：本窗口 0/16 条提供链接（对照 Android 77/88、iOS 3/3）。建议持续固定披露该比值以量化缺口；同时优先回访 257110（天津，SGT-AL50，「断电也不管事了」）。
• 神策事件名确认（连续 3 期未完成）：需先用 list_event_schemas 确认真实的「首帧时延 / 预览会话 / 回放 / 报警消息」事件名，再补 7 天趋势；本期按 skill 规则降级，未重试。

任务账本

说明：问题 1（startReplay 竞态）与 T-20261013-090000-a1b2（首帧迟至 105 秒）同属 Android 播放链路但根因不同（失败事件竞态 vs 取流空转），按 skill 规则独立建单，未合并。问题 3 的 257110 与 T-20260926-115214-fdf9（已联网却显示离线）同族但形态不同（断电不恢复 vs 在线态误显），亦独立建单。

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