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

🔴 问题 1：Android 8.4.1.6 KMP 回放页观看录像时不申请屏幕常亮，系统按设定时长自动息屏（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户进入卡回放 / 回放观看录像后，手机在系统息屏超时到达时自动黑屏锁屏，录像被中断；用户明确表述「以前不会息屏」，属回归型体验劣化，非网络类问题。
• 涉及反馈：本窗口新增 3 条独立反馈（跨 3 品牌、3 机型、3 地区）
• 256162｜OPPO PKV110｜Android 8.4.1.6｜中国安徽省阜阳市界首市｜2026-10-09 00:25:05｜「查看回放的时候会息屏，以前不会息屏。」
• 256135｜HONOR ALA-AN70｜Android 8.4.1.6｜中国贵州省毕节市金沙县｜2026-10-08 20:19:48｜「请问为什么在手机上看回放视频和报警视频时才看到几秒钟，手机就自动黑屏锁屏了？」
• 256128｜vivo V2551A｜Android 8.4.1.6｜中国广东省广州市｜2026-10-08 19:51:10｜「手机回放，会自动息屏」
• 延续样本（本窗口外、今日已分析）：同用户 ling901172 于 2026-10-08 10:21～19:51 累计 4 次提交（256026 / 256028 / 256045 / 256128），措辞由「锁屏」改「息屏」，见第 216～220 期
• 设备跨度：本窗口 3 机型（OPPO PKV110 / HONOR ALA-AN70 / vivo V2551A）+ 今日累计 ≥5 机型（另含 vivo V2531A / V2551A）；地区 ≥4（安徽阜阳 / 贵州毕节 / 广东广州 / 山东滨州）
• 严重度评分：78/100（反馈量 30 / 共性 30 / 业务关键度 40 —— 回放属录像查看核心能力，且为「跨品牌 + 跨地区 + 跨多用户」的强共性回归）
• 去重判定：同关键词在 24h 内已分析过（第 218 / 220 期）→ 沿用任务，不重复创单，但本窗口新增 3 条独立反馈、且代码核对升级为「分支级确认」，故本期仍进雷达并升级严重度

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

• 大盘量级（DeviceVideoPlayback，2026-10-02 ~ 2026-10-09 累计）：total_count = 150,746,957、unique_users = 11,408,943 —— 主链路量级正常，非系统性崩溃，本问题属客户端窗口标志位类缺陷。
• 该问题神策无直接埋点（屏幕常亮是宿主 WindowManager 标志位，未落埋点），证据链以 Logan + 代码 为主。
• 本窗口未对同事件同窗口重复查询，避免与第 218 / 220 期重复消耗。

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

• 反馈 ID：256162（OPPO PKV110）｜日志 seetong_1da0762c-…，28,589 字节，1,319 行；关键词已覆盖 PlaybackScreenAwake / setKeepScreenOn / Screen awake / onPause / onStop / keyguard / LoseFocus
• 反馈 ID：256128（vivo V2551A，用户 ling901172）｜日志 seetong_6f882ff9-…，110,353 字节，6,172 行
• 关键发现（回放链路全窗口零常亮请求）：
• 两份 Logan 全窗口均未命中 PlaybackScreenAwake / Screen awake requested= / Screen awake applied= 任一字符串 —— 回放页从未向宿主申请屏幕常亮
• 256162 日志尾段仅见页面生命周期与反馈页跳转：KRPerformanceManager---onPause-- → KMP_SCAN_TRACE-onCreate page=ImprovePage → KMP_SCAN_TRACE-onCreate page=FeedbackPage，无任何常亮申请记录
• 错误统计（256162）：{'-102': 1, '-101': 1, 'EXCEPTION': 3} —— 无崩溃栈，EXCEPTION 行为 clogan header / 状态打印类，与常亮缺陷无关
• 与历史样本形态完全一致：第 218 期（256091）、第 220 期（256103）与本窗口 3 条，共 4 份独立 Logan 均为「零常亮日志」同一形态

4. 代码定位（详细，本期新增分支级确认）

