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

🔴 问题 1：KMP 回放页未申请屏幕常亮，回放中手机自动息屏（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户进入 KMP 回放页观看录像时，手机在系统息屏超时到达后自动黑屏锁屏，回放中断，需重新点亮屏幕才能继续看。本窗口用户原话为「手机回放会自动锁屏」。
• 涉及反馈：本窗口新增 3 条独立反馈、2 名用户、2 个机型：

• 跨期连续性：该问题自 2026-09-26 起已连续多期回归，存量锚点包括 256026 / 256028 / 256045（同一用户 ling901172，1.5 小时内连提 3 次）、253236、253217、256227。256526 / 256527 与存量锚点为同一用户（ling901172），显示该用户在手环期内已累计 5 次反馈而无任何变化。
• 覆盖范围：Android 8.4.1.6 与 HarmonyOS 1.1.1.11 两条发布线均受影响；KMP 回放页（云回放 + 卡回放）全量覆盖。
• 严重度评分：84/100（反馈量 20 / 共性 30 / 关键度 34）——反馈量按 24 小时窗口内跨用户累计计数；共性覆盖双端 + 多品牌多机型；关键度按回放主链路计 34。较第 224 期（82）上调 2 分，原因是本期首次取得带 Logan 的现场样本，证据等级提升。

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

• 事件可见性基线（沿用第 224 期口径，2026-10-10 单日，appId=seetong）：

• 结论：回放 / 预览是当日高频路径（单日出图事件 3,259 万次、去重用户 763 万），常亮缺失的影响面不是长尾。
• 关键局限（必须标注）：常亮属于 window flag 级行为，客户端埋点体系内没有对应上报事件（ScreenAwake / PlaybackScreenAwake 在服务端不存在），因此神策只能证明影响面、不能直接证明根因。本期根因证据链以 Logan 行为侧反证 + 代码分支级反证 为主。

3. Logan 关键日志（核心数据源，本期首次取得现场样本）

• 反馈 ID：256526（vivo V2551A）｜256530（vivo V2162A）
• 日志体量：256526 = 160,172 bytes / 7,076 行；256530 = 106,693 bytes / 4,846 行；均成功下载并解析（下载接口返回的 Error stats 分别为 {'‑102': 2, '‑101': 2, 'EXCEPTION': 99} 与 {'‑102': 8, 'ssl_connect': 2, 'EXCEPTION': 136}，属背景噪声，非本问题相关）。
• 关键词命中情况（本问题的核心证据）：

• 关键调用链时序（256526，vivo V2551A，与「自动锁屏」投诉时间吻合）：
• 19:33:49.170 KMP_SCAN_TRACE-onCreate page=PlayBackPage（进入回放页，devId=30767794，设备名「大门」）
• 19:33:57.726 PlayBackPage:mark card playback first frame, devId=30767794（首帧出图）
• 19:33:58.959 track playback event elementId=playback_card_fullscreen → playback_card_enter_fullscreen（用户切全屏观看）
• 19:34:27~19:35:16 applyZoomToTimeline / currentTimeText source=fullscreen 密集输出（用户在全屏内持续操作时间轴，共约 78 秒连续观看）
• 19:35:24.038 KRPerformanceManager---onPause-- 且 onResume 在同窗口内零命中 → 页面被切到后台 / 屏幕关闭
• 19:35:24.042 PlayBackPage:stop card playback and frame watch, devId=30767794, controlState=PLAYING, isPlaying=true
• 全窗口（19:33:49 ~ 19:35:24，共 95 秒）内 Screen awake request 零命中——即回放页在整个前台可见期内从未向宿主发起过常亮请求。
• 关键调用链时序（256530，vivo V2162A，跨 10 小时双 session，首帧密集重试）：
• session A：10:24:47.504 onCreate → 首帧 10:24:53.608 / 10:25:01.960 / 10:25:07.093（6 秒内 3 次首帧标记，取流反复重试）→ 10:25:11.664 onPause（4.5 秒后离屏）
• session B：20:06:18.288 onCreate → 首帧 20:06:24.969 / 20:06:45.262（间隔 20 秒再次首帧）→ 20:06:55.301 首帧 → 20:06:55.414 onPause → 20:06:55.833 onDestroy → 20:06:55.846 resetCloudPlayerState
• 同样：全窗口 Screen awake request 零命中。
• 附：日志中存在 EXCEPTION 15559 --- LibImpl-onNvrReplayResp TPS_ReplayDevFileRsp is invalid，属 NVR 回放响应异常，与常亮无因果关系，但与用户「更新后看回放录像太卡了 画质太差了」的描述方向一致，登记为关联信号。
• 方法学说明（必须标注）：Logan 是环形缓冲区快照，本次快照未保存到 logout 记录，因此不能用「日志内无 Screen off 记录」反证屏幕没熄；本问题的 Logan 证据是「行为侧从未发起常亮请求」这一存在性缺失，而非「记录了屏幕熄灭事件」。该限定已在第 218 期固化，本期结论不变。
• 引文（256526 最后 3 条，展示回放被中断的现场）：

