as怎么用

as的用法如下：

1、as作副词，表示程度，意为“同样地”。在“as…as…”，“not-as…as…”结构中的第一个as是副词，作“和／与…（不）一样”解。

2、as作介词。作“如，像”解。或者为“充当，作为”。

3、as作连词，常用来连接主句和状语从句。引导时间状语从句：作“当…的时候”解，有“随着…”之意，与while意义相近，强调两个动作同时发生；或某事一发生，另一事立即发生。

4、引导原因状语从句：作“因为，由于”解，与because的用法相近。引导方式状语从句或比较状语从句：作“正如，（如）像”解。引导让步状语从句：作“虽然，尽管”解。这时从句常用倒装语序，即把从句中的表语、状语或动词原形放在as之前。

5、as作关系代词。引导限制性定语从句：用在“such…as”，“the-same…as”，“as…as”等结构中，常译作“像…一样的人（或物）”，“凡是…的人（或物）”。引导非限制性定语从句：用来指代它前面的整个句子。这个分句可以位于句首、句中或句末。

协程总是运行在⼀些以 CoroutineContext 类型为代表的上下文中，它们被定义在了 Kotlin 的标准库里。协程上下文是各种元素的集合，其中主要元素是协程中的Job（前面提到lanch和async都会返回一个job）

协程上下文包含⼀个协程调度器（参见 CoroutineDispatcher）它确定了相关的协程在哪个线程或哪些线程上执行。协程调度器可以将协程限制在⼀个特定的线程执行，或将它分派到⼀个线程池，亦或是让它不受限地运行。
所有的协程构建器诸如 launch 和 async 接收⼀个可选的 CoroutineContext 参数，它可以被用来显式的为⼀个新协程或其它上下文元素指定⼀个调度器。

DispatchersUnconfined 协程调度器在调用它的线程启动了⼀个协程，但它仅仅只是运行到第⼀个挂起点。挂起后，它恢复线程中的协程，而这完全由被调用的挂起函数来决定。非受限的调度器非常适用于执行不消耗 CPU 时间的任务，以及不更新局限于特定线程的任何共享数据（如UI）的协程。 另⼀方面，该调度器默认继承了外部的 CoroutineScope。runBlocking 协程的默认调度器，特别是，当它被限制在了调用者线程时，继承自它将会有效地限制协程在该线程运行并且具有可预测的 FIFO 调度。
所以该协程的上下文继承自 runBlocking {} 协程并在 main 线程中运行，当 delay 函数调用的时候，非受限的那个协程在默认的执行者线程中恢复执行

协程可以在⼀个线程上挂起并在其它线程上恢复。如果没有特殊工具，甚至对于⼀个单线程的调度器也是难以弄清楚协程在何时何地正在做什么事情。

让线程在每⼀个日志文件的日志声明中打印线程的名字,用log函数就行

协程可在不同的线程中跳转。使用 runBlocking 来显式指定了⼀个上下文，并且另⼀个使用 withContext 函数来改变协程的上下文，而仍然驻留在相同的协程中。不需要某个在 newSingleThreadContext 中创建的线程的时候，使用 use 函数来释放该线程。

协程的 Job 是上下文的⼀部分，并且可以使用 coroutineContext [Job] 表达式在上下文中检索它。CoroutineScope 中的 isActive 只是 coroutineContext[Job]isActive == true 的⼀种方便的快捷方式。（在协程取消时有提到，使计算协程可退出）

当⼀个协程被其它协程在 CoroutineScope 中启动的时候，它将通过 CoroutineScopecoroutineContext 来承袭上下文，并且这个新协程的 Job 将会成为父协程作业的子作业。当⼀个父协程被取消的时候，所有它的子协程也会被递归的取消。
当使用 GlobalScope 来启动⼀个协程时，则新协程的作业没有父作业。因此它与这个启动的作用域无关且独立运作。

⼀个父协程总是等待所有的子协程执行结束。父协程并不显式的跟踪所有子协程的启动，并且子协程不必使用 Jobjoin

当协程经常打印日志并且你只需要关联来⾃同⼀个协程的日志记录时，则自动分配的 id 是非常好的。然而，当⼀个协程与特定请求的处理相关联时或做⼀些特定的后台任务，最好将其明确命名以用于调试目的。
CoroutineName 上下文元素与线程名具有相同的目的。当调试模式开启时，它被包含在正在执行此协程的线程名中。

有时我们需要在协程上下文中定义多个元素。我们可以使用 + *** 作符来实现

kotlinxcoroutines 提供了⼀个封装：CoroutineScope 的抽象。所有的协程构建器都声明为在它之上的扩展。
创建⼀个 CoroutineScope 实例来管理协程的生命周期，并使它与 activity 的生命周期相关联。CoroutineScope 可以通过 CoroutineScope() 创建或者通过MainScope() 工厂函数。前者创建了⼀个通用作用域，而后者为使用 DispatchersMain 作为默认调度器的 UI 应用程序创建作用域：

输出：

前三个协程打印了消息，而其它的协程在 Activitydestroy() 调用了 cancel()

ThreadLocal，asContextElement 扩展函数可以将⼀些线程局部数据传递到协程与协程之间。asContextElement 它创建了额外的上下文元素，且保留给定 ThreadLocal 的值，并在每次协程切换其上下文时恢复它。

使用 DispatchersDefault 在后台线程池中启动了⼀个新的协程，所以它工作在线程池中的不同线程中，但它仍然具有线程局部变量的值，我们指定使用 threadLocalasContextElement(value = "launch") ，无论协程执行在哪个线程中都是没有问题的。
threadLocal有⼀个关键限制，即：当⼀个线程局部变量变化时，则这个新值不会传播给协程调用者（因为上下文元素无法追踪所有 ThreadLocal 对象访问），并且下次挂起时更新的值将丢失。使用 withContext 在协程中更新线程局部变量， 详见asContextElement。
输出

类和接口的继承通过 ： 来实现

kotlin 的接口可以包含抽象方法，以及方法的实现，接口可以有属性但必须是抽象的，或者提供访问器的实现，当然java 8 中的接口也支持这些特性了。

在kotlin中定义一个虚类，语法与java相似，在虚类中，可以声明类属性，构造函数，可以只定义方法头，也可以定义个包含方法体的完整方法。

子类在实例化的时候，没有实例化父类，那为什么要调用父类的构造函数呢？主要是为了对字段属性进行初始化。

提出类的继承机制的初衷，大体上处于以下两个方面考虑：

关于类型转换，有两条不成文的规则：

在基于面向接口设计原则开发程序时，必定会发生以下两种转换：

在第二步中，将基类强制转换为子类，是正确的——因为基类变量实际上指向的是子类实例对象
在kotlin中提供的强制转换语法是 as , 判断一个类型是 is （代替了java 中的 instanceof）

kotlin文档经常有用到ThreadcurrentThread()name，打印当前的线程和协程，但是自己测试只能看到线程信息。

输出：

需要在as的VM options中配置-Dkotlinxcoroutinesdebug才能看到

配置后输出：

---