Kotlin 协程与架构组件一起使用及底层原理分析

kotlin的协程封装了线程的API，这个线程框架可以让我们很方便得编写异步代码。

虽然协程已经很方便了，但是如果再配合Google提供的架构组件的KTX扩展一起使用，那就更方便了。

1. 添加KTX依赖

//将 Kotlin 协程与架构组件一起使用

//ViewModelScope
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1'
//LifecycleScope
implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.2.0'
//liveData
implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'

2. viewModelScope

2.1 用老方式在ViewModel中使用协程

在使用ViewModelScope之前，先来回顾一下以前在ViewModel中使用协程的方式。自己管理CoroutineScope，在不需要的时候（一般是在onCleared()）进行取消。否则，可能造成资源浪费、内存泄露等问题。

class JetpackCoroutineViewModel : ViewModel() {
    //在这个ViewModel中使用协程时,需要使用这个job来方便控制取消
    private val viewModelJob = SupervisorJob()
    
    //指定协程在哪里执行,并且可以由viewModelJob很方便地取消uiScope
    private val uiScope = CoroutineScope(Dispatchers.Main + viewModelJob)
    
    fun launchDataByOldWay() {
        uiScope.launch {
            //在后台执行
            val result = getNetData()
            //修改UI
            log(result)
        }
    }
    
    override fun onCleared() {
        super.onCleared()
        viewModelJob.cancel()
    }
    
    //将耗时任务切到IO线程去执行
    private suspend fun getNetData() = withContext(Dispatchers.IO) {
        //模拟网络耗时
        delay(1000)
        //模拟返回结果
        "{}"
    }
}

看起来有很多的样板代码，而且在不需要的时候取消协程很容易忘。

2.2 新方式在ViewModel中使用协程

正是在这种情况下，Google为我们创造了ViewModelScope，它通过向ViewModel类添加扩展属性来方便我们使用协程，而且在ViewModel被销毁时会自动取消其子协程。

class JetpackCoroutineViewModel : ViewModel() {
    fun launchData() {
        viewModelScope.launch {
            //在后台执行
            val result = getNetData()
            //修改UI
            log(result)
        }
    }

    //将耗时任务切到IO线程去执行
    private suspend fun getNetData() = withContext(Dispatchers.IO) {
        //模拟网络耗时
        delay(1000)
        //模拟返回结果
        "{}"
    }

}

所有CoroutineScope的初始化和取消都已经为我们完成了，只需要在代码里面使用viewModelScope即可开启一个新协程，而且还不用担心忘记取消的问题。

下面我们来看看Google是怎么实现的。

2.3 viewModelScope的底层实现

点进去看看源码，知根知底，万一后面遇到什么奇怪的bug，在知道原理的情况下，才能更快的想到解决办法。

private const val JOB_KEY = "androidx.lifecycle.ViewModelCoroutineScope.JOB_KEY"

/**
 * [CoroutineScope] tied to this [ViewModel].
 * This scope will be canceled when ViewModel will be cleared, i.e [ViewModel.onCleared] is called
 *
 * This scope is bound to
 * [Dispatchers.Main.immediate][kotlinx.coroutines.MainCoroutineDispatcher.immediate]
 */
public val ViewModel.viewModelScope: CoroutineScope
    get() {
        //先从缓存中取值，有就直接返回
        val scope: CoroutineScope? = this.getTag(JOB_KEY)
        if (scope != null) {
            return scope
        }
        //没有缓存就新建一个CloseableCoroutineScope
        return setTagIfAbsent(
            JOB_KEY,
            CloseableCoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
        )
    }

internal class CloseableCoroutineScope(context: CoroutineContext) : Closeable, CoroutineScope {
    override val coroutineContext: CoroutineContext = context

    override fun close() {
        coroutineContext.cancel()
    }
}

源码中首先是介绍了viewModelScope是什么，它其实是一个ViewModel的扩展属性，它的实际类型是CloseableCoroutineScope。这名字看起来就是一个可以取消的协程，果不其然，它实现了Closeable并在close方法中进行了取消。

