Seetong · Report

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

时间窗口：2026-10-19 09:00:23～17:08:53（Asia/Shanghai）

📌TL;DR 核心要点

  • 🔴 Android 8.4.1.6 在 16 分屏预览场景下出现应用进程反复重启，用户直接描述为“五分钟或十分钟闪退一次”：反馈 258335 的 Logan 在同一天出现 3 次 Application.onCreate，其中两次仅相隔 1.37 秒，另一次与前一轮相隔约 14 分钟；日志中没有 FATAL EXCEPTION 或 native signal，无法确认具体异常栈，严重度 60 / 100，现象置信度中、根因置信度弱。
  • 🟠 本期没有第二个达到 60 分门槛的新问题。258257 的“切到下一个摄像头仍显示第一个画面”与第 240 期已分析的画中画旧画面问题同域，按 24 小时去重规则不重复展开；258267 的回放卡死、258327 的设防回放不可用均为单用户且无 Logan，列入待补证。
  • 258335：Android 8.4.1.6、HONOR YAG-W09、山东，17:03:40 反馈“荣耀 x10promax，闪退，有时五分钟，有时十分钟”。

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-19）。

#问题（严重度降序）严重度平台版本负责人问题原因
1Android 8.4.1.6 及 HarmonyOS 1.1.1.11 单设备随机离线、P2P 恢复失败
17 期 · 153 条反馈
100Android · HarmonyOS1.1.1.11 / 8.4.1.6 / 1.1.1陈宝旺、冉博麟、唐胜、李国涛257582、257639 已确认是服务端心跳长期停更并伴随 P2P 离线，App 只是按离线状态展示；问题更可能在设备端、设备网关／P2P 服务或固件恢复机制，而不是 Android 播放器单点故障。
2Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6陈宝旺、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
3HarmonyOS 画中画状态导致切换设备后仍显示前一路画面
1 期 · 3 条反馈
90HarmonyOS1.1.1.11 / 1.1.2.3张跃译多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。
4升级后回放体验整体退化
4 期 · 18 条反馈
85Android · iOS8.4.1.6 / 8.3.14.2唐胜、许源、欧阳荣、谭伟8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
5KMP 回放页未申请屏幕常亮，回放中手机自动息屏
11 期 · 29 条反馈
84Android · HarmonyOS8.4.1.6 / 8.4.1 / 8.4.2唐胜、陈宝旺、许源、谭伟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，回放过程中发生系统级息屏。
6SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断
3 期 · 9 条反馈
80Android · HarmonyOS · iOS8.4.1.6 / 1.1.1.11唐胜、张威、陈宝旺设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。
7iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
8iOS 老版本微信登录空授权码触发 30100222
1 期 · 1 条反馈
80iOS8.1.3.5 / 8.1.305 / 8.1.503位冬微信授权回跳在当前旧版 iOS 上返回了空 code，客户端没有把它视为失败边界，仍向服务端提交空授权码，最终稳定触发 30100222。
9KMP 卡回放取「当天录像」时走云回放分支，失败后无超时兜底并反复重试
1 期 · 4 条反馈
71Android8.3.11.3 / 8.4.1.6陈宝旺、谭伟KMP 回放页在选择 Tab 时只信设备记忆、不信设备能力，把 supportCloud=false 的设备硬切到云回放 Tab 并以「前一天」初始化；云链路从未 prepared（currentVideoUrl 空、cloudPrepared=false），失败事件 result=0 又恰好落入 result<0 的无退避重试分支，同时 SD 异常态在非 WiFi IPC 上被 return NONE 吞掉——三者叠加，用户既看不到当天录像也收不到失败提示，且失败状态被 saveLastPlaybackTab(tabIndex=1) 固化到下一次。
10iOS 8.4.1.6 冷启动点击离线报警推送后未进入回放
1 期 · 2 条反馈
70iOS8.4.1.6 / 8.4.106欧阳荣、谭伟、陈宝旺当前冷启动没有留下通知响应回调或 KMP 回放路由证据，用户实际停留在普通启动链路；最可能的缺口是冷启动通知回调 / 参数分支未被当前处理逻辑承接或没有兜底，但尚不能确认是 APNs payload 缺 content、回调未到、视图条件拦截还是路由失败。

