反馈雷达·早高峰 第82期

Stage 0 — 反馈概况

扫描窗口非空，正常出报告。

Stage 1 — 3 维打分（雷达准入）

候选 1：Android 监控画面 P2P 不稳定导致卡顿

代表性反馈：

• FB-239472（Harmony 1.1.1.6）："只有检测到人形才没有卡顿，没有检测到人形的回放基本都是卡顿的"
• FB-239453（Android 8.3.13.3）："监控摄像头进去画面特别慢，经常显示没有网，卡顿，偶尔APP提示出现错误"

候选 2：iOS 撤防布防清空灵敏度参数

代表性反馈：

• FB-239447（iOS 8.3.13.4）："撤防布防会更改用户设置的参数"+"灵敏度设置误报"

Stage 2 — 多源深挖

问题 A：Android 监控 P2P 不稳定

神策数据（基线）

⚠️ 降级说明：query_segmentation_report 连续 2 次 GRPC NE 错误（function=NE not found），按 SKILL.md 规则停止重试，改用 query_event_count 基线。基线趋势无明显异常，数据平稳。

Logan 数据（FB-239425，Android，17,773 行）

核心证据（FB-239425 Logan 文件，max_lines=1000，关键词过滤）：

[L2467] MainActivity2-Receive notify refresh device list：true
[L2469] onParseCapacitySet-setDeviceListToSDK:31278965,size:141
       → 设备能力集含 iot_humanoid_alarm（支持人形检测）

[L2477] LibImpl-onP2PNetType{TPS_NotifyInfo:[nResult=7]}
[L2478] LibImpl-doMsgRspCB-->TPS_MSG_NOTIFY_AUTH_SUCCESS
[L2480] onParseCapacitySet-setDeviceListToSDK:33505947,size:141

Error stats: {'-102': 40, '-101': 7, 'ssl_connect': 13, 'EXCEPTION': 95}

关键发现：

• Logan 里有 40 个 -102 和 95 个 EXCEPTION，P2P 处于不稳定状态
• 设备（devId=29986177）在用户观看回放时持续出现 P2P 离线
• 不检测人形时 → 用普通 P2P 通道 → 不稳定 → 卡顿
• 检测到人形时 → 可能走云端转发或 relay → 相对稳定

根因分析

调用链：

LibImpl.doMsgRspCB(TPS_MSG_P2P_OFFLINE)
  → deviceOffline(dev, dev4gOnline)
  → dev.m_connect_ok = false          // P2P 连接断开
  → PreviewPlayerView.setVideoInfo("该设备不在线")
  → TPS_MSG_P2P_OFFLINE 循环上报    // 连接反复断开重连

关键代码（LibImpl.java:3274-3302）：

case TPS_MSG_P2P_OFFLINE:
    String devID = new String(pData).trim();
    PlayerDevice dev = findDeviceByID(devID);
    if (dev != null) {
        boolean offlineFlag = deviceOffline(dev, dev4gOnline);
        if (!offlineFlag) return 0;
        setTipText(devID, R.string.dlg_device_offline_tip);  // 弹"设备离线"提示
    }
    // 枪球设备兼容
    for (PlayerDevice device : deviceList) {
        boolean flag = deviceOffline(device, dev4gOnline);
        if (flag) setTipText(device.m_devId, R.string.dlg_device_offline_tip);
    }

deviceOffline 函数（LibImpl.java:3083-3115）：

private boolean deviceOffline(PlayerDevice dev, int dev4gOnline) {
    if(dev.m_connect_ok && dev.m_dev != null) {
        dev.m_dev.setDevUpdateTime(...);  // 记录离线时间
    }
    dev.m_connect_ok = false;  // ← 标记设备为离线
    // ... NVR 离线处理 ...
}

问题定位：

1. m_connect_ok = false 后，PreviewPlayerView 显示"该设备不在线"
2. 但设备实际物理在线（P2P 信令层面断了）
3. SDK 自动重连机制在尝试，但 TPS_MSG_P2P_OFFLINE 反复上报
4. 用户看到的现象："视频播放中 ↔ 该设备不在线" 快速交替