• 涉及仓库：seetong-kmp（moduleBase / modulePlayback）+ Seetong-App-Android（宿主）
• 关键事实 1：机制本身已实现且完整（仅存在于 feature_v8.4.2）
• moduleBase/src/commonMain/kotlin/com/seetong/base/page/BasePager.kt:58 → pageDidAppear() 调 syncKeepScreenOn(true)
• 同文件 :62 → pageDidDisappear() 调 syncKeepScreenOn(false)；:221 → 销毁时再释放
• 同文件 :67 → protected open fun keepScreenOnWhenVisible(): Boolean = false（默认关，需页面覆写）
• 同文件 :70-73 → syncKeepScreenOn() 经 bridgeModule.setKeepScreenOn(pageName, enabled) 下发，仅对 Android / HarmonyOS / iOS 生效，并打印 Screen awake request page=… enabled=…
• modulePlayback/.../PlayBackPage.kt:196 → override fun keepScreenOnWhenVisible(): Boolean = true ✅ 回放页已正确覆写
• 宿主侧：Seetong-App-Android/.../KuiklyRenderActivity.kt:58 setKeepScreenOn() → :63 applyScreenAwakeRequest() 应用 FLAG_KEEP_SCREEN_ON；:511 SCREEN_AWAKE_TAG = "PlaybackScreenAwake"
• 桥接：…/modules/KMPBridgeModule.kt → "setKeepScreenOn" 分支已注册并转发 Activity
• 关键事实 2：该能力只在 feature_v8.4.2，8.4.1 发布线完全不含（本期分支级实证）
• 修复提交：e840dc3b6「修复 KMP 回放页观看录像时未申请屏幕常亮的问题」（BUG 单号 1015747，提交人 chenbaowang，2026-09-24 14:55）
• 同源提交：f98e6f3b「屏幕常亮抽象到BasePage」、696aa83c「kmp支持页面支持常亮」
• git branch -a --contains e840dc3b6 → 仅 feature_v8.4.2 与 origin/feature_v8.4.2
• git show master:…/BasePager.kt | grep syncKeepScreenOn → 0 处命中；git show master:…/PlayBackPage.kt | grep keepScreenOnWhenVisible → 0 处命中
• git grep -i "KeepScreenOn|ScreenAwake" origin/master -- '.kt' '.java' → 仅命中扫码页 CameraPreview.java:80 的无关 surfaceHolder.setKeepScreenOn，KMP 回放常亮链路在发布线中完全不存在
• 版本链路：Android 宿主 origin/hotfix_8.4.1 版本号 8.4.1.7、origin/master 版本号 8.4.1.6，其 KMP 模块依赖均为 kuiklyModuleVersonLocal/Release = "8.4.1.7" / 早期 8.4.1.4 → 对应 KMP 发布线 master / feature_v1.1.x，均不含常亮提交
• ⇒ 8.4.1.x 全线用户必然不常亮，与 4 份 Logan「零 PlaybackScreenAwake」双向印证
• 调用链：PlayBackPage.pageDidAppear() → BasePager.syncKeepScreenOn(true) → moduleBase KMPBridgeModule.setKeepScreenOn(pageName, true) → 宿主 KMPBridgeModule "setKeepScreenOn" 分支 → KuiklyRenderActivity.setKeepScreenOn() → applyScreenAwakeRequest() → window.addFlags(FLAG_KEEP_SCREEN_ON)
• 关键分支：applyScreenAwakeRequest() 中 shouldKeepAwake = isActivityResumed && screenAwakeRequested —— 仅当 Activity 前台且页面请求才应用；后台 / 销毁自动释放
• 修复方向锚点：

1. 确认 e840dc3b6 / f98e6f3b / 696aa83c 合入 8.4.1.x 补丁线或随 8.4.2 发版（当前唯一缺口 = 代码未随线上版本发布，不是逻辑缺陷）
2. 交付前须剔除 KMP 示例宿主 androidApp/KuiklyRenderActivity.kt 的同类改动（提交说明中已自述该范围与交付范围不符）

5. 根因结论

• 置信度：🟢 强
• 一句话根因：回放页屏幕常亮的桥接机制已实现，但修复提交 e840dc3b6 仅存在于 feature_v8.4.2，从未进入 8.4.1.x 发布线，故线上 8.4.1.6 用户在系统息屏超时后必然被锁屏。
• 关键证据链：代码分支比对（contains 判定 + master 零命中） ⟷ 4 份独立 Logan 全窗口零 PlaybackScreenAwake ⟷ 用户措辞「以前不会息屏」的回归表述，三者互相印证。

6. 建议下一步