每次在使用viewModelScope的时候，会先从缓存中取，如果没有才去新建一个CloseableCoroutineScope。需要注意的是，CloseableCoroutineScope的执行是在主线程中执行的。

我们现在需要知道的是缓存是怎么存储和取出的。

//ViewModel.java

// Can't use ConcurrentHashMap, because it can lose values on old apis (see b/37042460)
@Nullable
private final Map mBagOfTags = new HashMap<>();
/**
 * Returns the tag associated with this viewmodel and the specified key.
 */
@SuppressWarnings({"TypeParameterUnusedInFormals", "unchecked"})
 T getTag(String key) {
    if (mBagOfTags == null) {
        return null;
    }
    synchronized (mBagOfTags) {
        return (T) mBagOfTags.get(key);
    }
}

/**
 * Sets a tag associated with this viewmodel and a key.
 * If the given {@code newValue} is {@link Closeable},
 * it will be closed once {@link #clear()}.
 * 

 * If a value was already set for the given key, this calls do nothing and
 * returns currently associated value, the given {@code newValue} would be ignored
 * 

 * If the ViewModel was already cleared then close() would be called on the returned object if
 * it implements {@link Closeable}. The same object may receive multiple close calls, so method
 * should be idempotent.
 */
@SuppressWarnings("unchecked")
 T setTagIfAbsent(String key, T newValue) {
    T previous;
    synchronized (mBagOfTags) {
        previous = (T) mBagOfTags.get(key);
        if (previous == null) {
            mBagOfTags.put(key, newValue);
        }
    }
    T result = previous == null ? newValue : previous;
    if (mCleared) {
        // It is possible that we'll call close() multiple times on the same object, but
        // Closeable interface requires close method to be idempotent:
        // "if the stream is already closed then invoking this method has no effect." (c)
        closeWithRuntimeException(result);
    }
    return result;
}

现在我们知道了，原来是存在了ViewModel的mBagOfTags中，它是一个HashMap。

知道了怎么存的，那么它是在什么时候用的呢？

@MainThread
final void clear() {
    mCleared = true;
    // Since clear() is final, this method is still called on mock objects
    // and in those cases, mBagOfTags is null. It'll always be empty though
    // because setTagIfAbsent and getTag are not final so we can skip
    // clearing it
    if (mBagOfTags != null) {
        synchronized (mBagOfTags) {
            for (Object value : mBagOfTags.values()) {
                // see comment for the similar call in setTagIfAbsent
                closeWithRuntimeException(value);
            }
        }
    }
    onCleared();
}

private static void closeWithRuntimeException(Object obj) {
    if (obj instanceof Closeable) {
        try {
            ((Closeable) obj).close();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

我在ViewModel中搜索了一下mBagOfTags，发现有一个clear方法，在里面将mBagOfTags遍历一遍，然后将所有value是Closeable的全部close。在上面的源码中，第一次使用viewModelScope的时候，会创建一个CloseableCoroutineScope，它实现了Closeable接口，并实现了close方法，刚好用来做取消操作。

看到这里，我们知道了：viewModelScope构建的协程是在ViewModel的clear方法回调时取消协程的。

而且，clear方法里面居然还有我们熟悉的onCleared方法调用。而onCleared我们知道是干什么的，当这个ViewModel不再使用时会回调这个方法，一般我们需要在此方法中做一些收尾工作，如取消观察者订阅、关闭资源之类的。

那么，大胆猜测一下，这个clear()方法应该也是在ViewModel要结束生命的时候调用的。

搜索了一下，发现clear方法是在ViewModelStore里面调用的。

public class ViewModelStore {

    private final HashMap mMap = new HashMap<>();

    final void put(String key, ViewModel viewModel) {
        ViewModel oldViewModel = mMap.put(key, viewModel);
        if (oldViewModel != null) {
            oldViewModel.onCleared();
        }
    }

    final ViewModel get(String key) {
        return mMap.get(key);
    }

    Set keys() {
        return new HashSet<>(mMap.keySet());
    }

    /**
     *  Clears internal storage and notifies ViewModels that they are no longer used.
     */
    public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.clear();
        }
        mMap.clear();
    }
}

ViewModelStore是一个容器，用于盛放ViewModel。在ViewModelStore的clear方法中调用了该ViewModelStore中所有ViewModel的clear方法。那么ViewModelStore的clear是在哪里调用的？我跟着追踪，发现是在ComponentActivity的构造方法中。

public ComponentActivity() {
    Lifecycle lifecycle = getLifecycle();
    getLifecycle().addObserver(new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            if (event == Lifecycle.Event.ON_DESTROY) {
                if (!isChangingConfigurations()) {
                    getViewModelStore().clear();
                }
            }
        }
    });
}