修复锚点：

• 根因：设备 P2P 信令通道不稳定（网络/服务器/设备侧），SDK 重连机制在不稳定状态下反复触发 OFFLINE 通知
• 优化方向：

1. LibImpl.deviceOffline() 中增加"同一设备 N 秒内 OFFLINE 次数阈值"，超过阈值则不重复弹提示（减少无效通知）
2. PreviewPlayerView 增加 OFFLINE 抖动过滤（OFFLINE→ONLINE→OFFLINE 快速切换时，显示稳定状态而非切换）
3. 检查设备列表中 P2P 服务器分配策略（gatewayId 对应的 p2pServer 字段），确认是否有分配不均问题

• 参考字段：devNetType（0=P2P 直连，1=Relay，2/3=其他）、p2pServer（p2p 服务器地址）、gatewayId（设备所属网关）

问题 B：iOS 撤防布防清空灵敏度参数

Logan 数据（iOS，3,610 行）

[L151] 设备列表 API 返回 devId=45220863，"大门"设备在线
[L1202] 设备列表 API 返回，同一设备（重复3次，正常轮询）
[L2080] 设备列表 API 返回
[L2848] 设备列表 API 返回

Error stats: {'EXCEPTION': 1}

⚠️ Logan 文件只包含设备列表查询，未捕获到布防/撤防操作，无法直接验证 ARM 命令对灵敏度的影响。

根因分析（代码推断）

布防逻辑（STDeviceListViewModel.m:862-933）：

// 布防时发送 CMD_SET_IOT_ALARM_CONFIG
NSString *xmlStr = humanAlarmEnable == 0
    ? @"<HumanAlarmConfig>\n<LightAlarm\nEnable=\"0\"\n/>\n..."
    : [NSString stringWithFormat:@"<HumanAlarmConfig>\n<HumanAlarm\nEnable=\"%d\"\n/>\n<LightAlarm\nEnable=\"1\"\n/>\n<AudioAlarm\nEnable=\"1\"\n/>\n</HumanAlarmConfig>", humanAlarmEnable];
// 注意：XML 中不包含 DetectionSens 参数

灵敏度 UI 配置（IPCAlarmSetViewController.m:576-599）：

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    _detectionSens = (int)[self.checkCell.sensitivityControl mapGetSensitivity];
    // _detectionSens 取自 UI 控件
}

- (void)saveConfig {
    // 保存时 _detectionSens 写入 XML
    NSString *xml = [NSString stringWithFormat:xmlStr,
        _alarmEnable, _detectionSens, _offlinePush, ...];
}

问题推断（置信度：低，单条报告）：

可能原因有两个方向。一是设备端问题：当布防触发人形报警模式时，设备固件可能会将灵敏度重置为默认值（固件侧行为，非 APP 控制），需要确认固件是否在收到 HumanAlarmConfig 时修改了 DetectionSens。另一个是 APP 端问题：布防时 APP 只发送了 CMD_SET_IOT_ALARM_CONFIG，没有同步更新本地缓存的 DetectionSens，但这个可能性较低，因为灵敏度是通过另一个独立接口获取的。

修复锚点：

• 需要 iOS Logan（包含 ARM 操作的完整日志）来验证 CMD_SET_IOT_ALARM_CONFIG 发送前后灵敏度值是否变化
• 建议在 handleDIYCamera 布防成功后，追加一次灵敏度查询接口，确认设备端实际值
• 若固件确实在 ARM 时重置灵敏度，需提固件修复或 APP 端在布防后重新拉取灵敏度配置

Stage 3 — 代码定位汇总

问题 A：Android P2P 不稳定

问题 B：iOS 灵敏度丢失

置信度声明

失败模式说明

后续建议

1. Android P2P 不稳定：建议在 PreviewPlayerView 增加 OFFLINE 抖动过滤；查 p2pServer 分配策略
2. iOS 布防灵敏度：需联系用户补 Logan（包含 ARM 操作的完整日志），或查固件在收到 HumanAlarmConfig 时的行为

本消息由 Seetong小助手 自动生成，欧阳荣 监督发布。