• 分配给：Android / KMP 客户端（发布线负责人）
• 优先处理项：① 把常亮提交 cherry-pick 到 8.4.1.x 补丁线或确认随 8.4.2 发版时间点；② 剔除示例宿主 androidApp 的同类改动
• 验证方法：设置较短系统息屏时间，在 8.4.1.6 与候选包分别连续回放 ≥10 分钟，确认候选包不熄屏、退出回放 / 退后台后常亮释放；回归时用 adb logcat -s PlaybackScreenAwake 核对 Screen awake requested=true 与 Screen awake applied=true 成对出现
• 任务：沿用 T-20260926-170258-576a（不重复创单）

🟠 问题 2：iOS 8.4.1.6 报警消息页进入即卡死，无法刷新 / 操作 / 返回，只能大退 App（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户「只要点进报警消息页面直接卡死，无法刷新，无法操作，无法返回，只能大退 App」——整页无响应，属 UI 主线程阻塞级别的严重体验问题。
• 涉及反馈：1 条（新平台、新用户）
• 256143｜iPhone（iOS 27.0.1）｜App 8.4.1.6｜中国河南省开封市｜2026-10-08 20:55:05
• 严重度评分：62/100（反馈量 10 / 共性 20 / 业务关键度 30 —— 报警消息属高频核心入口；共性记 20：iOS 8.4.1.6 + iOS 27.0.1 双维度，当前仅 1 条、尚未跨用户）
• 说明：本问题跨平台（此前多期为 Android / HarmonyOS 侧问题），iOS 报警页卡死为新面孔，故保留进雷达。

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

• 大盘量级（DeviceVideoPlayback，同窗口）：total_count = 150,746,957 —— 主链路正常，非全局性崩溃。
• 报警页相关事件：本窗口未取得可用于归因的细分分布（报警消息页链路无「卡死」类专用埋点，且单一用户样本不足以做分层）。
• 观测盲区声明：本问题仅 1 条反馈、单用户单机型，神策未提供可对照的异常量级跃升信号 ⇒ 不能据此判定为版本级共性问题。

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

• 反馈 ID：256143（iPhone 27.0.1，iOS 8.4.1.6）｜日志 Seetong-App-Name_1FCC2303-…，48,766 字节，6,972 行；关键词覆盖 AlarmMessage / card / freeze / ANR / main / WatchDog / crash / Exception
• 关键发现（报警页离场后紧接退 App，链路异常中断）：
• [L1083] 2026-10-08 00:19:37.274 … AlarmMessagePage-|00:19.37.272|[KLog][AlarmMessagePage]:stopObserveOnlineAlarmMessages source=pageDidDisappear
• [L1080-1082] 2026-10-08 00:19:37.266 … KRPerformanceManager---onPause--（连续 3 次）
• [L1158] 2026-10-08 00:19:38.039 … MainActivity2-MainActivity onStop...退出APP
• ⇒ 时间序为：报警页 pageDidDisappear → 连续 onPause → 约 0.8 秒后 onStop...退出APP，与用户「只能大退 App」的表述完全吻合
• 另：[L1168] 网络改变：mNetChangeRunnable、[L1169] KRPerformanceManager---onPause-- 出现在退出之后，属宿主重建 / 日志交错段
• 限制：该 Logan 起始于 11:03:33，而用户提交反馈为 20:55:05，卡死时刻的真实主线程栈未落在本次日志时间范围内；日志内未命中 ANR / WatchDog / 明确主线程阻塞栈
• 同用户另一次进入反馈页记录：[L1221] ImprovePage…handleUploadLogClick: open feedback page（00:19:55）—— 属事后提交反馈动作，非卡死现场

4. 代码定位（详细）