在Activity的生命周期走到onDestroy的时候调用ViewModelStore的clear做收尾工作。但是，注意一下，这个调用有个前提，此次走onDestroy不是因为配置更改才会去调用clear方法。

好的，到此为止，咱们理通了viewModelScope的协程是怎么做到自动取消的（ViewModel的mBagOfTags），以及是在什么时候进行取消的（ViewModel的clear()时）。

3. lifecycleScope

对于Lifecycle，Google贴心地提供了LifecycleScope，我们可以直接通过launch来创建Coroutine。

3.1 使用

举个简单例子，比如在Activity的onCreate里面,每隔100毫秒更新一下TextView的文字。

lifecycleScope.launch {
    repeat(100000) {
        delay(100)
        tvText.text = "$it"
    }
}

因为LifeCycle是可以感知组件的生命周期的，所以Activity一旦onDestroy了，相应的上面这个lifecycleScope。launch闭包的调用也会取消。

另外，lifecycleScope还贴心地提供了launchWhenCreated、launchWhenStarted、launchWhenResumed方法，这些方法的闭包里面有协程的作用域，它们分别是在CREATED、STARTED、RESUMED时被执行。

//方式1
lifecycleScope.launchWhenStarted {
    repeat(100000) {
        delay(100)
        tvText.text = "$it"
    }
}
//方式2
lifecycleScope.launch {
    whenStarted { 
        repeat(100000) {
            delay(100)
            tvText.text = "$it"
        }
    }
}

不管是直接调用launchWhenStarted还是在launch中调用whenStarted都能达到同样的效果。

3.2 LifecycleScope的底层实现

先来看下lifecycleScope.launch是怎么做到的

/**
 * [CoroutineScope] tied to this [LifecycleOwner]'s [Lifecycle].
 *
 * This scope will be cancelled when the [Lifecycle] is destroyed.
 *
 * This scope is bound to
 * [Dispatchers.Main.immediate][kotlinx.coroutines.MainCoroutineDispatcher.immediate].
 */
val LifecycleOwner.lifecycleScope: LifecycleCoroutineScope
    get() = lifecycle.coroutineScope

好家伙，又是扩展属性。这次扩展的是LifecycleOwner，返回了一个LifecycleCoroutineScope。每次在get的时候，是返回的lifecycle.coroutineScope，看看这个是啥。

/**
 * [CoroutineScope] tied to this [Lifecycle].
 *
 * This scope will be cancelled when the [Lifecycle] is destroyed.
 *
 * This scope is bound to
 * [Dispatchers.Main.immediate][kotlinx.coroutines.MainCoroutineDispatcher.immediate]
 */
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
            }
        }
    }

Lifecycle的coroutineScope也是扩展属性，它是一个LifecycleCoroutineScope。从注释可以看到，在Lifecycle被销毁之后，这个协程会跟着取消。这里首先会从mInternalScopeRef中取之前存入的缓存，如果没有再生成一个LifecycleCoroutineScopeImpl放进去，并调用LifecycleCoroutineScopeImpl的register函数。这里的mInternalScopeRef是Lifecycle类里面的一个属性： AtomicReference