override fun onError(t: Throwable?) {
tv_text.text = “error”
}
})
}

// 使用协程 请求+渲染数据
fun requestData2() {
GlobalScope.launch(Dispatchers.Main) {
try {
tv_text.text = Gson().toJson(testApi.getLatestNews2())
} catch (e: Exception) {
tv_text.text = “error”
}
}
}
}

rxjava2是使用回调的方式渲染数据，这个大家都知道

而协程需要先使用GlobalScope.launch启动一个协程(启动协程的方法很多，请自行查看官方文档)，并使用Dispatchers.Main指定协程调度器为主线程（即ui线程）, 然后通过 try catch分别处理正常和异常的情况（暂时使用GlobalScope上下文启动协程，下面会介绍一种专门再android中启动协程的方法）

这样看来是不是使用协程可以简化很多代码，使代码看起来更加优雅

我们再来看看多个请求并发和串行的情况

先多添加几个api，方便操作

interface TestApi {
@GET(“api/3/news/latest”)
fun getLatestNews(): Flowable

@GET(“api/3/news/{id}”)
fun getNewsDetail(@Path(“id”) id: Long): Flowable

@GET(“api/4/news/latest”)
suspend fun getLatestNews2(): LatestNews

@GET(“api/3/news/{id}”)
suspend fun getNewsDetail2(@Path(“id”) id: Long): News
}

比如我们先调用getLatestNews()方法请求一系列的新闻列表，然后在调用getNewsDetail请求第一个新闻的详情，代码如下

// 非协程用法
testApi.getLatestNews()
.flatMap {
testApi.getNewsDetail(it.stories!![0].id!!)
}
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(object : DisposableSubscriber() {
override fun onComplete() {}

override fun onNext(t: News) {
tv_text.text = t.title
}

override fun onError(t: Throwable?) {
tv_text.text = “error”
}
})

// 协程用法
GlobalScope.launch(Dispatchers.Main) {
try {
val lastedNews = testApi.getLatestNews2()
val detail = testApi.getNewsDetail2(lastedNews.stories!![0].id!!)
tv_text.text = detail.title
} catch(e: Exception) {
tv_text.text = “error”
}
}

再比如如果我们想调用getNewsDetail同时请求多个新闻详情数据

// 非协程用法
testApi.getLatestNews()
.flatMap {
Flowable.zip(
testApi.getNewsDetail(it.stories!![0].id!!),
testApi.getNewsDetail(it.stories!![1].id!!),
BiFunction<News, News, List> { news1, news2->
listOf(news1, news2)
}
)
}
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(object : DisposableSubscriber<List>() {
override fun onComplete() {}

override fun onNext(t: List) {
tv_text.text = t[0].title + t[1].title
}

override fun onError(t: Throwable?) {
tv_text.text = “error”
}
})

// 协程的用法
GlobalScope.launch(Dispatchers.Main) {
try {
// 先请求新闻列表
val lastedNews = testApi.getLatestNews2()
// 再使用async 并发请求第一个和第二个新闻的详情
val detail1 = async { testApi.getNewsDetail2(lastedNews.stories!![0].id!!) }
val detail2 = async { testApi.getNewsDetail2(lastedNews.stories!![1].id!!) }
tv_text.text = detail1.await().title + detail2.await().title
} catch(e: Exception) {
tv_text.text = “error”
}
}

可见相对于非协程的写法（代码中使用rxjava2），协程能让你的代码更加简洁、优雅，能更加清晰的描述你第一步想做什么、第二步想做什么等等

room数据库对协程的支持

room数据库在2.1.0开始支持协程, 并且需要导入room-ktx依赖

implementation “androidx.room:room-ktx:2.1.0”

然后在Dao中使用suspend定义挂起函数

@Dao
abstract class UserDao {
@Query(“select * from tab_user”)
abstract suspend fun getAll(): List
}

最后就像上面retrofit2那样使用协程即可

class RoomActivity : AppCompatActivity() {
private var adapter: RoomAdapter? = null

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_room)
…
}

…

private fun loadUser() {
GlobalScope.launch(Dispatchers.Main) {
adapter!!.data = AppDataBase.getInstance().userDao().getAll()
}
}

}

