| 类型 | 产生方式 | 异常传播特征 |
| — | — | — |
| 顶级作用域 | GlobalScope创建 | 异常不向外传播。异常到达顶级作用域后,如果还没有被处理,会抛给当前的exceptionHandler,如果没有则给当前线程的uncaughtExceptionHandler |
| 协同作用域 | Job嵌套、coroutineScope创建 | 异常双传播。异常会向上向下双向传播。 |
| 主从作用域 | 可通过supervisorScope创建,另外MainScope和lifecycleScope内部设置了 | 异自上而下单项传播。父协程不去受理子协程产生的异常。但是一旦父布局出现了异常,则会直接取消子协程。 |
相关引用,kotlin协程库这里使用的版本是:1.4.2,可点击查看了解目前自己当前kotlin版本对应的协程库版本。
project.ext.kotlin_coroutines_version = “1.4.2”
//kotlin协程标准库 GlobalScope
implementation “org.jetbrains.kotlinx:kotlinx-coroutines-core:$kotlin_coroutines_version”
//kotlin协程Android支持 MainScope()
implementation “org.jetbrains.kotlinx:kotlinx-coroutines-android:$kotlin_coroutines_version”
//lifecycle
implementation “androidx.lifecycle:lifecycle-runtime-ktx:2.3.0”
GlobalScope继承自CoroutineScope。
kotlin协程标准库里面是没有MainScope以及lifecycleScope这些花里胡哨的东西的😯,一般使用GlobalScope.launch来启动协程即可。
val job = GlobalScope.launch {
// TODO: 2021/8/29 do
}
使用launch启动可以设置启动模式,调度器以及异常处理器Handler,如下所示:
val coroutineExceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
throwable.printStackTrace()
}
val job = GlobalScope.launch(
Dispatchers.Main + coroutineExceptionHandler,
CoroutineStart.DEFAULT
) {
// TODO: 2021/8/29 do
}
调度器
| 调度器 | 线程,使用场景 |
| — | — |
| Default | 线程池,适合cpu密集的操作,比如计算 |
| Main | UI线程 比如计算 |
| Io | 线程池,适合io操作,比如网络请求等 |
| Unconfined | 不调度,直接执行。最后执行的线程取决于挂起函数恢复的时候的调度器 |
异常拦截器
设置方式,如上图所示,如果运行过程中挂起函数或者协程体体内部抛出异常(没有被处理),则会最终调用到异常拦截器。
协同作用域首先会看父协程是否处理异常,如果不处理才检查自己是否存在异常处理器等操作。同时会将异常下自己的子协程传递,取消子协程的进行。
顶级作用域会直接进行检查自己是否存在异常处理器等操作。
主从作用域其实就是协同作用域,但是它默认不处理子协程的异常,所以子协程只能处理,则就显示出,异常向下传播的镜像。不会影响自己的其他执行模块。比较适用于UI驱动的程序。比如说Android。
启动模式
| 启动模式 | 功能特性 |
| — | — |
| DEFAULT | 立即开始调度协程体,调度前若取消则直接取消 |
| ATOMIC | 立即开始调度协程体,直到第一个挂起点之前不能取消 |
| LAZY | 只有在需要(start/join/await)时才开始调度。其实创建协程有两种方式,一种是createCoroutine().resume(Unit);另一种是startCoroutine()内部调用了resume。而对于lazy的模式来说是先调用了createCoroutine,然后在需要的时候调用了resume启动协程 |
| UNDISPATCHED | 立即在当前协程执行协程体,知道遇到第一个挂起点(后续的执行线程取决于挂起点恢复执行时候的调度器) |
好了,现在说一说GlobalScope的问题🙄。
-
如果是Android基本都要调度到主线程进行操作,但是GlobalScope.launch默认的调度器是Default。每次都要显示的写Main不是很方便。
-
上面也说到了Android这种UI驱动的程序,比较适合主从作用域,但是GlobalScope是顶级作用域。那有人就说了supervisorScope启动的不是主从作用域吗?但是supervisorScope是一个挂起函数(可自行查看源码。其实是内部引用了一个私有的SupervisorCoroutine类,继承自ScopeCoroutine。重写了childCancelled方法,就干了一件事,返回了false。简单来说就是不处理子协程的异常🤦♀️,这可忒不负责任了😢)。如果要调用supervisorScope必须要在一个协程或者挂起函数内。啊 ~ 这。那我不得先启动一个协程?😅
-
还要一个问题,内存泄漏的问题。需要在页面销毁的适合取消掉当前协程。对于GlobalScope来说,就必须进行手动调用cancel的操作了。emmm,这波操作不仅麻烦而且危险(万一忘了取消咋整)!
先看一下源码:
public fun MainScope(): CoroutineScope = ContextScope(SupervisorJob() + Dispatchers.Main)
老话说得好啊,柿子的挑软的捏!Dispatchers.Main 好嘛!默认调度器是主线程,解决了上面说的第一个问题。
那SupervisorJob()是个啥呢?再进一步看看
public fun SupervisorJob(parent: Job? = null) : CompletableJob = SupervisorJobImpl(parent)
private class SupervisorJobImpl(parent: Job?) : JobImpl(parent) {
override fun childCancelled(cause: Throwable): Boolean = false
}
emm,结局显而易见。顺着方法一路点进去,发现了一个重写的childCancelled返回了false。还记得上面我写的supervisorScope简要分析吗?supervisorScope不就是也只干了这么个事情嘛😂。所以说这玩意其实也是一个主从作用域。解决了第二个问题。
顺手提一嘴,会不会有什么好奇为什么SupervisorJob() + Dispatchers.Main以及上面刚开始写的Dispatchers.Main + coroutineExceptionHandler,是个什么鬼,为什么可以加呢。其实调度器和异常处理器它就是CoroutineContext;而作用域接口内部就一个常量就是CoroutineContext。CoroutineContext是什么呢?这玩意就是协程上下文。说白了就是一个集合。在协程内部操作的过程中调度器、异常处理都是从CoroutineContext里面取的,包括作用域分发异常,也是从上下文中取得得父子协程。为什么可以加呢?因为内部重写了operator fun plus操作符,所以能进行加的操作(理解为集合即可,想要具体了解可以考虑撸一波源码😴)。
那好像就剩下生命周期没有解决了。再去瞅瞅Android对lifecycleScope做了什么封装吧!
emm,看源码
public val LifecycleOwner.lifecycleScope: LifecycleCoroutineScope
get() = lifecycle.coroutineScope
返回了LifecycleCoroutineScope,而LifecycleCoroutineScope可以启动协程,所以肯定是CoroutineScope作用域的子类。另外receiver是LifecycleOwner,所以先猜测:应该是绑定了Android的声明周期了。
public val Lifecycle.coroutineScope: LifecycleCoroutineScope
get() {
while (true) {
val existing = mInternalScopeRef.get() as LifecycleCoroutineScopeImpl?
if (existing != null) {
return existing
}
val newScope = LifecycleCoroutineScopeImpl(
this,
SupervisorJob() + Dispatchers.Main.immediate
)
if (mInternalScopeRef.compareAndSet(null, newScope)) {
newScope.register()
return newScope
}
}
}
本着带着问题看源码的思维,直接忽略掉那些CAS的操作。简单分析一波。返回了LifecycleCoroutineScopeImpl对象,而LifecycleCoroutineScopeImpl是LifecycleCoroutineScope类型的。所以重点就是LifecycleCoroutineScopeImpl了!
仔细看LifecycleCoroutineScopeImpl传入了this以及SupervisorJob() + Dispatchers.Main.immediate。this不就是生命周期Lifecycle嘛。而SupervisorJob()上面已经分析过了,成为主从作用域。Dispatchers.Main.immediate就是切换到主线程。那可能有人就会问题了,immediate是个什么鬼,别着急。先分析完主流程。其他的写在后面感兴趣的话可以看看。
下面看看LifecycleCoroutineScopeImpl的实现源码!
internal class LifecycleCoroutineScopeImpl(
override val lifecycle: Lifecycle,
override val coroutineContext: CoroutineContext
) : LifecycleCoroutineScope(), LifecycleEventObserver {
init {
if (lifecycle.currentState == Lifecycle.State.DESTROYED) {
coroutineContext.cancel()
}
}
fun register() {
launch(Dispatchers.Main.immediate) {
if (lifecycle.currentState >= Lifecycle.State.INITIALIZED) {
lifecycle.addObserver(this@LifecycleCoroutineScopeImpl)
} else {
coroutineContext.cancel()
}
}
}
override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
if (lifecycle.currentState <= Lifecycle.State.DESTROYED) {
lifecycle.removeObserver(this)
coroutineContext.cancel()
}
}
}
方便上面的分析,放上生命周期状态枚举类。DESTROYED的ordinal就是0,RESUMED的ordinal就是4。枚举可以直接使用ordinal比较大小。
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
构造LifecycleCoroutineScopeImpl的时候判断一波,如果当前是DESTROYED直接取消协程。
剩下就两个函数,register()和onStateChanged(source: LifecycleOwner, event: Lifecycle.Event)。
**register()**在创建LifecycleCoroutineScopeImpl的时候调用了一下(可以看上面的源码)。简单来说将当前注册进了生命周期观察者当中。
onStateChanged():每次生命周期变化的时候被调用(不了解的可以自行了解一波lifecycle)。每次都判断如果当前生命周期 在DESTROYED之后就取消掉协程,同时移除观察者! 破案了!!!
所以 lifecycleScope 完美解决了 上面说的GlobalScope的问题。不仅方便还安全!!!
lifecycleScope剩余问题分析(感兴趣的可以继续看)
lifecycleScope虽然比较方便且不用担心内存泄漏的问题!但是是有使用限制的。网上大部分都说lifecycleScope 只能在Activity、Fragment中使用其实是不太准确的。上面分析了一下lifecycleScope是LifecycleOwner的扩展函数,receiver是LifecycleOwner。因为Activity、Fragment和默认绑定了LifecycleOwner所以可以直接使用。但是理论上来说 只要是能获取到LifecycleOwner的地方都是可以使用lifecycleScope的!
LifecycleCoroutineScope
public abstract class LifecycleCoroutineScope internal constructor() : CoroutineScope {
internal abstract val lifecycle: Lifecycle
public fun launchWhenCreated(block: suspend CoroutineScope.() -> Unit): Job = launch {
lifecycle.whenCreated(block)
}
public fun launchWhenStarted(block: suspend CoroutineScope.() -> Unit): Job = launch {
lifecycle.whenStarted(block)
}
public fun launchWhenResumed(block: suspend CoroutineScope.() -> Unit): Job = launch {
lifecycle.whenResumed(block)
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![](https://i-blog.csdnimg.cn/blog_migrate/c034dbfed09354fbae0069bf105312f1.jpeg)
总结
首先是感觉自己的基础还是不够吧,大厂好像都喜欢问这些底层原理。
另外一部分原因在于资料也还没有看完,一面时凭借那份资料考前突击恶补个几天居然也能轻松应对(在这里还是要感谢那份资料,真的牛),于是自我感觉良好,资料就没有怎么深究下去了。
之前的准备只涉及了Java、Android、计网、数据结构与算法这些方面,面对面试官对其他基础课程的考察显得捉襟见肘。
下一步还是要查漏补缺,进行针对性复习。
最后的最后,那套资料这次一定要全部看完,是真的太全面了,各个知识点都涵盖了,几乎我面试遇到的所有问题的知识点这里面都有!希望大家不要犯和我一样的错误呀!!!一定要看完!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
能轻松应对(在这里还是要感谢那份资料,真的牛),于是自我感觉良好,资料就没有怎么深究下去了。
之前的准备只涉及了Java、Android、计网、数据结构与算法这些方面,面对面试官对其他基础课程的考察显得捉襟见肘。
下一步还是要查漏补缺,进行针对性复习。
最后的最后,那套资料这次一定要全部看完,是真的太全面了,各个知识点都涵盖了,几乎我面试遇到的所有问题的知识点这里面都有!希望大家不要犯和我一样的错误呀!!!一定要看完!
[外链图片转存中…(img-dRyj3t2w-1713390830560)]
[外链图片转存中…(img-DQsr7JnO-1713390830561)]
[外链图片转存中…(img-KIwisx1Q-1713390830562)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!