> [L6272] 2026-10-10 19:35:16.896 PlayBackPage:exitFullScreen, cachedCenterTimeSec=68382, currentTimeText=18:59:42
> [L6277] 2026-10-10 19:35:24.038 KRPerformanceManager---onPause--
> [L6278] 2026-10-10 19:35:24.042 PlayBackPage:stop card playback and frame watch, devId=30767794, controlState=PLAYING, isPlaying=true

4. 代码定位（本期复核，分支级反证结论不变）

• 涉及仓库：~/seetong-kmp（跨端 KMP 公共层）+ ~/Seetong-App-Android（Android 宿主）
• 完整调用链（已完成、自洽）：

BasePager.pageDidAppear()（~/seetong-kmp/moduleBase/src/commonMain/kotlin/com/seetong/base/page/BasePager.kt:55-59）
→ syncKeepScreenOn(true)（BasePager.kt:69-75）
→ bridgeModule.setKeepScreenOn(pageName, enabled)（BasePager.kt:72）
→ LogUtils.d("Screen awake request page=$pageName enabled=$enabled", SCREEN_AWAKE_TAG)（BasePager.kt:73）
→ 原生桥 SET_KEEP_SCREEN_ON = "setKeepScreenOn"（moduleBase/.../KMPBridgeModule.kt:675-676）
→ 宿主分发（~/Seetong-App-Android/.../kmp/src/main/java/com/seetong/kuikly/KMPBridgeModule.kt:107-112）
→ KuiklyRenderActivity.setKeepScreenOn(pageName, enabled)（.../KuiklyRenderActivity.kt:82-88）
→ applyScreenAwakeRequest()（:90-101）→ window.addFlags(FLAG_KEEP_SCREEN_ON)

• 回放页声明：modulePlayback/src/commonMain/kotlin/com/seetong/moduleplayback/page/playback/PlayBackPage.kt:196 → override fun keepScreenOnWhenVisible(): Boolean = true
• 关键分支：BasePager.kt:71 的条件 (!pagerData.isAndroid && !pagerData.isOhOs && !pagerData.isIOS) return 说明该能力已设计为同时覆盖 Android / HarmonyOS / iOS 三端，不存在端侧遗漏。
• 本期独立复核（分支级反证，逐条实测）：