这里指介绍room数据库的协程用法，对于room数据库的介绍和其他用法请查看Android Jetpack ROOM数据库用法介绍和android Jetpack ROOM数据库结合其它Library的使用介绍

协程在android里的应用

上面的example都是使用GlobalScope上下文来启动协程, 其实真正在android中一般不建议直接使用GlobalScope，因为使用GlobalScope.launch 时，我们会创建一个顶层协程。虽然它很轻量，但它运行时仍会消耗一些内存资源，如果我们忘记保持对新启动的协程的引用，它还会继续运行，所以我们必须保持所有对GlobalScope.launch启动协程的引用，然后在activity destory（或其它需要cancel）的时候cancel掉所有的协程，否则就会造成内存泄露等一系列问题

比如：

class CoroutineActivity : AppCompatActivity() {
private lateinit var testApi: TestApi
private var job1: Job? = null
private var job2: Job? = null
private var job3: Job? = null

…

override fun onDestroy() {
super.onDestroy()
job1?.cancel()
job2?.cancel()
job3?.cancel()
}
…

// 启动第一个顶级协程
fun requestData1() {
job1 = GlobalScope.launch(Dispatchers.Main) {
try {
val lastedNews = testApi.getLatestNews2()
tv_text.text = lastedNews.stories!![0].title
} catch(e: Exception) {
tv_text.text = “error”
}
}
}

// 启动第二个顶级协程
fun requestData2() {
job2 = GlobalScope.launch(Dispatchers.Main) {
try {
val lastedNews = testApi.getLatestNews2()
// 在协程内部启动第三个顶级协程
job3 = GlobalScope.launch(Dispatchers.Main) {
try {
val detail = testApi.getNewsDetail2(lastedNews.stories!![0].id!!)
tv_text.text = detail.title
} catch (e: Exception) {
tv_text.text = “error”
}
}
} catch(e: Exception) {
tv_text.text = “error”
}
}
}
}

可见如果使用GlobalScope启动的协程越多，就必须定义越多的变量持有对启动协程的引用，并在onDestroy的时候cancel掉所有协程

下面我们就介绍MainScope代替GlobalScope的使用

class CoroutineActivity : AppCompatActivity() {
private var mainScope = MainScope()
private lateinit var testApi: TestApi

…

override fun onDestroy() {
super.onDestroy()
// 只需要调用mainScope.cancel，就会cancel掉所有使用mainScope启动的所有协程
mainScope.cancel()
}

fun requestData1() {
mainScope.launch {
try {
val lastedNews = testApi.getLatestNews2()
tv_text.text = lastedNews.stories!![0].title
} catch(e: Exception) {
tv_text.text = “error”
}
}
}

fun requestData2() {
mainScope.launch {
try {
val lastedNews = testApi.getLatestNews2()
val detail = testApi.getNewsDetail2(lastedNews.stories!![0].id!!)
tv_text.text = detail.title
} catch (e: Exception) {
tv_text.text = “error”
}
}
}
}

又或者是使用kotlin委托模式实现如下：

class CoroutineActivity : AppCompatActivity(), CoroutineScope by MainScope() {
private lateinit var testApi: TestApi

…

override fun onDestroy() {
super.onDestroy()
cancel()
}

fun requestData1() {
launch {
try {
val lastedNews = testApi.getLatestNews2()
tv_text.text = lastedNews.stories!![0].title
} catch(e: Exception) {
tv_text.text = “error”
}
}
}

fun requestData2() {
launch {
try {
val lastedNews = testApi.getLatestNews2()
val detail = testApi.getNewsDetail2(lastedNews.stories!![0].id!!)
tv_text.text = detail.title
} catch (e: Exception) {
tv_text.text = “error”
}
}
}
}

同时我们先来看看MainScope的定义

@Suppress(“FunctionName”)
public fun MainScope(): CoroutineScope = ContextScope(SupervisorJob() + Dispatchers.Main)

可见使用MainScope非常简单，只需要在activity onDestroy中调用MainScope 的cancel方法即可，而不需要定义其它协程的引用, 并且MainScope的调度器是Dispatchers.Main, 所以也不需要手动指定Main调度器

Lifecycle对协程的支持

发现Lifecycle组件库在2.2.0的alpha版中已经有了对于协程的支持