🔴 问题 1：Android 8.4.1.6 的 16 分屏预览期间应用进程反复重启 ｜ 负责人：唐胜、张威

现象与覆盖范围

  • 258335：Android 8.4.1.6、HONOR YAG-W09、山东，17:03:40 反馈“荣耀 x10promax，闪退，有时五分钟，有时十分钟”。
  • 该反馈提供了可下载 Logan，日志共 59,216 行，覆盖 2026-10-19 00:00:01～16:48 左右。用户在 16:20:49 进入 16 分屏，日志列出 8 台枪球设备的 16 个通道；16:26:13 一次性停止多个播放器，16:26:14.666 与 16:26:16.038 连续出现两次 Application.onCreate，16:40:17.624 又出现一次。
  • 这是一名单用户样本，机型、版本、地区维度均单一；但应用在 16 分屏预览期间短时间内反复重建进程，和“使用几分钟后闪退”的描述形成直接时间对应。
  • 严重度评分：60 / 100。反馈量 10（1 名用户）；共性广度 10（单平台、单版本、单机型）；业务关键度 40（实时预览是核心监控链路，进程重启会直接中断多路查看）。

神策证据

  • MonitorFrameResult 全平台 10 月 19 日截至查询时刻共 35,547,940 次、8,033,909 名用户。Android 8.4.1.6 为 18,899,283 次、4,541,388 名用户，成功 18,405,717 次、失败 493,566 次，失败率约 2.61%。
  • 该失败率只代表出图事件，不等同于 App 崩溃率。MonitorFrameResult 不能解释进程为何重启，也未提供本用户的 clientId 关联，因此本期不把出图失败率当成闪退证据。
  • 神策可以确认 Android 8.4.1.6 仍是当日主要运行版本，样本并非极小尾量；但不能替代崩溃堆栈。

友盟证据

  • Android 8.4.1.6 在 09:00～16:00 的小时崩溃率为 0.01%～0.02%，每小时错误数 273～364；17:00 小时尚未完整，当前 106 个错误、0.02%。
  • Native 崩溃率同期为 0.01%，每小时 142～221 个错误；没有出现平台级尖峰，因此不能证明大量用户同时遭遇同类闪退。
  • 友盟只能说明大盘，不知道本机是否上报，也没有反馈 ID 关联；用户“每 5～10 分钟一次”的高频现象不能被大盘平均率否定。

Logan 关键日志

  • 16:20:50.552 起，PreviewPlayerView-onAttachedToWindow 连续出现，同一 PlayerPreviewActivity 同时附加 16 路播放器；16:20:52.408～52.515 收到 16 路首帧。
  • 16:20:56.266，PreviewSession 记录 currentSplitMode=16、previewDeviceCount=16、lowPowerDeviceCount=16，确认不是四分屏或单画面。
  • 16:26:13.176～13.200，代码连续停止 47697144-CH-1、47697144-CH-2、47697363-CH-1 等播放器，随后记录 ---App from front to back--。
  • 16:26:14.666，SeetongLog-TIme-onAppStart end；16:26:14.705，Application onCreate Time:251；仅 1.37 秒后，16:26:16.038 与 16:26:16.089 再次出现相同启动完成记录。
  • 16:40:17.624 与 16:40:17.691，又出现一次 onAppStart end 和 Application onCreate Time:389。反馈发生于 17:03:40，三次进程启动均落在反馈前约 37～47 分钟。
  • 全文检索未发现 FATAL EXCEPTION、AndroidRuntime、Fatal signal、SIGSEGV、SIGABRT、OutOfMemoryError、ANR in 或 Force finishing。这不能证明“没有崩溃”，只能说明本次上传的 Logan 没有保留异常栈。

