Skip to content

Commit d8222bd

Browse files
committed
《基础》:scope => 作用域,builder => 构建器
1 parent 7e31d4c commit d8222bd

File tree

1 file changed

+14
-14
lines changed

1 file changed

+14
-14
lines changed

docs/basics.md

+14-14
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ class BasicsGuideTest {
2525
* [桥接阻塞和非阻塞的世界](#bridging-blocking-and-non-blocking-worlds)
2626
* [等待一个任务](#waiting-for-a-job)
2727
* [结构性的并发](#structured-concurrency)
28-
* [范围建造器](#scope-builder)
28+
* [作用域建造器](#scope-builder)
2929
* [提取函数重构](#extract-function-refactoring)
3030
* [协程是轻量级的](#coroutines-are-light-weight)
3131
* [像守护线程一样的全局协程](#global-coroutines-are-like-daemon-threads)
@@ -70,7 +70,7 @@ World!
7070
<!--- TEST -->
7171

7272
本质上,协程是轻量级的线程。
73-
它们在 [CoroutineScope] 上下文中和 [launch] _协同构造器_ 一起被启动。
73+
它们在 [CoroutineScope] 上下文中和 [launch] _协同构建器_ 一起被启动。
7474
这里我们在 [GlobalScope] 中启动了一些新的协程, 存活时间是指新的<!--
7575
-->协程的存活时间被限制在了整个应用的存活时间之内。
7676

@@ -90,7 +90,7 @@ Error: Kotlin: Suspend functions are only allowed to be called from a coroutine
9090

9191
第一个例子中在相似的代码中包含了 _非阻塞的_ `delay(...)`_阻塞的_ `Thread.sleep(...)`
9292
它非让容易的让我们看出来哪一个是阻塞的,哪一个是非阻塞的。
93-
来一起使用明确的阻塞 [runBlocking] 协程构造器
93+
来一起使用明确的阻塞 [runBlocking] 协程构建器
9494

9595
<div class="sample" markdown="1" theme="idea" data-min-compiler-version="1.3">
9696

@@ -217,12 +217,12 @@ World!
217217

218218
这有一个更好的解决办法。我们可以在你的代码中使用结构性并发。
219219
用来代替在 [GlobalScope] 中启动协程,就像我们使用线程时那样(线程总是全局的),
220-
我们可以在一个具体的范围中启动协程并操作
220+
我们可以在一个具体的作用域中启动协程并操作
221221

222-
在我们的例子中, 我们有一个被转换成使用[runBlocking]的协程构造器的`main`函数
223-
每一个协程构造器, 包括`runBlocking`, 添加了一个实例在[CoroutineScope]范围的代码块中.
224-
我们可以在一个协程还没有明确的调用`join`之前在这个范围内启动它们, 因为一个外部的协程
225-
(我们的例子中的`runBlocking`) 没有在所有的协程在它们的范围内启动完成后执行<!--
222+
在我们的例子中, 我们有一个被转换成使用[runBlocking]的协程构建器的`main`函数
223+
每一个协程构建器, 包括`runBlocking`, 添加了一个实例在[CoroutineScope]作用域的代码块中.
224+
我们可以在一个协程还没有明确的调用`join`之前在这个作用域内启动它们, 因为一个外部的协程
225+
(我们的例子中的`runBlocking`) 没有在所有的协程在它们的作用域内启动完成后执行<!--
226226
-->完毕, 从而, 我们可以使我们的例子更简单:
227227

228228
<div class="sample" markdown="1" theme="idea" data-min-compiler-version="1.3">
@@ -248,9 +248,9 @@ Hello,
248248
World!
249249
-->
250250

251-
### 范围构造器
252-
除了由不同的构造器提供的协程范围,也是可以使用 [coroutineScope] 构造器来声明你自己<!--
253-
-->的范围。它启动了一个新的协程范围并且在所有子协程执行结束后并没有执行<!--
251+
### 作用域构建器
252+
除了由不同的构建器提供的协程作用域,也是可以使用 [coroutineScope] 构建器来声明你自己<!--
253+
-->的作用域。它启动了一个新的协程作用域并且在所有子协程执行结束后并没有执行<!--
254254
-->完毕。[runBlocking][coroutineScope] 主要的不同之处在于后者在等待所有的子协程<!--
255255
-->执行完毕时并没有使当前线程阻塞.
256256

@@ -265,7 +265,7 @@ fun main() = runBlocking { // this: CoroutineScope
265265
println("Task from runBlocking")
266266
}
267267

268-
coroutineScope { // 创建一个新的协程范围
268+
coroutineScope { // 创建一个新的协程作用域
269269
launch {
270270
delay(500L)
271271
println("Task from nested launch")
@@ -324,13 +324,13 @@ World!
324324
-->
325325

326326

327-
但是如果提取函数包含了一个调用当前范围的协程构造器
327+
但是如果提取函数包含了一个调用当前作用域的协程构建器
328328
在这个例子中仅仅使用 `suspend` 来修饰提取出来的函数是不够的. 在 `CoroutineScope` 调用 `doWorld` 方法
329329
是一种解决方案, 但它并非总是适用, 因为它不会使API看起来更清晰。
330330
惯用的解决方法是使 `CoroutineScope` 在一个类中作为一个属性并包含一个目标函数,
331331
或者使它外部的类实现 `CoroutineScope` 接口。
332332
作为最后的手段,[CoroutineScope(coroutineContext)][CoroutineScope()] 也是可以使用的,但是这样的结构是不安全的
333-
因为你将无法在这个范围内控制方法的执行。只有私有的API可以使用这样的写法。
333+
因为你将无法在这个作用域内控制方法的执行。只有私有的API可以使用这样的写法。
334334

335335
### 协程是轻量级的
336336

0 commit comments

Comments
 (0)