• 涉及仓库：seetong-kmp（moduleMessage，跨端共用页）+ Seetong-App-iOS（宿主）
• 关键类：AlarmMessagePage（moduleMessage/src/commonMain/kotlin/com/seetong/modulemessage/page/AlarmMessagePage.kt）
• 关键生命周期锚点（本期实测行号）：
• :311 override fun pageDidDisappear() → :312 super.pageDidDisappear() → :330 stopObserveOnlineAlarmMessages("pageDidDisappear")
• :931 alarmModule.observeOnlineAlarmMessages(observe = true) { … }（进入页面时注册 Native 报警回调）
• :948-954 stopObserveOnlineAlarmMessages(source) → alarmModule.observeOnlineAlarmMessages(observe = false)
• :316-325 注释明确记录：「Android 打开图片预览或回放页会触发 pageDidDisappear」，说明该页离场 / 复现路径存在跨端差异，iOS 侧需单独核对
• 调用链：报警消息入口 → AlarmMessagePage.pageDidAppear() → observeOnlineAlarmMessages(observe=true) 注册 Native 报警回调 → 用户点入详情 / 返回 → pageDidDisappear() → stopObserveOnlineAlarmMessages 注销
• 关键分支（最可能触发卡死的路径）：observeOnlineAlarmMessages 的注册 / 注销不对称——若 pageDidDisappear 未被触发（如被模态遮盖、或 iOS 侧 pageDidAppear 反复触发）则在 Native 报警 biz 上叠加多重回调；注释中已描述过「后发请求覆盖前者、把页面带回 Loading」的同类竞态
• 修复方向锚点：① 核对 AlarmMessagePage 反复 pageDidAppear 时 observeOnlineAlarmMessages(true) 是否幂等；② iOS 宿主分支中 pageDidDisappear 的触发时机与 Android 是否一致；③ 长列表 + 报警图片加载的主线程阻塞点（列表复用 / 图片解码）需补采样
• 代码待定位：iOS 宿主侧报警入口的原生实现未在 Seetong-App-iOS 中找到对应 KMP 接入点（搜索路径：Seetong5.0_ios/Seetong_tps/ 全量 AlarmMessage 命名文件），该缺口不阻塞报告。

5. 根因结论

• 置信度：🟡 中（Logan 直证「报警页离场 → 立即退 App」的时序，与用户表述吻合；但卡死现场主线程栈未落在日志窗口内，且仅 1 条样本、无跨用户共性）
• 一句话根因：iOS 8.4.1.6 进入报警消息页后发生整页无响应，用户被迫大退；现有 Logan 只能证明「报警页离场后约 0.8 秒 App 被退出」，尚不能确认阻塞点在 KMP 报警页回调注册 / 注销、还是 iOS 宿主侧列表渲染。
• 关键证据链：AlarmMessagePage:stopObserveOnlineAlarmMessages source=pageDidDisappear（L1083）→ MainActivity onStop...退出APP（L1158）时序 ⟷ 用户「只能大退」表述；神策未提供对照，无法升级为强置信度。

6. 建议下一步

• 分配给：iOS 客户端（牵头）+ KMP moduleMessage owner（协同）
• 优先处理项：① 取该用户在 20:50~20:56 时段的完整 Logan（本次日志仅覆盖 11:03 起）或现场复现；② 核对 AlarmMessagePage 回调注册 / 注销的幂等性与 iOS 侧 pageDidDisappear 触发时机
• 验证方法：Android 与 iOS 各 1 台真机，连续「进入报警页 → 点开详情 → 返回」≥20 次，观察是否出现无响应；iOS 侧用 Instruments 抓主线程采样
• 任务：建议新建任务，标题「核查 iOS 8.4.1.6 报警消息页进入即卡死」，状态 captured，证据指向本报告

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

汇总：扫描 102 条 → 进雷达 3 条 / 排除 99 条（🟢 无效 3 🟡 配置·待补证 9 🟣 网络 78 🟤 建议·商业化 9）

数据源状态汇总

待补证

• 问题 1：需由发布负责人确认 e840dc3b6 / f98e6f3b 是否 cherry-pick 进 8.4.1.x 补丁线；候选包需真机连续回放 ≥10 分钟验证，并以 adb logcat -s PlaybackScreenAwake 核对 requested=true / applied=true 成对出现
• 问题 2：需取 256143 用户在 20:50~20:56 时段的完整 Logan（本次日志起于 11:03）；并核对 AlarmMessagePage:931/948 回调注册 / 注销的幂等性与 iOS 侧 pageDidDisappear 触发时机
• HarmonyOS 1.1.1.11 聚集（本窗口 10 条，多为回放 / 卡顿 / 黑屏 / 网络联系不上）：全部无 Logan，无法定位，暂仅登记不深挖；若同一版本连续 3 期出现同类聚集，需升级为专项排查
• 窗口连续性：本期为 09:00 正期，窗口起点取上一期 H17 报告头部（2026-10-08 09:00~17:00）的结束时刻 17:00:00，两期首尾相接、无重叠、无遗漏；2026-10-08 当日存在 3 次手动补跑，已确认与本窗口不重叠

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