代码定位

  • 涉及模块：Seetong-App-Android/Seetong5.0ForSeetong/Seetong5.0/app。
  • App.java:40-64：Application.onCreate() 同步调用 Global.onAppStart()；日志中的 onAppStart end 与 Application onCreate Time 可作为一次进程级启动的明确锚点。
  • Global.java:2385-2400：自定义 Thread.setDefaultUncaughtExceptionHandler 捕获未处理异常后，先调用 saveCrashInfo2File()，再构造 FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TOP 的重启 Intent，最后调用 Process.killProcess(myPid())。
  • Global.java:2872-2899：异常栈会写入 getCrashinfoDir() 下的 crash yyyyMMdd_HHmmss.log，同时尝试写入 Logan。当前 Logan 没有异常栈，因此下一步必须取应用日志 ZIP 中的 crash sidecar 文件。
  • PlayerPreviewActivity.java:539：进入预览时从 SplitScreenManager 恢复上次分屏数量，支持 16 分屏；PlayerPreviewActivity.java:6142-6198 的页面停止/恢复会统一起停当前播放列表。
  • PlayerContainerFragment.kt:1655-1666：stopOrStartCurrentPlayList() 对 getUsedPlayers() 全量遍历，16 分屏时会同步起停 16 个播放器。
  • PreviewPlayerView.kt:348-379：每个画面动态绑定一个 GLSurfaceView 和一个 OpenglesRender；:762-779 再为每个画面建立独立的 10 秒求流计时器。16 分屏因此意味着最多 16 套 GL 渲染器与 16 个周期任务同时运行。
  • 调用链：进入预览 → 恢复 16 分屏 → PlayerContainerFragment.playCurrentDevice() → 16 个 PreviewPlayerView 各建 GLSurface/计时器 → 启动或停止全部播放器 → 应用进程结束 → Application.onCreate() 重建。
  • 当前代码能解释“自动拉起会让用户看到近似连续闪退/重启”，也能指出 16 分屏资源放大点；但没有本次 crash sidecar，不能断言是 GL、媒体资源、SDK native 层还是 Java 异常导致。

根因结论

  • 置信度：现象 🟡 中，根因 🔴 弱。
  • 一句话根因：可确认用户在 16 分屏预览期间经历至少三次进程级冷启动；最可能是一次未上传的未处理异常或进程被系统终止，现有 Logan 缺少崩溃栈，无法继续定位到具体组件。
  • 关键证据链：用户原话“每 5～10 分钟闪退” → 16 分屏持续运行 → 16:26 正常停止全部播放器后连续两次冷启动 → 16:40 再次冷启动 → 同一版本友盟大盘无异常尖峰，说明是少数设备/使用组合触发，而不是全版本服务中断。
  • 明确不下的结论：不把 16 分屏直接认定为根因，不把 InputVideoDataAgent=return -33 写成崩溃原因，也不把友盟大盘正常解读为该用户没有问题。

建议下一步

  • 分配给：Android 预览与 KMP 播放负责人为主，SDK native 内存/媒体负责人配合；任务 T-20261019-171814-47a3，状态 P1 / captured。
  • 回访 258335，索取 getCrashinfoDir() 对应的 crash *.log 或完整应用日志 ZIP，确认 16:26:14、16:26:16、16:40:17 三次启动前是否存在异常栈、ActivityManager 杀进程原因、lowmemory 或 native tombstone。
  • 在 HONOR YAG-W09、Android 8.4.1.6、21 台设备场景下连续运行 30 分钟：记录 pid、前台 Activity、Java heap/native heap/fd/线程数、GLSurface 数、MediaCodec 数、SDK 连接数，并每分钟触发一次前后台切换。
  • 复现矩阵至少覆盖：16 分屏持续播放、16 分屏切 1/4 分屏、快速换设备、横竖屏切换、前后台切换、弱网重连；每轮同时记录 onCreate/onDestroy、渲染帧时间与进程终止原因。
  • 修复方向：把自动重启与崩溃上报解耦，先持久化并上报完整堆栈再决定是否重启；为连续重启增加冷却和次数上限，避免 1 秒级重启循环；16 分屏下限制并发 10 秒求流任务并复用渲染资源。

本期扫描全量