需要添加lifecycle-runtime-ktx依赖(正式版出来之后，请使用正式版)

implementation “androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha05”

lifecycle-runtime-ktx 中 给LifecycleOwner添加了 lifecycleScope扩展属性（类于上面介绍的MainScope），用于方便的操作协程;

先看看源码

val LifecycleOwner.lifecycleScope: LifecycleCoroutineScope
get() = lifecycle.coroutineScope

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 指定协程体 在主线程中执行
// Dispatchers.Main.immediate 跟 Dispatchers.Main唯一的区别是，如果当前在主线程，这立马执行协程体，而不是走Dispatcher分发流程
SupervisorJob() + Dispatchers.Main.immediate
)
if (mInternalScopeRef.compareAndSet(null, newScope)) {
newScope.register()
return newScope
}
}
}

同时LifecycleCoroutineScope 还提供了绑定LifecycleOwner生命周期(一般是指activity和fragment)的启动协程的方法；如下：

abstract class LifecycleCoroutineScope internal constructor() : CoroutineScope {
internal abstract val lifecycle: Lifecycle

// 当 activity 处于created的时候执行 协程体
fun launchWhenCreated(block: suspend CoroutineScope.() -> Unit): Job = launch {
lifecycle.whenCreated(block)
}

// 当 activity 处于start的时候执行 协程体
fun launchWhenStarted(block: suspend CoroutineScope.() -> Unit): Job = launch {
lifecycle.whenStarted(block)
}

// 当 activity 处于resume的时候执行 协程体
fun launchWhenResumed(block: suspend CoroutineScope.() -> Unit): Job = launch {
lifecycle.whenResumed(block)
}
}

由于上面启动协程的方法绑定了activity生命周期，所以在activity destroy的时候，也实现了自动cancel掉协程

所以我们 CoroutineActivity Demo的代码可以写的更加简单，如下：

class CoroutineActivity : AppCompatActivity() {
private lateinit var testApi: TestApi

…

fun requestData1() {
lifecycleScope.launchWhenResumed {
try {
val lastedNews = testApi.getLatestNews2()
tv_text.text = lastedNews.stories!![0].title
} catch(e: Exception) {
tv_text.text = “error”
}
}
}
}

LiveData对协程的支持

同时Google也对LiveData提供了对协程的支持，不过需要添加lifecycle-livedata-ktx依赖

// 现在还是alpha版，等正式版发布以后，请替换成正式版
implementation “androidx.lifecycle:lifecycle-livedata-ktx:2.2.0-alpha05”

lifecycle-livedata-ktx依赖添加了liveData顶级函数，返回CoroutineLiveData

源码如下：

…
internal const val DEFAULT_TIMEOUT = 5000L
…
fun liveData(
context: CoroutineContext = EmptyCoroutineContext,
timeoutInMs: Long = DEFAULT_TIMEOUT,
@BuilderInference block: suspend LiveDataScope.() -> Unit
): LiveData = CoroutineLiveData(context, timeoutInMs, block)

CoroutineLiveData是在什么时候启动协程并执行协程体的呢？？？

internal class CoroutineLiveData(
context: CoroutineContext = EmptyCoroutineContext,
timeoutInMs: Long = DEFAULT_TIMEOUT,
block: Block
) : MediatorLiveData() {
private var blockRunner: BlockRunner?
private var emittedSource: EmittedSource? = null

init {
val scope = CoroutineScope(Dispatchers.Main.immediate + context + supervisorJob)
blockRunner = BlockRunner(
liveData = this,
block = block,
timeoutInMs = timeoutInMs,
scope = scope
) {
blockRunner = null
}
}

…

// observer(观察者)个数有0到1时执行
// 即第一次调用observe或observeForever时执行
override fun onActive() {
super.onActive()
// 启动协程并执行协程体
blockRunner?.maybeRun()
}

// observer(观察者)个数有1到0时执行
// 即调用removeObserver时触发检查并执行回调
override fun onInactive() {
super.onInactive()
// 取消协程
blockRunner?.cancel()
}
}

可见CoroutineLiveData是在onActive()启动协程，在onInactive()取消协程

所以使用LiveData对协程的支持, 那么CoroutineActivity Demo的代码写法如下

