iOS集成最新版Jitsi Meet SDK遇QoS优先级反转崩溃问题求助

问题描述 #

集成最新版Jitsi Meet SDK到iOS应用后，重复发起/结束一对一通话2-3次后应用崩溃，报错：

Thread running at QOS_CLASS_USER_INTERACTIVE waiting on a lower QoS thread running at QOS_CLASS_DEFAULT. Investigate ways to avoid priority inversions.

复现步骤：

• 发起一对一通话
• 接收方加入后离开会议
• 再次发起一对一通话
• 接收方再次加入后离开会议
• 应用崩溃并触发上述错误

崩溃前日志：

2023-05-25 12:40:13.351655+0530 GatherHall-Staging[14842:1032673] [JitsiMeetSDK] [JitsiConference.js] Removing remote P2P track: RemoteTrack[userID: f9dd57e1, type: audio, ssrc: 2609474008, p2p: true, sourceName: f9dd57e1-a0, status: {readyState: live, muted: false, enabled: true}] 
2023-05-25 12:40:13.351803+0530 GatherHall-Staging[14842:1032662] [JitsiMeetSDK] [JitsiConference.js] Stopping remote stats for P2P connection participantLeft [AnyHashable(“participantId”): f9dd57e1] 
2023-05-25 12:40:13.354828+0530 GatherHall-Staging[14842:1032872] [JitsiMeetSDK] [JitsiConference.js] Stopping CallStats for P2P connection 
2023-05-25 12:40:13.355889+0530 GatherHall-Staging[14842:1032674] [JitsiMeetSDK] [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=P2P,initiator=true,sid=07968ae8bcb6] Skipped sending session-terminate 
2023-05-25 12:40:13.357528+0530 GatherHall-Staging[14842:1032662] [JitsiMeetSDK] [modules/xmpp/JingleSessionPC.js] JingleSessionPC[session=P2P,initiator=true,sid=07968ae8bcb6] Session terminated undefined undefined 
2023-05-25 12:40:13.361885+0530 GatherHall-Staging[14842:1032662] [JitsiMeetSDK] [JitsiConference.js] Peer to peer connection closed!

解决方案 #

1. 调整SDK线程QoS优先级 #

在初始化Jitsi Meet前，强制将SDK相关操作的线程优先级与主线程对齐为QOS_CLASS_USER_INTERACTIVE，避免高低优先级线程锁竞争：

// 初始化前设置线程优先级
Thread.current.qualityOfService = .userInteractive

// 初始化JitsiMeet配置
let options = JitsiMeetConferenceOptions.fromBuilder { builder in
    builder.setServerURL(URL(string: "你的Jitsi服务器地址"))
    // 其他业务配置
}
JitsiMeet.sharedInstance().initialize(options)

同时，在会议结束的回调中，将资源清理操作放到高优先级线程执行：

func conferenceTerminated(_ data: [AnyHashable : Any]!) {
    DispatchQueue.global(qos: .userInteractive).async {
        // 自定义资源清理逻辑
    }
}

2. 主动清理SDK资源 #

每次会议结束后调用destroy()释放SDK持有的所有资源，避免重复创建会议导致的资源堆积和线程冲突：

func conferenceTerminated(_ data: [AnyHashable : Any]!) {
    JitsiMeet.sharedInstance().destroy()
    
    // 若需要再次发起会议，延迟重新初始化
    DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) {
        let newOptions = JitsiMeetConferenceOptions.fromBuilder { builder in
            // 重新配置会议参数
        }
        JitsiMeet.sharedInstance().initialize(newOptions)
    }
}

3. 降级到稳定版SDK #

部分开发者反馈最新版SDK存在未修复的QoS线程问题，可降级到6.2.0等已知稳定版本，在Podfile中指定版本：

pod 'JitsiMeetSDK', '~> 6.2.0'

4. 临时禁用P2P模式 #

如果业务允许，可在会议配置中关闭P2P模式，强制使用SFU服务器转发，规避P2P连接的线程管理问题：

let options = JitsiMeetConferenceOptions.fromBuilder { builder in
    builder.setFeatureFlag("p2p.enabled", withBoolean: false)
    // 其他配置
}

内容的提问来源于stack exchange，提问作者S K