• 提交时间：f98e6f3b 屏幕常亮抽象到 BasePage（2026-09-24 14:45）、696aa83c KMP 支持页面支持常亮（2026-09-24 16:05）。
• 宿主侧同源确认：~/Seetong-App-Android/Seetong5.0ForSeetong/Seetong5.0/kmp/src/main/java/com/seetong/kuikly/KuiklyRenderActivity.kt:82-101 已有实现，KMPBridgeModule.kt:107-112 已注册桥方法——KMP 公共层 + 桥接层 + Android 宿主层齐备，只差分支合并。
• 修复方向锚点：把 f98e6f3b + 696aa83c cherry-pick 进 feature_v8.4.4 / hotfix_v1.1.1 / master；随后确认 BasePager.kt:55-75、PlayBackPage.kt:196、KuiklyRenderActivity.kt:82-101 三处在目标分支同时存在。

5. 根因结论

• 置信度：🟢 强
• 一句话根因：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，回放过程中发生系统级息屏。
• 关键证据链（本期由双向改为三向印证）：

1. 行为侧（本期新增）：256526 / 256530 两份现场 Logan在 PlayBackPage 全程可见期内 Screen awake request / SCREEN_AWAKE_TAG 零命中——回放页从未发出常亮请求；
2. 代码侧：5 支分支逐一实测，f98e6f3b / 696aa83c 仅存在于 feature_v8.4.2；
3. 历史侧：第 218 期 Logan 结论（PlaybackScreenAwake 全窗口零命中）与本期完全一致。

——行为没发生 + 代码没合入 + 历史可复现，三向一致，不存在「实现写错」的解释，只剩「没合进去」一种。

• 附带风险：由于修复未进 master，后续任何从 master 新拉的分支都不会自动继承该修复，存在长期丢失风险，必须显式 cherry-pick。

6. 建议下一步

• 分配给：KMP 框架负责人（BasePager / KMPBridgeModule 归属方）+ Android 宿主负责人 + HarmonyOS 1.1.1.1x 维护人
• 优先处理项：

1. 立即将 f98e6f3b、696aa83c cherry-pick 进 feature_v8.4.4、hotfix_v1.1.1、master，并确认三支均已包含 BasePager.kt:55-75、PlayBackPage.kt:196、KuiklyRenderActivity.kt:82-101
2. 回访存量反馈用户（含 256526 / 256527 / 256530、256227、256045、253236、253217），说明修复版本号与预计放行时间

• 验证方法：候选包真机连续回放 ≥ 10 分钟（覆盖云回放 / 卡回放、竖横屏、全屏进出、切 Tab、前后台切换），确认全程不熄屏；同时抓 Logan 确认出现 Screen awake request page=PlayBackPage enabled=true 记录——以日志出现为准，不以肉眼观感为准（该条即本问题的二进制通过标准）。

🟠 问题 2：HarmonyOS 1.1.1.11 回放 / 监控链路不可用连续第 4 期聚集（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：HarmonyOS 1.1.1.11 用户在观看监控 / 回放 / 录像环节集中受挫，措辞涵盖「无法查看监控」「看不到回放」「视频不能回放」「无法删除视频」。
• 涉及反馈：本窗口 HarmonyOS 反馈共 21 条（全部 1.1.1.11），其中功能性描述 7 条独立反馈：

• 其余 14 条 HarmonyOS 反馈为无效文本（256508–256512「家」×5、256581「款」）、单点驾驶舱类（256595 电池不行、256592 设备在线、256578 客服催问、256553 分享咨询、256574/256575 固件升级后无声、256514 返回主页、256490「.」），不并入本问题共性计数。
• 跨期连续性：本期为连续第 4 期（第 222 / 223 / 224 / 225 期）出现同类聚集；第 223 期 7 条、第 224 期 8 条、本期 7 条，量级稳定，已满足第 224 期设定的「累计达 4 期即升级专项排查」触发条件。
• 严重度评分：68/100（反馈量 20 / 共性 30 / 关键度 18）——跨 5 机型、跨 5 地区，共性维度拉满；关键度按回放 / 预览场景计 18（因单条内容分散、未收敛到单一失效点，酌情下调）。较第 224 期（66）上调 2 分，原因是连续期数达到升级阈值。

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