class CoroutineActivity : AppCompatActivity() {
private lateinit var testApi: TestApi

…

fun requestData1() {
liveData {
try {
val lastedNews = testApi.getLatestNews2()
emit(lastedNews.stories!![0].title!!)
} catch(e: Exception) {
emit(“error”)
}
}.observe(this, Observer {
tv_text.text = it
})
}
}

上面我们讲了协程在android里最常用的用法，下面将介绍协程的一些基本知识

协程上下文

协程上下文用CoroutineContext表示，kotlin中 比较常用的Job、协程调度器(CoroutineDispatcher)、协程拦截器（ContinuationInterceptor）等都是CoroutineContext的子类，即它们都是协程上下文

先看一下CoroutineContext 比较重要的plus方法，它是一个用operator修复的重载(+)号的操作符方法

@SinceKotlin(“1.3”)
public interface CoroutineContext {

/**

• Returns a context containing elements from this context and elements from other [context].
• The elements from this context with the same key as in the other one are dropped.
  */
  public operator fun plus(context: CoroutineContext): CoroutineContext =
  if (context === EmptyCoroutineContext) this else // fast path – avoid lambda creation
  context.fold(this) { acc, element ->
  val removed = acc.minusKey(element.key)
  if (removed === EmptyCoroutineContext) element else {
  // make sure interceptor is always last in the context (and thus is fast to get when present)
  val interceptor = removed[ContinuationInterceptor]
  if (interceptor == null) CombinedContext(removed, element) else {
  val left = removed.minusKey(ContinuationInterceptor)
  if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else
  CombinedContext(CombinedContext(left, element), interceptor)
  }
  }
  }
  }

比如上面说的MainScope定义就使用了+号操作符

public fun MainScope(): CoroutineScope = ContextScope(SupervisorJob() + Dispatchers.Main)

如果你看启动协程的源码就会发现，在kotlin中 大量使用 + 号操作符，所以kotlin中大部分CoroutineContext对象都是CombinedContext对象

上面的example使用的launch方法启动协程有三个参数, 分别是协程上下文、协程启动模式、协程体

public fun CoroutineScope.launch(
context: CoroutineContext = EmptyCoroutineContext, // 协程上下文
start: CoroutineStart = CoroutineStart.DEFAULT, // 协程启动模式
block: suspend CoroutineScope.() -> Unit // 协程体
): Job {
val newContext = newCoroutineContext(context)
val coroutine = if (start.isLazy)
LazyStandaloneCoroutine(newContext, block) else
StandaloneCoroutine(newContext, active = true)
coroutine.start(start, coroutine, block)
return coroutine
}

协程启动模式

• DEFAULT

立即执行协程体

runBlocking {
val job = GlobalScope.launch(start = CoroutineStart.DEFAULT) {
println("1: " + Thread.currentThread().name)
}
// 不需要调用join方法
// job.join()
}

打印结果

1: DefaultDispatcher-worker-1

CoroutineStart.DEFAULT启动模式不需要手动调用join或start等方法，而是在调用launch方法的时候就会自动执行协程体的代码

• LAZY

只有在需要的情况下才执行协程体

runBlocking {
val job = GlobalScope.launch(start = CoroutineStart.LAZY) {
println("1: " + Thread.currentThread().name)
}
// 一定调用join方法
job.join()
}

打印结果

1: DefaultDispatcher-worker-1

CoroutineStart.LAZY启动模式一定要手动调用join或start等方法，否者协程体不会执行

• ATOMIC

立即执行协程体，但在开始运行之前无法取消, 即开启协程会无视cancelling状态

runBlocking {
val job = GlobalScope.launch(start = CoroutineStart.ATOMIC) {
println("1: " + Thread.currentThread().name)
delay(1000)
println("2: " + Thread.currentThread().name)
}
job.cancel()
delay(2000)
}

打印结果

1: DefaultDispatcher-worker-1

CoroutineStart. ATOMIC启动模式的协程体 即使调了cancel方法 也一定会执行，因为开启协程会无视cancelling状态；上面的example只打印了一句话，是因为执行delay(1000)的时候 发现协程处于关闭状态, 所以出现了JobCancellationException异常，导致下面的代码没有执行，如果 delay(1000) 这句代码用 try catch 捕获一下异常，就会继续执行下面的代码