关键词／类型反馈数反馈 ID 与处置
普遍网络提示 -102 / -101 / -100263258334、258333、258332、258330、258329、258328、258326、258325、258324、258323、258322、258320、258319、258316、258315、258314、258313、258312、258311、258310、258309、258308、258307、258306、258305、258304、258302、258301、258300、258299、258297、258296、258294、258292、258291、258290、258289、258286、258285、258284、258283、258280、258278、258277、258276、258275、258274、258273、258272、258271、258268、258264、258263、258262、258261、258260、258258、258256、258255、258253、258252、258251、258250；均为多语言网络模板，按 🟣 排除
闪退／进程重启1258335；Logan 直证 16 分屏期间 3 次冷启动，进入问题 1
回放、录像、离线与连接异常10258327、258318、258267、258321、258317、258288、258298、258282、258281、258257；单点或 24 小时重复，未达独立雷达门槛
夜间画面与灯光策略3258303、258254、258287；需要设备成像模式与计划任务记录，暂列观察
人形识别、401 与无效内容3258295、258259、258331；证据不足，暂列待补证
使用咨询与未达门槛观察6258293、258279、258270、258269、258266、258265；单用户或信息不足，暂列观察或按 🟢 咨询排除
反馈接口按 2026-10-19 日期级查询返回 total=117 / fetched=117 / complete=true，再按 09:00:23～17:08:53 精确裁剪为 86 条；网络项与业务项按每条反馈的主问题唯一归类，合计 86 条。心愿单另有 5 条产品建议，未混入反馈总数。

排除与重复说明

  • 258257 的“打开下一个仍出现第一个画面”与第 240 期 HarmonyOS 画中画旧画面问题同域，24 小时内不重复分析；沿用手写任务 T-20260924-090202-a811。
  • 258293 的“画面卡顿”虽有一份 Logan，但日志只显示 12:37～12:51 频繁切换单分屏/四分屏与播放状态，未出现明确首帧超时、解码错误或丢帧指标；单用户样本不足以独立进入雷达，列为下一期回看项。
  • 258267 明确否认内存卡问题并要求排查回放卡死，但无 Logan；258327 的“设防回放不工作”同样无日志，均不凭描述猜测根因。

心愿单与数据源状态

心愿单亮点

  • 5390：希望增加电视版或手机投屏，属于明确的大屏使用诉求。
  • 5389：希望恢复旧版回放时间轴拖动方式，反映新版交互效率回退，建议产品复核。
  • 5388：设备自动离线十几天且售后未解决，建议与设备心跳、售后工单一起闭环。
  • 5387：希望设备离线时仍能查看历史回放，涉及本地缓存与云端策略。
  • 5386：希望增加灯光亮度调节，可与设备能力位和照明控制链路评估。

数据源状态

  • 反馈平台：✅ 正常。日期级 total=117 / fetched=117 / complete=true；精确时间窗内 86 条全部纳入扫描。
  • 心愿单：✅ 正常。total=5 / fetched=5 / complete=true。
  • 友盟：✅ 可查询。Android 8.4.1.6 的崩溃、Native 崩溃与卡顿统计均取得小时数据；大盘无尖峰，但没有反馈 ID 级关联。
  • 神策：✅ 可查询。MonitorFrameResult 趋势与 Android 8.4.1.6 平台分布成功；该事件不含崩溃诊断字段，本期只作为出图基线。
  • Logan：⚠️ 部分覆盖。258335 有 59,216 行 Logan，可直证应用多次冷启动；未包含 crash *.log 或 native tombstone，根因证据不完整。
  • 代码仓：✅ 正常。已定位 Android 应用启动、异常自动重启、16 分屏播放控制与每画面 GLSurface/计时器实现。
  • TAPD：⏭️ 未调用，本期主要处于客户端崩溃根因阶段，不引入历史 Bug 干扰。

待补证

  • 258335 的 crash *.log、应用日志 ZIP、Android logcat tombstone，以及三次 Application.onCreate 前的进程终止原因。
  • HONOR YAG-W09 在 16 分屏下的 Java heap、native heap、fd、线程、GLSurface、MediaCodec 与 SDK 连接资源曲线。
  • 258267 回放卡死、258327 设防回放不可用的 Logan 与设备型号，确认是否属于已知 HarmonyOS 回放链路问题。
  • 258293 的掉帧率、recv_frame_time 与渲染帧间隔；当前日志不足以证明“画面卡顿”来自客户端，不能与 258335 的进程重启混为一谈。
  • 258295“升级后人形识别默认无法开启”的设备能力位、服务端配置继承与本机日志。

下一期 = 第243期 = 2026-10-20-H09.md（明天上午 09:00；窗口 今日 17:08:53 ~ 明日 09:00）

🗂️历史期次

查看全部历史期次（近 90 天）→

由 OpenClaw 统一报告渲染器生成 · 最新更新时间：2026-10-19 17:19 · 数据以同名 Markdown 原始报告为准