• 本期未按 HarmonyOS 维度下钻。限制说明：seetong_os 维度下钻需在 MonitorFrameResult / NvrMonitorFrameResult 上分组，本期受样例时间与 token 预算约束未展开；NvrMonitorFrameResult 历史样本量偏小（第 223 期记录当日仅 60 人），样本不足以做 HarmonyOS 回放首帧耗时归因。
• 结论：神策在本问题中仅作为影响面参照，不作为根因证据。

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

• 反馈 ID：256599｜256572｜256571｜256561｜256560｜256555｜256567
• 状态：7 条功能性反馈的 loganFileDownloadUrl 全部为空字符串；本窗口 21 条 HarmonyOS 反馈无一带 Logan。
• 关键栈 / 错误码：无法给出（无日志即无栈、无错误码）。
• 上下文：这是本问题最关键的发现——不是「日志里没线索」，而是「日志压根不存在」。本期首次可量化：HarmonyOS 端 21/21 条反馈零 Logan，为跨平台中唯一全量缺失的端。
• 引文：无。
• 对照：同期 Android 反馈普遍带 loganFileDownloadUrl（本窗口 256526 / 256527 / 256530 / 256557 / 256566 等均可下载），说明这是 HarmonyOS 端专属的上报能力缺口，不是平台级故障。

4. 代码定位

• 涉及仓库：~/seetong-kmp（HarmonyOS 复用 KMP 公共层）+ HarmonyOS 宿主
• 已确认：BasePager.kt:71 的常亮判定显式包含 pagerData.isOhOs，说明 KMP 公共层的常亮能力设计上已覆盖 HarmonyOS；但 hotfix_v1.1.1 分支既不含 f98e6f3b / 696aa83c，也不含 syncKeepScreenOn（本期实测 0 处）。
• 回放主链路：本期仍未完成定位。原因：标准路径下 HarmonyOS 宿主仓库与 KMP 回放页的失败分支未被日志指向，缺少入口证据，无法在不猜的前提下给出类名与行号。
• 说明：已搜路径包括 ~/seetong-kmp/modulePlayback、~/seetong-kmp/moduleBase、~/seetong-app-harmony；未找到可锚定的失败分支，故标注「代码待定位」，不阻塞报告。
• 修复方向锚点：优先补 Logan 上报（先有证据，再谈定位），其次核对 PlayBackPage 与 HarmonyOS 宿主在回放 Tab 切换、录像起止控制、删除视频流程上的桥接返回值。

5. 根因结论

• 置信度：🟡 中
• 一句话根因：HarmonyOS 1.1.1.11 在回放 / 录像 / 预览 / 删除视频路径上存在连续 4 期持续聚集的不可用反馈，且该端在对应场景完全不产出 Logan，导致根因无法收敛；目前只能确认「问题真实存在且跨机型跨地区」，无法确认「具体失效点」。
• 关键证据链：7 条功能性 HarmonyOS 反馈（跨 5 机型、5 地区）+ 跨期连续性（第 222 / 223 / 224 / 225 期连续同类描述）+ 21 条反馈全部零 Logan。证据链在现象层成立，在机制层断裂——断裂点就是 Logan 缺失。
• 与问题 1 的关系：两者共享同一个 Logan 缺口（HarmonyOS 无日志），因此问题 1 的「强置信度」来自 Android 侧 Logan + 分支三重反证，而问题 2 只能停在「中置信度」。
• 升级建议：连续 4 期已达阈值，建议由雷达常规项升级为专项排查，指定负责人并设定明确的补 Logan 交付时间点。

6. 建议下一步

• 分配给：HarmonyOS 端负责人 + KMP 公共层 Logan 归属方
• 优先处理项：

1. 补齐 HarmonyOS 回放 / 录像 / 预览 / 删除视频场景的 Logan 上报（能力缺口，优先级最高，已连续 4 期阻塞根因分析）
2. 对 256599、256571 / 256572、256555 四名用户做定点回访，记录设备型号、固件版本、网络类型、失败时刻
3. 启动专项排查立项，明确 owner 与交付时间点

