将Kotlin中ConcurrentLinkedQueue替换为Channel队列以优化性能

我正在开发一款移动端BPM数据读取应用，需要实现串行任务队列——必须完成前一个任务后才能执行下一个。参考了某个协程库的代码后，当前基于ConcurrentLinkedQueue实现的队列响应迟缓，想排查原因，同时寻找更高效的替代方案。了解到Kotlin的Channel是FIFO队列类型，但不确定是否适用，希望得到帮助。

现有队列实现代码 #

队列轮询函数setupQueuePolling #

private fun setupQueuePolling() {
        viewModelScope.launch(Dispatchers.IO) {
            Log.e(TAG, "Starting Polling")
            while (true) {
                synchronized(commandQueue) {
                    if (!commandQueue.isEmpty()) {
                        commandQueue.poll()?.let { qItem ->
                            qItem("This is input")
                        }
                    }
                }
            }
        }
    }

添加任务函数addItemToQueue #

fun addItemToQueue(item: (input: String) -> Unit) {
    Log.e(TAG, "Added Item ->> $item")
    commandQueue.add(item)
}

调用场景 #

在MainActivity.kt、onConnectionStateChange、onServicesDiscovered和onCharacteristicChanged方法中调用addItemToQueue，部分场景使用了GlobalScope。

现有队列响应迟缓的核心原因 #

1. 无意义的忙轮询：while(true)的无限循环会持续占用CPU资源，即使队列空也不会休眠，导致线程资源被浪费，真正有任务时的响应优先级被降低。
2. 冗余的锁操作：ConcurrentLinkedQueue本身是线程安全的，额外的synchronized块会增加锁竞争开销，拖慢并发场景下的任务处理速度。
3. 阻塞式任务执行：如果队列中的任务是耗时操作（比如BLE通信读取BPM数据），直接在轮询线程中执行会阻塞后续任务的处理，造成队列积压。
4. GlobalScope的滥用：不受生命周期管理的协程可能导致任务执行时机混乱，甚至引发内存泄漏，间接影响队列的响应效率。

更高效的替代方案：Kotlin Channel #

Kotlin Channel是为协程通信设计的FIFO队列，完美适配串行任务执行场景，相比ConcurrentLinkedQueue有以下关键优势：

• 自带挂起等待机制，队列空时自动挂起协程，不会占用闲置CPU；
• 天然线程安全，无需手动加锁；
• 支持背压处理，可避免任务过度积压；
• 配合协程挂起特性，耗时任务不会阻塞线程。

基于Channel的实现示例 #

// 定义任务通道，UNLIMITED支持无限制任务积压（可根据业务调整为BUFFERED）
private val commandChannel = Channel<(input: String) -> Unit>(Channel.UNLIMITED)

// 启动协程串行处理任务
private fun setupChannelProcessing() {
    viewModelScope.launch(Dispatchers.IO) {
        // 自动遍历通道任务，空队列时自动挂起
        for (task in commandChannel) {
            try {
                task("This is input")
                // 若任务是挂起函数，直接调用即可，不会阻塞线程
            } catch (e: Exception) {
                Log.e(TAG, "Task execution failed", e)
            }
        }
    }
}

// 向通道添加任务
fun addItemToQueue(item: (input: String) -> Unit) {
    Log.e(TAG, "Added Item ->> $item")
    viewModelScope.launch {
        commandChannel.send(item)
    }
}

额外优化建议 #

• 彻底替换GlobalScope，统一使用viewModelScope或lifecycleScope管理协程，确保任务生命周期与组件同步；
• 将BLE相关的耗时任务定义为挂起函数，配合Dispatchers.IO执行，避免阻塞任务处理线程；
• 根据业务场景调整Channel容量（比如Channel.BUFFERED），平衡任务积压需求与内存占用。

内容的提问来源于stack exchange，提问作者Compose Learner