• UNDISPATCHED

立即在当前线程执行协程体，直到第一个 suspend 调用 挂起之后的执行线程取决于上下文当中的调度器了

runBlocking {
println("0: " + Thread.currentThread().name)
// 注意这里没有用GlobalScope.launch
// 因为GlobalScope.launch启动的是一个顶层协程, 无法关联当前协程的上下文（coroutineContext）, 导致结果有偏差
launch(context = Dispatchers.Default, start = CoroutineStart.UNDISPATCHED) {
println("1: " + Thread.currentThread().name)
delay(1000)
println("2: " + Thread.currentThread().name)
}
delay(2000)
}

打印结果

0: main
1: main
2: DefaultDispatcher-worker-1

可见 0 和 1 的执行线程是一样的，当执行完delay(1000), 后面的代码执行线程取决于Dispatchers.Default调度器指定的线程，所以 2 在另一个线程中执行

协程调度器

协程调度器 其实也是 协程上下文

协程调度器是用来指定协程代码块在哪个线程中执行，kotlin提供了几个默认的协程调度器，分别是Default、Main、Unconfined, 并针对jvm, kotlin提供了一个特有的IO调度器

• Dispatchers.Default

指定代码块在线程池中执行

GlobalScope.launch(Dispatchers.Default) {
println("1: " + Thread.currentThread().name)
launch (Dispatchers.Default) {
delay(1000) // 延迟1秒后，再继续执行下面的代码
println("2: " + Thread.currentThread().name)
}
println("3: " + Thread.currentThread().name)
}

打印结果如下

1: DefaultDispatcher-worker-1
3: DefaultDispatcher-worker-1
2: DefaultDispatcher-worker-1

• Dispatchers.Main

指定代码块在main线程中执行（针对Android就是ui线程）

GlobalScope.launch(Dispatchers.Default) {
println("1: " + Thread.currentThread().name)
launch (Dispatchers.Main) {
delay(1000) // 延迟1秒后，再继续执行下面的代码
println("2: " + Thread.currentThread().name)
}
println("3: " + Thread.currentThread().name)
}

打印结果如下：

1: DefaultDispatcher-worker-1
3: DefaultDispatcher-worker-1
2: main

可见Dispatchers.Main就是指定协程代码块在main线程中执行

• Dispatchers.Unconfined

没有指定协程代码快在哪个特定线程中执行，即当前在哪个线程，代码块中接下来的代码就在哪个线程中执行（即一段协程代码块 由于启动了子协程 导致切换了线程, 那么接下来的代码块也是在这个线程中执行）

GlobalScope.launch(Dispatchers.Default) {
println("1: " + Thread.currentThread().name)
launch (Dispatchers.Unconfined) {
println("2: " + Thread.currentThread().name)
requestApi() // delay(1000) 本来想用delay，但是使用requestApi 可能更加清晰
println("3: " + Thread.currentThread().name)
}
println("4: " + Thread.currentThread().name)
}

// 定义一个挂起函数，在一个新的子线程中执行
private suspend fun requestApi() = suspendCancellableCoroutine {
Thread {
println("5: requestApi: " + Thread.currentThread().name)
it.resume(“success”)
}.start()
}

打印结果如下：

1: DefaultDispatcher-worker-1
2: DefaultDispatcher-worker-1
5: requestApi: Thread-3
4: DefaultDispatcher-worker-1
3: Thread-3

可见2 和 3的代码 执行线程明显不一样；当执行到requestApi这句代码的时候 会切换到子线程（即Thread-3）中执行代码，然后接下来的协程代码块就会在Thread-3中执行

• Dispatchers.IO

它是基于 Default 调度器背后的线程池，并实现了独立的队列和限制，因此协程调度器从 Default 切换到 IO 并不会触发线程切换

GlobalScope.launch(Dispatchers.Default) {
println("1: " + Thread.currentThread().name)
launch (Dispatchers.IO) {
println("2: " + Thread.currentThread().name)
requestApi() // delay(1000)
println("3: " + Thread.currentThread().name)
}
println("4: " + Thread.currentThread().name)
}

打印结果如下：

