Android音乐应用中GlobalScope.launch与CoroutineScope选型疑问

核心前提说明 #

你当前用到的GlobalScope.launch和CoroutineScope(Dispatchers.IO).launch本质上都是无绑定生命周期的全局独立作用域，默认没有父Job管控，不会跟随组件生命周期自动取消，这也是你运行时没有感知到差异的核心原因。两种写法都不符合Android平台协程的最佳实践，具体场景的选择和优化方案如下：

场景1：Service通知更新逻辑 #

现有两种实现的问题 #

不管是用GlobalScope还是临时创建的CoroutineScope，单次执行的通知更新协程都没有绑定Service的生命周期：如果协程执行过程中Service已经销毁，协程仍然会持有notificationManager、mediaSession等Service成员的引用，造成短时间内存泄漏。
如果buildNotification没有 heavy IO 操作，notificationManager.notify本身支持在主线程直接调用，完全不需要指定Dispatchers.IO。

最优方案 #

在Service内部初始化一个绑定生命周期的私有作用域：

private val serviceScope = CoroutineScope(Dispatchers.Main.immediate + SupervisorJob())

在Service的onDestroy回调中调用serviceScope.cancel()，自动销毁所有该作用域下未完成的协程。后续所有Service内的协程都通过serviceScope.launch启动即可。

二选一推荐 #

如果只能在你给出的两种写法中选择，优先选CoroutineScope(Dispatchers.IO).launch：GlobalScope是全应用级的全局作用域，所有用GlobalScope启动的协程无法统一追踪、批量管控，自定义的CoroutineScope可以按需持有引用，后续要统一取消也更方便。

场景2：播放进度轮询逻辑 #

现有两种实现的问题 #

该场景是长时间运行的循环协程，用无绑定的作用域风险极高：如果Service销毁时没有将state改为BIND_STATE_CANCELED，协程会一直在后台无限循环执行，长期持有mediaMediaConnection等组件引用，会造成严重的内存泄漏、后台耗电问题，甚至触发ANR。
另外如果update()方法是更新UI的操作，指定Dispatchers.IO的话会触发子线程更新UI的崩溃，需要切换到主线程执行。

最优方案 #

直接用前面提到的Service绑定生命周期的serviceScope启动协程，Service销毁时协程会被自动取消，不需要完全依赖state的判断做退出兜底。如果有耗时操作可以在协程内部用withContext(Dispatchers.IO)切换线程。

二选一推荐 #

同样优先选CoroutineScope(Dispatchers.IO).launch，你可以将该作用域的实例保存为成员变量，在不需要轮询的时候主动调用scope.cancel()终止协程，比不受控的GlobalScope安全性更高。

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