Kotlin中如何正确处理WebSocket回调并向Compose页面共享数据

你现在用单例持有WebSocket连接、SharedFlow分发事件、ViewModel收集数据驱动Compose渲染的核心思路是合理的，但现有实现存在几个设计缺陷，上线后很容易出现内存泄漏、消息丢失、回调异常的问题。

现有实现的核心问题 #

• 把页面ViewModel的协程作用域传入全局单例是典型的生命周期错配。单例生命周期和应用进程一致，ViewModel生命周期和绑定的页面一致，页面销毁时ViewModel会被回收、对应的协程作用域会被取消：一方面短生命周期对象被长生命周期单例持有会造成内存泄漏，另一方面作用域失效后，onMessage里启动的协程会直接抛异常或者无法执行，导致消息完全丢失。
• SharedFlow使用默认配置没有做背压兜底。默认构造的MutableSharedFlow缓冲区大小为0，只要收集端暂时处于不可收集状态（比如页面切后台、配置变更重建、协程还没启动），发送的消息会直接被丢弃，对需要可靠送达的业务场景不友好。
• 消息解析、发送逻辑没有异常兜底。如果convertStringToModel解析失败抛出异常，会直接把协程作用域打崩，后续所有消息都无法正常分发。
• OkHttp的WebSocket回调本身运行在OkHttp内部的工作线程，完全依赖外部传入的协程作用域决定执行线程，上下文不可控。

修正后的实现方案 #

1. 调整WebSocketManager的设计 #

不要接收外部传入的协程作用域，单例自己持有和应用生命周期对齐的独立协程域，同时配置好SharedFlow的参数：

// 密封类定义所有Socket事件，避免类型判断混乱
sealed class WebSocketEvent {
    data class OnConnectionStateChanged(val isConnected: Boolean) : WebSocketEvent()
    data class OnMessageReceived(val data: YourSocketModel) : WebSocketEvent()
    data class OnParseError(val throwable: Throwable, val rawText: String) : WebSocketEvent()
}

class WebSocketManager private constructor() {
    // 自定义作用域，用SupervisorJob避免单个子协程异常影响整个管理器
    private val managerScope = CoroutineScope(SupervisorJob() + Dispatchers.IO)

    private val _socketEvents = MutableSharedFlow<WebSocketEvent>(
        replay = 0, // 需要新订阅者拿到最新一条消息就设为1，纯即时事件设0即可
        extraBufferCapacity = 64, // 预留足够缓冲区应对背压
        onBufferOverflow = BufferOverflow.DROP_OLDEST // 缓冲区满时丢弃最老的过期消息，可根据业务调整
    )
    val socketEvents: SharedFlow<WebSocketEvent> = _socketEvents

    // 省略OkHttpClient初始化、connect、disconnect等基础逻辑

    private inner class AppWebSocketListener : WebSocketListener() {
        override fun onMessage(webSocket: WebSocket, text: String) {
            // 直接用管理器自身的作用域启动协程，不依赖外部传入的scope
            managerScope.launch {
                val parseResult = runCatching { convertStringToModel(text) }
                parseResult.onSuccess { model ->
                    _socketEvents.emit(WebSocketEvent.OnMessageReceived(model))
                }.onFailure { e ->
                    _socketEvents.emit(WebSocketEvent.OnParseError(e, text))
                }
            }
        }

        // 其他onOpen、onClosed、onFailure回调同理，都用managerScope分发对应事件
    }

    companion object {
        @Volatile
        private var instance: WebSocketManager? = null
        fun getInstance(): WebSocketManager {
            return instance ?: synchronized(this) {
                instance ?: WebSocketManager().also { instance = it }
            }
        }
    }
}

2. ViewModel层正确收集事件 #

不要把ViewModel的作用域往外传，直接在ViewModel自身的viewModelScope里收集事件，转换成Compose可直接观测的UI状态：

data class PageUiState(
    val isSocketConnected: Boolean = false,
    val latestMessage: YourSocketModel? = null
)

class ChatViewModel : ViewModel() {
    private val socketManager = WebSocketManager.getInstance()
    private val _uiState = MutableStateFlow(PageUiState())
    val uiState: StateFlow<PageUiState> = _uiState.asStateFlow()

    init {
        viewModelScope.launch {
            socketManager.socketEvents.collect { event ->
                when(event) {
                    is WebSocketEvent.OnConnectionStateChanged -> {
                        _uiState.update { it.copy(isSocketConnected = event.isConnected) }
                    }
                    is WebSocketEvent.OnMessageReceived -> {
                        _uiState.update { it.copy(latestMessage = event.data) }
                    }
                    is WebSocketEvent.OnParseError -> {
                        // 可以在这里加日志上报、错误提示逻辑
                    }
                }
            }
        }
    }

    // 页面需要发送消息时直接调用manager的send方法即可
    fun sendMessage(content: String) {
        socketManager.send(content)
    }
}

3. Compose层渲染 #

只需要收集ViewModel暴露的UI状态即可，不要直接在可组合项里收集WebSocket的事件流：

@Composable
fun ChatPage(viewModel: ChatViewModel = viewModel()) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    // 基于uiState做页面渲染即可
}

额外注意点 #

• SharedFlow的参数不要照搬，根据你的业务场景调整：如果是股票报价、实时位置这类时效性极强、旧数据无意义的场景，缓冲区溢出策略选DROP_OLDEST即可；如果是聊天消息这类不能丢的场景，可以配合本地消息队列做持久化，不要完全依赖内存里的Flow缓存。
• WebSocket连接不要和单个页面绑定，建议结合应用前后台生命周期管理连接，避免后台空跑耗流量耗电。
• 如果有多个页面需要同时收集Socket事件，当前的单例+SharedFlow设计可以直接支持，不需要额外修改，SharedFlow本身支持多订阅者。

内容的提问来源于stack exchange，提问作者M D