@@ -25,7 +25,7 @@ class BasicsGuideTest {
25
25
* [ 桥接阻塞和非阻塞的世界] ( #bridging-blocking-and-non-blocking-worlds )
26
26
* [ 等待一个任务] ( #waiting-for-a-job )
27
27
* [ 结构性的并发] ( #structured-concurrency )
28
- * [ 范围建造器 ] ( #scope-builder )
28
+ * [ 作用域建造器 ] ( #scope-builder )
29
29
* [ 提取函数重构] ( #extract-function-refactoring )
30
30
* [ 协程是轻量级的] ( #coroutines-are-light-weight )
31
31
* [ 像守护线程一样的全局协程] ( #global-coroutines-are-like-daemon-threads )
70
70
<!-- - TEST -->
71
71
72
72
本质上,协程是轻量级的线程。
73
- 它们在 [ CoroutineScope] 上下文中和 [ launch] _ 协同构造器 _ 一起被启动。
73
+ 它们在 [ CoroutineScope] 上下文中和 [ launch] _ 协同构建器 _ 一起被启动。
74
74
这里我们在 [ GlobalScope] 中启动了一些新的协程, 存活时间是指新的<!--
75
75
-->协程的存活时间被限制在了整个应用的存活时间之内。
76
76
@@ -90,7 +90,7 @@ Error: Kotlin: Suspend functions are only allowed to be called from a coroutine
90
90
91
91
第一个例子中在相似的代码中包含了 _ 非阻塞的_ ` delay(...) ` 和 _ 阻塞的_ ` Thread.sleep(...) ` 。
92
92
它非让容易的让我们看出来哪一个是阻塞的,哪一个是非阻塞的。
93
- 来一起使用明确的阻塞 [ runBlocking] 协程构造器 :
93
+ 来一起使用明确的阻塞 [ runBlocking] 协程构建器 :
94
94
95
95
<div class =" sample " markdown =" 1 " theme =" idea " data-min-compiler-version =" 1.3 " >
96
96
@@ -217,12 +217,12 @@ World!
217
217
218
218
这有一个更好的解决办法。我们可以在你的代码中使用结构性并发。
219
219
用来代替在 [ GlobalScope] 中启动协程,就像我们使用线程时那样(线程总是全局的),
220
- 我们可以在一个具体的范围中启动协程并操作 。
220
+ 我们可以在一个具体的作用域中启动协程并操作 。
221
221
222
- 在我们的例子中, 我们有一个被转换成使用[ runBlocking] 的协程构造器的 ` main ` 函数
223
- 每一个协程构造器 , 包括` runBlocking ` , 添加了一个实例在[ CoroutineScope] 范围的代码块中 .
224
- 我们可以在一个协程还没有明确的调用` join ` 之前在这个范围内启动它们 , 因为一个外部的协程
225
- (我们的例子中的` runBlocking ` ) 没有在所有的协程在它们的范围内启动完成后执行 <!--
222
+ 在我们的例子中, 我们有一个被转换成使用[ runBlocking] 的协程构建器的 ` main ` 函数
223
+ 每一个协程构建器 , 包括` runBlocking ` , 添加了一个实例在[ CoroutineScope] 作用域的代码块中 .
224
+ 我们可以在一个协程还没有明确的调用` join ` 之前在这个作用域内启动它们 , 因为一个外部的协程
225
+ (我们的例子中的` runBlocking ` ) 没有在所有的协程在它们的作用域内启动完成后执行 <!--
226
226
-->完毕, 从而, 我们可以使我们的例子更简单:
227
227
228
228
<div class =" sample " markdown =" 1 " theme =" idea " data-min-compiler-version =" 1.3 " >
@@ -248,9 +248,9 @@ Hello,
248
248
World!
249
249
-->
250
250
251
- ### 范围构造器
252
- 除了由不同的构造器提供的协程范围 ,也是可以使用 [ coroutineScope] 构造器来声明你自己 <!--
253
- -->的范围。它启动了一个新的协程范围并且在所有子协程执行结束后并没有执行 <!--
251
+ ### 作用域构建器
252
+ 除了由不同的构建器提供的协程作用域 ,也是可以使用 [ coroutineScope] 构建器来声明你自己 <!--
253
+ -->的作用域。它启动了一个新的协程作用域并且在所有子协程执行结束后并没有执行 <!--
254
254
-->完毕。[ runBlocking] 和 [ coroutineScope] 主要的不同之处在于后者在等待所有的子协程<!--
255
255
-->执行完毕时并没有使当前线程阻塞.
256
256
@@ -265,7 +265,7 @@ fun main() = runBlocking { // this: CoroutineScope
265
265
println (" Task from runBlocking" )
266
266
}
267
267
268
- coroutineScope { // 创建一个新的协程范围
268
+ coroutineScope { // 创建一个新的协程作用域
269
269
launch {
270
270
delay(500L )
271
271
println (" Task from nested launch" )
@@ -324,13 +324,13 @@ World!
324
324
-->
325
325
326
326
327
- 但是如果提取函数包含了一个调用当前范围的协程构造器 ?
327
+ 但是如果提取函数包含了一个调用当前作用域的协程构建器 ?
328
328
在这个例子中仅仅使用 ` suspend ` 来修饰提取出来的函数是不够的. 在 ` CoroutineScope ` 调用 ` doWorld ` 方法
329
329
是一种解决方案, 但它并非总是适用, 因为它不会使API看起来更清晰。
330
330
惯用的解决方法是使 ` CoroutineScope ` 在一个类中作为一个属性并包含一个目标函数,
331
331
或者使它外部的类实现 ` CoroutineScope ` 接口。
332
332
作为最后的手段,[ CoroutineScope(coroutineContext)] [ CoroutineScope() ] 也是可以使用的,但是这样的结构是不安全的
333
- 因为你将无法在这个范围内控制方法的执行 。只有私有的API可以使用这样的写法。
333
+ 因为你将无法在这个作用域内控制方法的执行 。只有私有的API可以使用这样的写法。
334
334
335
335
### 协程是轻量级的
336
336
0 commit comments