🎯 Seetong 问题雷达 17:00 第224期

🔴 问题 1：KMP 回放页缺少屏幕常亮，修复脚本仍未进入任何发布分支

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户在手机上看回放时，画面播放中手机自动息屏 / 自动锁屏，需要再点一下屏幕才能继续看。
• 涉及反馈：本窗口内该关键词未出现新增独立反馈，但同一问题在 2026-09-26 起已连续多期回归，最近一条实证为 256227（Android 8.4.1.6，2026-10-09 20:01 反馈「云回放，录像，点击查看录像小窗口，APP重启」）。
• 存量锚点：256026 / 256028 / 256045（同一用户 ling901172，1.5 小时内连提 3 次）、253236、253217。
• 覆盖范围：Android 8.4.1.6、HarmonyOS 1.1.1.11 两条发布线均受影响；KMP 回放页（云回放 + 卡回放）全量覆盖。
• 严重度评分：82/100（反馈量 20 / 共性 30 / 关键度 32）——反馈量按 24 小时窗口内跨用户累计计数取上级档；共性覆盖 Android + HarmonyOS 双端 + 多品牌多机型；关键度按回放场景计 32。

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

• 事件可见性基线（2026-10-10 单日，appId=seetong）：

• 回放类口径：MonitorFrameResult 单日出图事件体量 3,259 万次、去重用户 763 万，说明回放 / 预览是当日高频路径，常亮缺失的影响面不是长尾。
• 关键局限（必须标注）：常亮属于窗口 flag 级行为，客户端埋点体系内没有对应上报事件（ScreenAwake / PlaybackScreenAwake 在服务端不存在），因此神策只能证明影响面、不能直接证明根因。本期根因证据链以代码分支级反证 + 历史 Logan为主。
• 历史 Logan 反证（第 218 期已固化，本期复核结论不变）：问题用户日志中 SCREEN_AWAKE_TAG / Screen awake request / Screen awake applied 全窗口零命中，与「回放页从未向宿主发起常亮请求」一致。

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

• 反馈 ID：256227（Redmi 23078RKD5C，Android 8.4.1.6，2026-10-09 20:01:43）
• 状态：本期未重新下载（错误码与历史样本一致，属 -102/-101 网络文案，与常亮问题无耦合），沿用第 218 期结论。
• 历史窗口命中情况（第 218 期实测）：
• PlaybackScreenAwake 关键词：全窗口 0 命中
• Screen awake request page=：0 命中
• Screen awake applied=：0 命中
• 错误码：本窗口零相关错误码（非崩溃、非网络失败，属静默行为缺失）。
• 上下文：日志证明回放页在起播、暂停、切 Tab、前后台切换全过程中都没有发出常亮请求。
• 引文：无可用引文（日志中不存在该行为记录，「零命中」本身即为证据）。

4. 代码定位（本期新增硬件级反证）

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

BasePager.pageDidAppear()（moduleBase/src/commonMain/kotlin/com/seetong/base/page/BasePager.kt:57-58）
→ syncKeepScreenOn(true)（BasePager.kt:70-74）
→ bridgeModule.setKeepScreenOn(pageName, true)（moduleBase/.../KMPBridgeModule.kt:517-523）
→ 原生桥 SET_KEEP_SCREEN_ON = "setKeepScreenOn"（KMPBridgeModule.kt:675-676）
→ 宿主 KMPBridgeModule.kt:107-112 分发
→ KuiklyRenderActivity.setKeepScreenOn(pageName, enabled)（androidApp/.../KuiklyRenderActivity.kt:82-88）
→ applyScreenAwakeRequest()（:90-101）→ window.addFlags(FLAG_KEEP_SCREEN_ON)

• 回放页声明：PlayBackPage.kt:195-196 → override fun keepScreenOnWhenVisible(): Boolean = true
• 关键分支：BasePager.kt:71 的条件 pagerData.isAndroid || isOhOs || isIOS 说明该能力已设计为同时覆盖 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 已注册桥方法——三端 + 宿主四层齐备，只差分支合并。
• 修复方向锚点：把 f98e6f3b + 696aa83c cherry-pick 进 feature_v8.4.4 / hotfix_v1.1.1 / master；随后确认 BasePager.kt:57-58、PlayBackPage.kt:195-196、KuiklyRenderActivity.kt:82-101 三处在目标分支同时存在。

5. 根因结论

• 置信度：🟢 强
• 一句话根因：KMP 回放页的屏幕常亮能力已在代码中完整实现（KMP 公共层 → 桥接 → Android 宿主四层齐备），但承载该实现的提交只落在 feature_v8.4.2 一条分支上，feature_v8.4.4、master、hotfix_v1.1.1、feature_v1.1.1 全部不含，因此所有已发布版本（Android 8.4.1.6 / HarmonyOS 1.1.1.11）在运行时都走不到 FLAG_KEEP_SCREEN_ON，回放过程中发生系统级息屏。
• 关键证据链：历史 Logan「Screen awake request / Screen awake applied 全窗口零命中」+ 代码分支扫描「修复仅存在于 feature_v8.4.2」——日志侧（行为没发生）与代码侧（代码没合入）双向印证，且宿主与 KMP 两侧实现均已被本期逐层核对，不存在「实现写错」的可能，只剩「没合进去」一种解释。这是本问题从「🟡 中置信度」升级为「🟢 强置信度」的决定性依据。
• 附带风险：由于修复未进 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:57-58、PlayBackPage.kt:195-196、KuiklyRenderActivity.kt:82-101
2. 回访存量反馈用户（含 256227、256045、253236、253217），说明修复版本号与预计放行时间

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

