e.printStackTrace()
}
}
我们将loadProjectTreeError和loadProjectTree分别使用try-catch块进行异常捕获，运行结果也正如预期，接口请求互相不影响：
loadProjectTree: error Exception HTTP 404 Not Found
loadProjectTree: com.fuusy.common.network.BaseResp@57e153d
上述为一般状况下处理协程异常的方法，但是在某些情况下，try-catch却也存在捕获不到异常的可能。
1.2 什么情况下try-catch会无效？
正常来说，try-catch块中只有代码块存在异常，都将被捕获到catch中。但是协程中的异常却存在特殊情况。
例如在协程中开启一个失败的子协程，则无法捕获。还是以上面的接口举个例子：
fun loadProjectTree() {
viewModelScope.launch() {
try {
//子协程
launch {
//失败的接口
service.loadProjectTreeError()
}
} catch (e: Exception) {
e.printStackTrace()
}
}
}
在try-catch块中创建了一个子协程，调用了一个百分百会失败的接口，这个时候我们期望的是能将异常捕获至catch中，但是真正运行后却发现App崩溃退出了。这也验证了try-catch作用无效。
至于try-catch为什么在协程中开启一个失败的子协程的情况下会失败？这就不得不提到一个新的知识点，协程的结构化并发。
1.3 什么是协程的结构化并发？
在kotlin的协程中，全局的GlobalScope是一个作用域，每个协程自身也是一个作用域，新建的协程与它的父作用域存在一个级联的关系，也就是一个父子关系层次结构。而这级联关系主要在于：
-
父作用域的生命周期持续到所有子作用域执行完； -
当结束父作用域结束时，同时结束它的各个子作用域； -
子作用域未捕获到的异常将不会被重新抛出，而是一级一级向父作用域传递，这种异常传播将导致父父作用域失败，进而导致其子作用域的所有请求被取消。
上面的三点也就是协程结构化并发的特性。
了解了什么是协程的结构化并发，那我们就又回到try-catch为什么在协程中开启一个失败的子协程的情况下会失败？的问题上。很显然，上面第3点就是这个问题的答案，子协程中未捕获的异常不会被重新抛出，而是在父子层次结构中向上传播，这种异常传播将导致父Job失败。
在这种情况下，我们就应该使用一个新的处理异常的方法：CoroutineExceptionHandler
二、CoroutineExceptionHandler全局捕获异常
除了try-catch外，协程处理异常的第二个方法是使用CoroutineExceptionHandler。
2.1 CoroutineExceptionHandler的介绍
首先我们来了解一下什么是CoroutineExceptionHandler？
这是官方文档中对CoroutineExceptionHandler的解释，起初时我对于这个解释是读不懂的，后面仔细想了想，CoroutineExceptionHandler作为一个全局捕获异常的方式，是由于协程结构化并发的特性的存在，子作用域的异常经过一级一级的传递，最后由CoroutineExceptionHandler进行处理。因为传递到CoroutineExceptionHandler时已经到达顶层作用域，这种情况下，子协程已经结束。也就是说在CoroutineExceptionHandler被调用时，所有子协程已经完成了相应的异常。
2.2 CoroutineExceptionHandler的使用
首先，我们在ViewModel中创建了一个exceptionHandler，
private val exceptionHandler = CoroutineExceptionHandler { _, exception ->
Log.d(TAG, “CoroutineExceptionHandler exception : ${exception.message}”)
}
接着将exceptionHandler附加给viewModelScope。
fun loadProjectTree() {
viewModelScope.launch(exceptionHandler) {
//失败的接口
service.loadProjectTreeError()
}
}
根据协程的结构化并发的特性，当根协程通过launch{}启动时，异常将被传递给已附加的CoroutineExceptionHandler。
2.3 CoroutineExceptionHandler的不足
协程中不使用try-catch，CoroutineExceptionHandler作为全局捕获异常的机制，最后异常会在CoroutineExceptionHandler中处理。但是有两点需要注意：
由于没有try-catch来捕获住异常，异常会向上传播，直到它到达RootScope或SupervisorJob，根据协程的结构化并发的特性，异常向上传播时，父协程会失败，同时父协程所级联的子协程和兄弟协程也都会失败；
如果你想并行请求多个接口，并且需要他们彼此不影响任务的执行，也就是任何一个接口异常，其他任务将继续执行，那么CoroutineExceptionHandler不是一个很好的选择。而接下来说的supervisorScope更适合这种情况。
CoroutineExceptionHandler的作用在于全局捕获异常，CoroutineExceptionHandler无法在代码的特定部分处理异常，例如针对某一个失败接口，无法在异常后进行重试或者其他特定操作。
如果你想在特定部分做异常处理的话，try-catch更适合。
三、SupervisorScope+async
上面2.3提到了CoroutineExceptionHandler的一个缺陷：子协程出现异常，父协程和其兄弟协程也都会跟着执行失败。
针对此问题，kotlin协程中提出了另一个协程作用域：SupervisorScope
该作用域与async结合开启协程时，子协程出现了异常，并不会影响其父协程以及其兄弟协程。所以更适合多个并行任务的执行。
学习福利
【Android 详细知识点思维脑图（技能树）】
其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。
虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。
由于篇幅有限，这里以图片的形式给大家展示一小部分。
详细整理在GitHub可以见；
Android架构视频+BAT面试专题PDF+学习笔记
%8F%91%E4%B8%8D%E4%BC%9A%E8%BF%99%E4%BA%9B%EF%BC%9F%E5%A6%82%E4%BD%95%E9%9D%A2%E8%AF%95%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)**
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