• 验证方法：修复包在 HarmonyOS 真机走「进入回放 → 切换 Tab → 拖动时间轴 → 删除视频 → 退出」全路径，确认 Logan 目录产出对应日志文件；随后按 devId 串联首帧回调与失败码。
• 升级条件：已满足（累计 4 期）。若下一期继续聚集，按专项流程处理并不再计入雷达常规项。

本期扫描全量

计数校验：72 + 7 + 3 + 18 + 4 + 6 + 5 + 3 = 118。其中 3 条（256526 / 256527 / 256530）同时命中「回放」与「画质/性能」语义，为去重前的语义归类重叠，去重后独立反馈为 115 条，与接口 fetched=115 一致。问题 1 属存量回归（24 小时内已分析过），按 skill「重复问题」规则不重复计入反馈量，但因其「首次取得现场 Logan 样本」属新证据，保留在雷达内详细分析。

数据源状态汇总

待补证

• 问题 1（常亮缺失）：
• 需由发布负责人确认 f98e6f3b / 696aa83c 的 cherry-pick 计划与目标版本号（feature_v8.4.4 或 hotfix_v1.1.1）
• 需在候选包抓 Logan 确认 Screen awake request page=PlayBackPage enabled=true 记录实际出现——这是唯一的二进制通过标准
• 需评估「修复未进 master」的长期丢失风险，建议在 master 补一次显式合并
• 本期新增限定：Logan 为环形缓冲区快照、未保存到 logout 记录，因此本次证据为「行为侧从未发起常亮请求」的存在性缺失，不能用日志反证「屏幕确实熄灭」；后续建议在 Logan 中增加屏幕状态变更的显式埋点，使证据可正可反
• 问题 2（HarmonyOS 回放聚集）：
• 首要：补齐 HarmonyOS 端回放 / 录像 / 预览 / 删除视频场景的 Logan 上报（连续 4 期阻塞根因，已达升级阈值）
• 需在神策按 seetong_os=HarmonyOS 对 MonitorFrameResult / NvrMonitorFrameResult 下钻，补做 7 天趋势
• 需回访 256599（ALN-AL10）、256571 / 256572（SCA-AL00）、256555（HED-AL00）四名用户
• 需专项立项，明确 owner 与交付时间点
• 登记待补证（不进详细分析）：
• 256563（iOS 8.4.1.6，iPhone 18.7.8）「查看软件相册中以往截取的图片或者视频时总是黑屏闪退，软件自动更新后频频出现」——iOS 新平台、新线索，无 Logan，下期若再出现即进雷达
• 256574 / 256575（HarmonyOS ALN-AL00）「摄像头固件升级后没有声音了，未升级的摄像头还有声音」——用户已自行完成对照实验，指向固件侧，建议转 Server / 固件组
• 256555 / 256567 与问题 2 同端，已并入共性计数
• 反馈窗口连续性：本期为 09:00 正期，窗口起点取上一期 H17 报告头部「时间窗口」行右端的 2026-10-10 17:00:00（该期 run 实际时刻 16:32 早于标准 17:00，本期按标准整点 17:00 接续，不因此留缝、不重叠），终点 = 本期 run 实际时刻 2026-10-11 09:00:00；两期首尾相接，拼合覆盖 2026-10-10 17:00 ~ 2026-10-11 09:00 完整 16 小时（含整夜）。
• 方法学记录：本期沿用脚本化落盘（_collect_feedback 直连 → JSON 落盘 → 程序化分类）替代在单轮 toolResult 中直读大 JSON，规避「超长 toolResult 导致行为退化」的历史故障模式。本期首次实现 Logan 的程序化关键词零命中校验（awake 全词形 0 命中为可复算的二进制事实），使「零命中」从主观判断变为可验证断言。

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