CoroutineScope和withContext之间的Kotlin差异

如何解决CoroutineScope和withContext之间的Kotlin差异

要更改函数中的线程，请使用CoroutineScope或withContext。我不知道有什么区别，但是有了CourineScope，我还可以使用处理程序。

示例：

private fun removeViews(){
    CoroutineScope(Main).launch(handler){
        gridRoot.removeAllViews()
    }
}

private suspend fun removeViews(){
    withContext(Main){
        gridRoot.removeAllViews()
    }
}

我从在后台线程（IO）上运行的协程调用此函数。有没有比其他合适的了？

解决方法

这两个实际上是根本不同的，并且您碰巧遇到了一个用例，而您并没有遇到不同：

CoroutineScope(Main).launch(handler){

这将启动并发的协程，该协程独立进行。

withContext(Main){

此函数仅在其中的代码完成时才完成，并返回其结果。这是您应该进行的方式。

第一种使用CoroutineScope的方法的另一个缺点是，它规避了结构化并发。您创建的临时协同作用域没有父级，因此如果需要较长时间才能完成并且GUI被删除（用户导航离开当前的Activity），它将不会自动清除。

您实际上应该永远不要使用CoroutineScope(Main)惯用语，我认为没有一个合适的实例。如果您明确希望避免结构化并发，那么编写更好，更干净的

GlobalScope.launch(Main + handler) {

效果差不多。

如果您想要适合结构化并发的并发协程，请使用

fun CoroutineScope.removeViews() {
    launch {
        gridRoot.removeAllViews()
    }
}

请注意，我删除了handler参数，子协程程序将忽略它，因为它会将所有失败转发给其父协程程序，这正是您想要的。父协程应该安装一个异常处理程序。

从技术上讲，它们是相同的，但是在用例方面，它们是不同的，并且对不同的用例都有很大的影响，因此在使用它们时要小心
协程范围：
CoroutineScope是Coroutine的起点。 CoroutineScope自身内部可以具有多个协程，这构成了协程层次结构。让我们想想，父母有多个孩子。假设CoroutineScope是父母，那么这个父母可以有多个孩子（也是协程）。这些孩子被称为job

private val coroutineScope = CoroutineScope()
    coroutineScope(IO).launch{
    val childOne = launch(Main){}
   val childTwo = launch(Main){}
}

看到那个childOne和childTwo吗？为什么我们需要这些？因为我们不能直接取消协程，所以无法直接取消协程，无论协程完成还是失败。但是，如果我们想取消该怎么办？在这种情况下，我们需要job。但是要注意的是，这些作业children与父级完全相关。父级是（IO），子级是（Main），此父级是在IO Disptacher中启动的，但是当涉及到这些子级时，他们将切换到（Main）并做他们的事情，但父级仍将处于（IO）切换孩子的调度员不会影响父母。
但是，如果两个孩子中的任何一个发生了问题，该怎么办？在这种情况下，我们将观看这次峰会：
https://www.youtube.com/watch?v=w0kfnydnFWI
本次峰会涉及协程异常和取消。看着它，令人惊叹...
withContext：
什么是Context？
withContext应该在任何Coroutine或suspend fun内，因为withContext本身是一个暂停函数。
withContext用于在不同情况下切换上下文
但是如何？


suspend fun fetchFromNetworkAndUpdateUI() {
    withContext(IO){
        println("Some Fake data from network")
    }
    
    withContext(Main){
        //updating Ui
        //setting that Data to some TextView etc
    }
    
}

参见代码，我们正在从网络异步获取数据，因为我们不想阻塞MainThread，然后我们切换上下文，为什么？因为我们无法在IoDispatcher中更新与UI相关的内容，因为我们已使用main将上下文更改为withContext(main){}并更新了UI。
并且还有其他诸如liveData的用例，我们正在使用IoDispatcher进行改造以获取值，然后在下一步中，我们必须使用withContext(main){}将其设置为liveData，因为我们无法在后台线程中观察liveData的值。 br /> 是的，我希望这会有所帮助。如有任何问题，请发表评论。

摘自Antonio Leiva article关于协程的信息：

协程上下文是一组定义以下内容的规则和配置协程将如何执行

withContext是一项函数，可让您轻松更改挂起函数的context，以确保该函数在特定线程（例如，来自IO池的线程）中执行。为此，您可以强制挂起函数在特定线程池中执行其主体，例如：

suspend fun getAuthenticationStatus(): AuthenticationStatus = withContext(Dispatchers.IO) {
    when (val result = repository.getAuthenticationStatus()) {
        is Result.Success -> result.data
        is Result.Error -> AuthenticationStatus.Unauthorized
    }
}

这样，即使您是从UI范围（MainScope）调用此挂起函数，也可以100％确保在工作线程中执行了该挂起函数，并且可以在返回的结果中更新UI。主线程，例如：

MainScope().launch {
            userIdentityVM.getAuthenticationStatus().run {
                when (this) {
                    is AuthenticationStatus.Authenticated -> {
                       // do something
                    }
                    is AuthenticationStatus.Unauthorized -> {
                       // do something else
                    }
                }
            }
        }

总而言之，通过使用withContext，您可以将挂起功能设置为“主保险箱” 。

scope和context之间的区别基本上是预期的目的。要启动协程，通常使用launch协程构建器，该构建器定义为CoroutineScope上的扩展功能。

fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,// ...
): Job

在协程范围中指定为参数的上下文通过加号运算符合并到协程范围，并且在由协程范围指定的“默认”上下文中优先” 。这样，您可以在“父”上下文中执行代码。要深入了解，我建议您this article，作者是Roman Elizarov（科特林图书馆@JetBrains的团队负责人）。

CoroutineScope和withContext之间的Kotlin差异

如何解决CoroutineScope和withContext之间的Kotlin差异

解决方法

相关推荐