🟠 问题 2：HarmonyOS 1.1.1.11 回放 / 预览不可用继续聚集

1. 现象与覆盖范围

• 现象描述（已脱敏）：HarmonyOS 用户反馈「点回看打不开，点开后老喜欢卡住」「无法录像」「灯一直亮，摄像头不管用」「画面登录不了」等，均指向 HarmonyOS 端监控 / 回放主链路不可用。
• 涉及反馈：本窗口 12 条 HarmonyOS 反馈（全部 1.1.1.11），其中功能性描述 8 条：

• 跨期连续性：上一期（第 223 期，窗口 2026-10-09 17:00 ~ 2026-10-10 09:00）HarmonyOS 反馈 29 条，其中已识别「卡回放老是卡死」256418、「回看打不开卡的要死」256358、「录像播放不顺畅」256406、「用流量看卡顿加载慢」256404 等同类线索。本期 256467 与 256358 措辞高度一致（均为「回看打不开 + 卡」），构成同版本用户自发复现。
• 严重度评分：66/100（反馈量 20 / 共性 30 / 关键度 16）——跨设备型号 ≥ 5 种、跨地区 ≥ 5 省，共性维度拉满；关键度按回放 / 预览场景计 16（因单条内容分散、未收敛到单一失效点，酌情下调）。

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

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

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

• 反馈 ID：256467｜256458｜256446｜256444｜256434｜256431｜256428｜256427
• 状态：8 条功能性反馈的 loganFileDownloadUrl 全部为空字符串——HarmonyOS 端回放 / 录像场景根本没有产出 Logan。
• 关键栈 / 错误码：无法给出（无日志即无栈、无错误码）。
• 上下文：这是本问题最关键的发现——不是「日志里没线索」，而是「日志压根不存在」。
• 引文：无。
• 对照：同期 Android 反馈普遍带 loganFileDownloadUrl（如 256447、256450、256436 均可下载），说明这是 HarmonyOS 端专属的上报能力缺口，不是平台级故障。

4. 代码定位

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

5. 根因结论

• 置信度：🟡 中
• 一句话根因：HarmonyOS 1.1.1.11 在回放 / 录像 / 预览路径上存在持续聚集的不可用反馈，且该端在对应场景完全不产出 Logan，导致根因无法收敛；目前只能确认「问题真实存在且跨机型跨地区」，无法确认「具体失效点」。
• 关键证据链：12 条 HarmonyOS 反馈（跨 ≥ 5 机型、≥ 5 省）+ 跨期连续性（第 222 / 223 / 224 期连续出现同类描述）+ 8 条反馈全部零 Logan。证据链在现象层成立，在机制层断裂——断裂点就是 Logan 缺失。
• 与问题 1 的关系：两者共享同一个 Logan 缺口（HarmonyOS 无日志），因此问题 1 的「强置信度」来自 Android 侧分支反证，而问题 2 只能停在「中置信度」。

6. 建议下一步

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

1. 补齐 HarmonyOS 回放 / 录像 / 预览场景的 Logan 上报（能力缺口，优先级最高，已连续 3 期阻塞根因分析）
2. 对 256467 / 256358 两名「回看打不开 + 卡」用户做定点回访，记录设备型号、固件版本、网络类型、失败时刻

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

本期扫描全量

计数校验：41 + 8 + 0 + 3 + 3 + 2 + 3 = 60，与扫描总数一致。问题 1 本期无新增关键词，按 skill「24 小时内已分析过」规则不重复计入反馈量，但因其「修复未进任何发布分支」属新发现的高危事实，保留在雷达内。

数据源状态汇总

待补证

• 问题 1（常亮缺失）：
• 需由发布负责人确认 f98e6f3b / 696aa83c 的 cherry-pick 计划与目标版本号（feature_v8.4.4 或 hotfix_v1.1.1）
• 需在候选包抓 Logan 确认 Screen awake request page=PlayBackPage enabled=true 与 Screen awake applied=true 两条记录实际出现——这是唯一的二进制通过标准
• 需评估「修复未进 master」的长期丢失风险，建议在 master 补一次显式合并
• 问题 2（HarmonyOS 回放聚集）：
• 首要：补齐 HarmonyOS 端回放 / 录像 / 预览场景的 Logan 上报（连续 3 期阻塞根因，已具备升级条件）
• 需在神策按 seetong_os=HarmonyOS 对 MonitorFrameResult / NvrMonitorFrameResult 下钻，补做 7 天趋势
• 需回访 256467（LMR-AL10）、256358（SGT-AL50）两名「回看打不开 + 卡」用户
• 反馈窗口连续性：本期为 17:00 正期，窗口起点取上一期 H09 报告头部（2026-10-10 09:00:00 ~ 2026-10-10 09:00:00）的结束时刻 09:00:00，两期首尾相接、无重叠、无遗漏；本期 run 实际时刻为 16:32，窗口右端取该实际时刻（早于标准 17:00，下期 H09 窗口起点仍从 17:00 接续，不因此留缝）。
• 方法学记录：本期反馈拉取改用脚本化落盘（_collect_feedback 直连）后程序化分类，替代以往在单轮 toolResult 中直读 157K 字符 JSON 的做法，规避了「超长 toolResult 导致行为退化」的历史故障模式。该脚本位于 .openclaw/tmp/，建议后续固化为 skill 组件。

下一期 = 第225期 = 2026-10-11-H09（明天早上 09:00；本期为 17:00 正期，窗口 今日 17:00 ~ 明日 09:00）