1: DefaultDispatcher-worker-1
4: DefaultDispatcher-worker-1
2: DefaultDispatcher-worker-1
5: requestApi: Thread-3
3: DefaultDispatcher-worker-1

• 绑定到任意自定义线程的调度器（这种方式要谨慎使用）

可以使用kotlin自带newSingleThreadContext方法或者使用ExecutorService的扩展方法asCoroutineDispatcher创建一个Dispatcher

// 第一种方法
val dispatcher = newSingleThreadContext(“custom thread”)
// 第二种方法
// val dispatcher = Executors.newSingleThreadExecutor{ r -> Thread(r, “custom thread”) }.asCoroutineDispatcher()
GlobalScope.launch(dispatcher) {
println("1: " + Thread.currentThread().name)
delay(1000)
println("2: " + Thread.currentThread().name)
}

runBlocking {
delay(2000L)
// 一定要close，否则线程永远都不会结束，很危险
dispatcher.close()
}

打印结果如下：

1: custom thread
2: custom thread

可见我们可以自己创建线程绑定到协程调度器上，但是这种方式不建议使用，因为一旦手动创建了线程 就需要手动close，否则线程就永远也不会终止，这样会很危险

协程作用域GlobalScope、coroutineScope、supervisorScope

协程作用域是一个非常重的东西

• GlobeScope

GlobeScope 启动的协程会单独启动一个作用域，无法继承外面协程的作用域，其内部的子协程遵从默认的作用域规则

• coroutineScope

coroutineScope 启动的协程会继承父协程的作用域，其内部的取消操作是双向传播的，子协程未捕获的异常也会向上传递给父协程

• supervisorScope

supervisorScope 启动的协程会继承父协程的作用域，他跟coroutineScope不一样的点是 它是单向传递的，即内部的取消操作和异常传递 只能由父协程向子协程传播，不能从子协程传向父协程

MainScope 就是使用的supervisorScope作用域，所以只需要子协程 出错 或 cancel 并不会影响父协程，从而也不会影响兄弟协程

协程异常传递模式

协程的异常传递跟协程作用域有关，要么跟coroutineScope一样双向传递，要么跟supervisorScope一样由父协程向子协程单向传递

针对supervisorScope的单向传递

runBlocking {
println(“1”)
supervisorScope {
println(“2”)
// 启动一个子协程
launch {
1/0 // 故意让子协程出现异常
}
delay(100)
println(“3”)
}
println(“4”)
}

最后

都说三年是程序员的一个坎，能否晋升或者提高自己的核心竞争力，这几年就十分关键。

技术发展的这么快，从哪些方面开始学习，才能达到高级工程师水平，最后进阶到Android架构师/技术专家？我总结了这 5大块；

我搜集整理过这几年阿里，以及腾讯，字节跳动，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2021年虽然路途坎坷，都在说Android要没落，但是，不要慌，做自己的计划，学自己的习，竞争无处不在，每个行业都是如此。相信自己，没有做不到的，只有想不到的。祝大家2021年万事大吉。

兄弟协程

协程异常传递模式

协程的异常传递跟协程作用域有关，要么跟coroutineScope一样双向传递，要么跟supervisorScope一样由父协程向子协程单向传递

针对supervisorScope的单向传递

runBlocking {
println(“1”)
supervisorScope {
println(“2”)
// 启动一个子协程
launch {
1/0 // 故意让子协程出现异常
}
delay(100)
println(“3”)
}
println(“4”)
}

最后

都说三年是程序员的一个坎，能否晋升或者提高自己的核心竞争力，这几年就十分关键。

技术发展的这么快，从哪些方面开始学习，才能达到高级工程师水平，最后进阶到Android架构师/技术专家？我总结了这 5大块；

我搜集整理过这几年阿里，以及腾讯，字节跳动，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。

[外链图片转存中…(img-lAJUvvHw-1643532867347)]

[外链图片转存中…(img-SmD1cVBj-1643532867348)]

[外链图片转存中…(img-WtwOzPID-1643532867349)]

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2021年虽然路途坎坷，都在说Android要没落，但是，不要慌，做自己的计划，学自己的习，竞争无处不在，每个行业都是如此。相信自己，没有做不到的，只有想不到的。祝大家2021年万事大吉。

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录