iOS通过TCP socket调用WKWebView evaluateJavascript触发IPC限流导致UI阻塞问题

整个问题的触发链路和核心原因可拆解为三点：

• WKWebView 的 JS 执行逻辑运行在独立的 WebContent 进程中，evaluateJavaScript 的所有调用本质都是 App 主进程向 WebContent 进程发送 XPC 跨进程消息，不存在同进程内直接调用的路径
• 当前实现中，每收到一条 Socket 数据，就无缓冲地通过 Combine 直接投递到主 RunLoop，立即触发一次 evaluateJavaScript 调用。高频次的调用会产生海量待发送的 XPC 消息，持续在主队列和跨进程通道中堆积
• 当跨进程通道中堆积的待处理消息超过系统设置的安全阈值时，就会触发系统内置的 IPC 节流机制（也就是报错提示的内容）。同时主 RunLoop 被大量待执行的 evaluateJavaScript 任务占满，无法正常处理触摸、渲染等 UI 事件，最终造成全应用 UI 阻塞。

• 增加短窗口数据缓冲合并逻辑，摒弃“来一条发一次”的调用模式。可以在主队列维护临时数据缓冲区，以 100~200ms 为时间窗口，把窗口内收到的所有 Socket 数据批量拼接为 JS 可识别的格式，仅执行一次 evaluateJavaScript 调用，将高频次的跨进程请求压缩到系统可承载的范围。
• 增加 JS 串行执行的流控逻辑，避免并发发送跨进程请求。维护执行状态标记，只有当上一次 evaluateJavaScript 的 completionHandler 触发后，再从本地待发送队列取出下一批数据发起调用，保证同一时间最多只有1条跨进程消息在通道中传输，从根源避免消息堆积。
• 调整 Combine 链路的投递策略，不要直接把上游 Socket 的原始事件透传到主队列。可以在上游调度阶段使用 Combine 的 collect、throttle 操作符，对短时间内的连续事件做窗口合并、降频处理后，再统一投递到主队列执行调用，减少主队列的任务密度。
• 对持续高频的大数据传输场景，可替换通信架构：通过自定义 URLSchemeHandler 把 Socket 接收的数据注册为 WebView 可主动拉取的本地资源，完全绕开频繁的 evaluateJavaScript 跨进程通信路径，从架构层面降低跨进程通信的压力。

内容的提问来源于stack exchange，提问作者Hwangho Kim