最近看到很多关于livedata和flow的文章，大家都在学那我肯定不能落后。便去学习一番，偶得SharedFlowBus（卷死你们）。

那么正式开始前我们先大概了解下 StateFlow 和 SharedFlow

StateFlow

StateFlow 是一个状态容器式可观察数据流，可以向其收集器发出当前状态更新和新状态更新。还可通过其value属性读取当前状态值。

在 Android 中，StateFlow 非常适合需要让可变状态保持可观察的类。

与使用 flow 构建器构建的冷数据流不同，StateFlow 是热数据流：从此类数据流收集数据不会触发任何提供方代码。StateFlow 始终处于活跃状态并存于内存中，而且只有在垃圾回收根中未涉及对它的其他引用时，它才符合垃圾回收条件。

当新使用方开始从数据流中收集数据时，它将接收信息流中的最近一个状态及任何后续状态。您可在 LiveData 等其他可观察类中找到此操作行为。

SharedFlow

SharedFlow 是 StateFlow 的可配置性极高的泛化数据流。您可以使用 SharedFlow 将 tick 信息发送到应用的其余部分，以便让所有内容定期同时刷新。除了获取最新资讯之外，您可能还想要使用用户最喜欢的主题集刷新用户信息部分。

class MainViewModel :  ViewModel() {

    

    private val _sharedFlow = MutableSharedFlow<Int>(0, 1, BufferOverflow.DROP_OLDEST)

    val sharedFlow: SharedFlow<Int> = _sharedFlow



    init {

	viewModelScope.launch {

            for (i in 0..10) {

		sharedFlow.tryEmit(i)

            }

	}

    }

    

}



class MainFragment : Fragment() {



    private val viewModel: MainViewModel by viewModels()

   

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        super.onViewCreated(view, savedInstanceState)

        

        CoroutineScope(Dispatchers.Main).launch {

            viewModel.sharedFlow.collect { 

                println(it)

            }

        }

    }



}

 

您可通过以下方式自定义 SharedFlow 行为：

• 通过 replay，您可以针对新订阅者重新发送多个之前已发出的值。
• 通过 onBufferOverflow，您可以指定相关政策来处理缓冲区中已存满要发送的数据项的情况。默认值为 BufferOverflow.SUSPEND，这会使调用方挂起。其他选项包括 DROP_LATEST 或 DROP_OLDEST。

MutableSharedFlow 还具有 subscriptionCount 属性，其中包含处于活跃状态的收集器的数量，以便您相应地优化业务逻辑。MutableSharedFlow 还包含一个 resetReplayCache 函数，供您在不想重放已向数据流发送的最新信息的情况下使用。

没错，以上信息摘自 Android Developers ，我真是太能水了，干脆改行写小说得了哈哈哈。

SharedFlowBus的使用

// 发送消息

SharedFlowBus.with(objectKey: Class<T>).tryEmit(value: T)

// 发送粘性消息

SharedFlowBus.withSticky(objectKey: Class<T>).tryEmit(value: T)



// 订阅消息

SharedFlowBus.on(objectKey: Class<T>).observe(owner){ it ->

    println(it)

}

// 订阅粘性消息

SharedFlowBus.onSticky(objectKey: Class<T>).observe(owner){ it ->

    println(it)

}

 

通过上面的使用方法可以看出 SharedFlowBus 的优点

• 使用者不用显示调用反注册方法。
• 感知生命周期，防止内存泄漏。
• 实时数据刷新。

SharedFlowBus的实现

object SharedFlowBus {



    private var events = ConcurrentHashMap<Any, MutableSharedFlow<Any>>()

    private var stickyEvents = ConcurrentHashMap<Any, MutableSharedFlow<Any>>()



    fun <T> with(objectKey: Class<T>): MutableSharedFlow<T> {

        if (!events.containsKey(objectKey)) {

            events[objectKey] = MutableSharedFlow(0, 1, BufferOverflow.DROP_OLDEST)

        }

        return events[objectKey] as MutableSharedFlow<T>

    }



    fun <T> withSticky(objectKey: Class<T>): MutableSharedFlow<T> {

        if (!stickyEvents.containsKey(objectKey)) {

            stickyEvents[objectKey] = MutableSharedFlow(1, 1, BufferOverflow.DROP_OLDEST)

        }

        return stickyEvents[objectKey] as MutableSharedFlow<T>

    }



    fun <T> on(objectKey: Class<T>): LiveData<T> {

        return with(objectKey).asLiveData()

    }



    fun <T> onSticky(objectKey: Class<T>): LiveData<T> {

        return withSticky(objectKey).asLiveData()

    }



}

 

源码说明

以上就是 SharedFlowBus 的源码，可以直接拷贝到项目中使用。

你好呀，我是歪歪。

最近有个读者给我说，面试聊到线程池的时候，相谈甚欢，基本都回答上来了，但是其中有一个问题直接把他干懵逼了。

面试官问他：你说一下线程池里面的锁吧。

结果他关于线程池的知识点其实都是在各个博客或者面经里面看到的，没有自己去翻阅过源码，也就根本就没有注意过线程池里面还有锁的存在。

他还给我抱怨：

他这么一说，我也觉得，好像大家聊到线程池的时候，都没有怎么聊到里面用到的锁。

确实是存在感非常低。

要不我就安排一下？

mainLock

其实线程池里面用到锁的地方还是非常的多的。

比如我之前说过，线程池里面有个叫做 workers 的变量，它存放的东西，可以理解为线程池里面的线程。

而这个对象的数据结构是 HashSet。

HashSet 不是一个线程安全的集合类，这你知道吧？

所以，你去看它上面的注释是怎么说的：

当持有 mainLock 这个玩意的时候，才能被访问。

就算我不介绍，你看名字也能感觉的到：如果没有猜测的话，那么 mainLock 应该是一把锁。

到底是不是呢，如果是的话，它又是个什么样子的锁呢？

在源码中 mainLock 这个变量，就在 workers 的正上方：

原来它的真身就是一个 ReentrantLock。

用一个 ReentrantLock 来保护一个 HashSet，完全没毛病。

那么 ReentrantLock 和 workers 到底是怎么打配合的呢？

我们还是拿最关键的 addWorker 方法来说：

用到锁了，那么必然是有什么东西需要被被独占起来的。

你再看看，你加锁独占了某个共享资源，你是想干什么？

绝大部分情况下，肯定是想要改变它，往里面塞东西，对不对？

所以你就按照这个思路分析，addWorker 中被锁包裹起来的这段代码，它到底在独占什么东西？

其实都不用分析了，这里面的共享数据一共就两个。两个都需要进行写入操作，这两共享数据，一个是workers 对象，一个是 largestPoolSize 变量。

workers 我们前面说了，它的数据结构是线程不安全的 HashSet。

largestPoolSize 是个啥玩意，它为什么要被锁起来？

这个字段是用来记录线程池中，曾经出现过的最大线程数。

包括读取这个值的时候也是加了 mianLock 锁的：

其实我个人觉得这个地方用 volatile 修饰一下 largestPoolSize 变量，就可以省去 mainLock 的上锁操作。

同样也是线程安全的。

不知道你是不是也是这样觉得的？

如果你也是这样想的话，不好意思，你想错了。

在线程池里面其他的很多字段都用到了 volatile：

为什么 largestPoolSize 不用呢？

你再看一下前面 getLargestPoolSize 方法获取值的地方。

如果修改为 volatile，不上锁，就少了一个 mainLock.lock() 的操作。

去掉这个操作，就有可能少了一个阻塞等待的操作。

假设 addWorkers 方法还没来得及修改 largestPoolSize 的值，就有线程调用了 getLargestPoolSize 方法。

由于没阻塞，直接获取到的值，只是那一瞬间的 largestPoolSize，不是一定是 addWorker 方法执行完成后的

加上阻塞，程序是能感知到 largestPoolSize 有可能正在发生变化，所以获取到的一定是 addWorker 方法执行完成后的 largestPoolSize。

所以我理解加锁，是为了最大程度上保证这个参数的准确性。

除了前面说的几个地方外，还是有很多 mainLock 使用的地方：

我就不一一介绍了，你得自己去翻一翻，这玩意介绍起来也没啥意思，都是一眼就能瞟明白的代码。

说个有意思的。

你有没有想过这里 Doug Lea 老爷子为什么用了线程不安全的 HashSet，配合 ReentrantLock 来实现线程安全呢？

为什么不直接搞一个线程安全的 Set 集合，比如用这个玩意 Collections.synchronizedSet？

答案其实在前面已经出现过了，只是我没有特意说，大家没有注意到。

就在 mainLock 的注释上写着：

我捡关键的地方给你说一下。

首先看这句：

While we could use a concurrent set of some sort, it turns out to be generally preferable to use a lock.

这句话是个倒装句，应该没啥生词，大家都认识。

其中有个 it turns out to be，可以介绍一下，这是个短语，经常出现在美剧里面的对白。

翻译过来就是四个字“事实证明”。

所以，上面这整句话就是这样的：虽然我们可以使用某种并发安全的 set 集合，但是事实证明，一般来说，使用锁还是比较好的。

接下来老爷子就要解释为什么用锁比较好了。

我翻译上这句话的意思就是我没有乱说，都是有根据的，因为这是老爷子亲自解释的为什么他不用线程安全的 Set 集合。

第一个原因是这样说的：

Among the reasons is that this serializes interruptIdleWorkers, which avoids unnecessary interrupt storms, especially during shutdown. Otherwise exiting threads would concurrently interrupt those that have not yet interrupted.

英文是的，我翻译成中文，加上自己的理解是这样的。

首先第一句里面有个 “serializes interruptIdleWorkers”，这两个单词组合在一起还是有一定的迷惑性的。

serializes 在这里，并不是指我们 Java 中的序列化操作，而是需要翻译为“串行化”。

interruptIdleWorkers，这玩意根本就不是一个单词，这是线程池里面的一个方法：

在这个方法里面进来第一件事就是拿 mainLock 锁，然后尝试去做中断线程的操作。

由于有 mainLock.lock 的存在，所以多个线程调用这个方法，就被 serializes 串行化了起来。

串行化起来的好处是什么呢？

就是后面接着说的：避免了不必要的中断风暴（interrupt storms），尤其是调用 shutdown 方法的时候，避免退出的线程再次中断那些尚未中断的线程。

为什么这里特意提到了 shutdown 方法呢？

因为 shutdown 方法调用了 interruptIdleWorkers：

所以上面啥意思呢？

这个地方就要用一个反证法了。

假设我们使用的是并发安全的 Set 集合，不用 mainLock。

这个时候有 5 个线程都来调用 shutdown 方法，由于没有用 mainLock ，所以没有阻塞，那么每一个线程都会运行 interruptIdleWorkers。

所以，就会出现第一个线程发起了中断，导致 worker ，即线程正在中断中。第二个线程又来发起中断了，于是再次对正在中断中的中断发起中断。

额，有点像是绕口令了。

所以我打算重复一遍：对正在中断中的中断，发起中断。

因此，这里用锁是为了避免中断风暴（interrupt storms）的风险。

并发的时候，只想要有一个线程能发起中断的操作，所以锁是必须要有的。有了锁这个大前提后，反正 Set 集合也会被锁起来，索性就不需要并发安全的 Set 了。

所以我理解，在这里用 mainLock 来实现串行化，同时保证了 Set 集合不会出现并发访问的情况。

只要保证这个这个 Set 操作的时候都是被锁包裹起来的就行，因此，不需要并发安全的 Set 集合。

即注释上写的：Accessed only under mainLock.

记住了，有可能会被考哦。

然后，老爷子说的第二个原因：

It also simplifies some of the associated statistics bookkeeping of largestPoolSize etc.

这句话就是说的关于加锁好维护 largestPoolSize 这个参数，不再贅述了。

哦，对了，这是有个 etc，表示“诸如此类”的意思。

这个 etc 指的就是这个 completedTaskCount 参数，道理是一样的：

另一把锁

除了前面说的 mainLock 外，线程池里面其实还有一把经常被大家忽略的锁。

那就是 Worker 对象。

可以看到 Worker 是继承自 AQS 对象的，它的很多方法也是和锁相关的。

同时它也实现了 Runnable 方法，所以说到底它就是一个被封装起来的线程，用来运行提交到线程池里面的任务，当没有任务的时候就去队列里面 take 或者 poll 等着，命不好的就被回收了。

我们还是看一下它加锁的地方，就在很关键的 runWorker 方法里面：

java.util.concurrent.ThreadPoolExecutor#runWorker

那么问题就来了：

这里是线程池里面的线程，正在执行提交的任务的逻辑的地方，为什么需要加锁呢？

这里为什么又自己搞了一个锁，而不用已有的 ReentrantLock ，即 mainLock 呢？

答案还是写在注释里面：

我知道你看着这么大一段英文瞬间就没有了兴趣。

但是别慌，我带你细嚼慢咽。

第一句话就开门见山的说了：

Class Worker mainly maintains interrupt control state for threads running tasks.

worker 类存在的主要意义就是为了维护线程的中断状态。

维护的线程也不是一般的线程，是 running tasks 的线程，也就是正在运行的线程。

怎么理解这个“维护线程的中断状态”呢？

你去看 Worker 类的 lock 和 tryLock 方法，都各自只有一个地方调用。

lock 方法我们前面说了，在 runWorker 方法里面调用了。

在 tryLock 方法是在这里调用的：

这个方法也是我们的老朋友了，前面刚刚才讲过，是用来中断线程的。

中断的是什么类型的线程呢？

就是正在等待任务的线程，即在这里等着的线程：

java.util.concurrent.ThreadPoolExecutor#getTask

换句话说：正在执行任务的线程是不应该被中断的。

那线程池怎么知道那哪任务是正在执行中的，不应该被中断呢？

我们看一下判断条件：

关键的条件其实就是 w.tryLock() 方法。

所以看一下 tryLock 方法里面的核心逻辑是怎么样的：

核心逻辑就是一个 CAS 操作，把某个状态从 0 更新为 1，如果成功了，就是 tryLock 成功。

“0”、“1” 分别是什么玩意呢？

注释，答案还是在注释里面：

所以，tryLock 中的核心逻辑compareAndSetState(0, 1)，就是一个上锁的操作。

如果 tryLock 失败了，会是什么原因呢？

肯定是此时的状态已经是 1 了。

那么状态什么时候变成 1 呢？

一个时机就是执行 lock 方法的时候，它也会调用 tryAcquire 方法。

那 lock 是在什么时候上锁的呢？

runWorker 方法里面，获取到 task，准备执行的时候。

也就是说状态为 1 的 worker 肯定就是正在执行任务的线程，不可以被中断。

另外，状态的初始值被设置为 -1。

我们可以写个简单的代码，验证一下上面的三个状态：

首先我们定义一个线程池，然后调用 prestartAllCoreThreads 方法把所有线程都预热起来，让它们处于等待接收任务的状态。

你说这个时候，三个 worker 的状态分别是什么？

那必须得是 0 ，未上锁的状态。

当然了，你也有可能看到这样的局面：

-1 是从哪里来的呢？

别慌，我等下给你讲，我们先看看 1 在哪呢？

按照之前的分析，我们只需要往线程池里面提交一个任务即可：

这个时候，假如我们调用 shutdown 呢，会发什么？

当然是中断空闲的线程了。

那正在执行任务的这个线程怎么办呢？

因为是个 while 循环，等到任务执行完成后，会再次调用 getTask 方法：

getTask 方法里面会先判断线程池状态，这个时候就能感知到线程池关闭了，返回 null，这个 worker 也就默默的退出了。

好了，前面说了这么多，你只要记住一个大前提：自定义 worker 类的大前提是为了维护中断状态，因为正在执行任务的线程是不应该被中断的。

接着往下看注释：

We implement a simple non-reentrant mutual exclusion lock rather than use ReentrantLock because we do not want worker tasks to be able to reacquire the lock when they invoke pool control methods like setCorePoolSize.

这里解释了为什么老爷子不用 ReentrantLock 而是选择了自己搞一个 worker 类。

因为他想要的是一个不能重入的互斥锁，而 ReentrantLock 是可以重入的。

从前面分析的这个方法也能看出来，是一个非重入的方法：

传进来的参数根本没有使用，代码里面也没有累加的逻辑。

如果你还没反应过来是怎么回事的话，我给你看一下 ReentrantLock 里面的重入逻辑：

你看到了吗，有一个累加的过程。

释放锁的时候，又有一个与之对应的递减的过程，减到 0 就是当前线程释放锁成功：

而上面的累加、递减的逻辑在 worker 类里面通通是没有的。

那么问题又来了：如果是可以重入的，会发生什么呢？

目的还是很前面一样：不想打断正在执行任务的线程。

同时注释里面提到了一个方法：setCorePoolSize。

你说巧不巧，这个方法我之前写线程池动态调整的时候重点讲过呀：

可惜当时主要讲 delta>0 里面的的逻辑去了。

现在我们看一下我框起来的地方。

workerCountOf(ctl.get()) > corePoolSize 为 true 说明什么情况？

说明当前的 worker 的数量是多于我要重新设置的 corePoolSize，需要减少一点。

怎么减少呢？

调用 interruptIdleWorkers 方法。

这个方法我们前面刚刚分析了，我再拿出来一起看一下：

里面有个 tryLock，如果是可以重入的，会发生什么情况？

是不是有可能把正在执行的 worker 给中断了。

这合适吗？

好了，注释上的最后一句话：

Additionally, to suppress interrupts until the thread actually starts running tasks, we initialize lock state to a negative value, and clear it upon start (in runWorker).

这句话就是说为了在线程真正开始运行任务之前，抑制中断。所以把 worker 的状态初始化为负数(-1)。

大家要注意这个：and clear it upon start (in runWorker).

在启动的时候清除 it，这个 it 就是值为负数的状态。

老爷子很贴心，把方法都给你指明了：in runWorker.

所以你去看 runWorker，你就知道为什么这里上来先进行一个 unLock 操作，后面跟着一个 allow interrupts 的注释：

因为在这个地方，worker 的状态可能还是 -1 呢，所以先 unLock，把状态刷到 0 去。

同时也就解释了前面我没有解释的 -1 是哪里来的：

想明白了吗，-1 是哪里来的？

肯定是在启动过程中，执行了 workers.add 方法，但是还没有来得及执行 runWorker 方法的 worker 对象，它们的状态就是 -1。

最后说一句

好了，看到了这里了，点赞安排一个吧。写文章很累的，需要一点正反馈。

给各位读者朋友们磕一个了：

顾名思义，这是一个作用在Toolbar上的布局，但是要注意的是CollapsingToolbarLayout不能单独存在，它必须要作为AppBarLayout的直接子布局来使用，而AppBarLayout又必须是CoordinatorLayout（监听子控件的事件，做出合理的响应）的子布局。所以可以得到：

<?xml version="1.0" encoding="utf-8"?>

<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:app="http://schemas.android.com/apk/res-auto"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    >

    <com.google.android.material.appbar.AppBarLayout

        android:layout_width="match_parent"

        android:layout_height="250dp"

        android:id="@+id/appbar">

        <com.google.android.material.appbar.CollapsingToolbarLayout

            android:id="@+id/collapsing_toolbar"

            android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"

            app:contentScrim="?attr/colorPrimary"

            app:layout_scrollFlags="scroll|exitUntilCollapsed"

            android:layout_width="match_parent"

            android:layout_height="match_parent">

        </com.google.android.material.appbar.CollapsingToolbarLayout>

    </com.google.android.material.appbar.AppBarLayout>

</androidx.coordinatorlayout.widget.CoordinatorLayout>

 

接着为了让标题栏高级一些，在CollapsingToolbarLayout中放一张图片和一个Toolbar

<?xml version="1.0" encoding="utf-8"?>

<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:app="http://schemas.android.com/apk/res-auto"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    >

    <com.google.android.material.appbar.AppBarLayout

        android:layout_width="match_parent"

        android:layout_height="250dp"

        android:id="@+id/appbar">

        <com.google.android.material.appbar.CollapsingToolbarLayout

            android:id="@+id/collapsing_toolbar"

            android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"

            app:contentScrim="?attr/colorPrimary"

            app:layout_scrollFlags="scroll|exitUntilCollapsed"

            android:layout_width="match_parent"

            android:layout_height="match_parent">

            <ImageView

                android:layout_width="match_parent"

                android:layout_height="match_parent"

                android:scaleType="centerCrop"

                app:layout_collapseMode="parallax"

                android:id="@+id/fruit_image_view"/>

            <androidx.appcompat.widget.Toolbar

                android:layout_width="match_parent"

                android:layout_height="?attr/actionBarSize"

                android:id="@+id/toolbar"

                app:layout_collapseMode="pin"/>

        </com.google.android.material.appbar.CollapsingToolbarLayout>

    </com.google.android.material.appbar.AppBarLayout>



</androidx.coordinatorlayout.widget.CoordinatorLayout>

 

这里有一个layout_collapseMode属性，表示在折叠过程中的折叠样式，parallax表示在折叠过程中会产生错位偏移，而pin表示会始终不变。

NestedScrollView

标题栏完成之后，就是开始编写水果内容的部分了。这里使用NestedScrollView,这和ScrollView，RecyclerView一样都是可以通过滚动的方式来查看屏幕外的数据。同样的和之前的RecyclerView一样，这里也要指定一个布局行为。 由于NestedScrollView和ScrollView一样，只允许存在一个直接子布局，这里就可以嵌套一个LinearLayout作为它的直接子布局。然后在LinearLayout中放具体的内容就可以了。

    <androidx.core.widget.NestedScrollView

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        app:layout_behavior="@string/appbar_scrolling_view_behavior">

        <LinearLayout

            android:orientation="vertical"

            android:layout_width="match_parent"

            android:layout_height="wrap_content">

            <androidx.cardview.widget.CardView

                android:layout_marginTop="35dp"

                android:layout_marginLeft="15dp"

                android:layout_marginRight="15dp"

                android:layout_marginBottom="15dp"

                app:cardCornerRadius="4dp"

                android:layout_width="match_parent"

                android:layout_height="wrap_content">

                <TextView

                    android:id="@+id/fruit_content_text"

                    android:layout_width="wrap_content"

                    android:layout_height="wrap_content"

                    android:layout_margin="10dp"/>

            </androidx.cardview.widget.CardView>

        </LinearLayout>

    </androidx.core.widget.NestedScrollView>

 

这里添加了一个布局行为（和之前的RecyclerView一样）。 为了让之前的知识尽可能用到，这里再加一个悬浮按钮。

    <com.google.android.material.floatingactionbutton.FloatingActionButton

        android:src="@drawable/ic_comment"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        app:layout_anchor="@id/appbar"

        app:layout_anchorGravity="bottom|end"/>

 

这是目前的效果图接着就是通过逻辑代码将数据给填进去了。

MainActivity→FruitActivity

由于数据是在MainActivity得到的，FruitActivity并不能得到数据，所以需要通过MainActivity将数据传输过去，这里可以用Intent来传输。

        ViewHolder viewHolder=new ViewHolder(view);

        viewHolder.cardView.setOnClickListener(new View.OnClickListener() {

            @Override

            public void onClick(View v) {

                Intent intent=new Intent(context,FruitActivity.class);

                int position=viewHolder.getAdapterPosition();

                Fruit fruit=FruitList.get(position);

                intent.putExtra("fruitName",fruit.getName());

                intent.putExtra("fruitId",fruit.getId());

                context.startActivity(intent);

            }

        });

 

这里选择在每次生成ViewHolder的时候就为其中的cardView绑定点击事件，将id和name传递给FruitAcitivity。

FruitActivity进行数据处理。

       ImageView imageView=findViewById(R.id.fruit_image_view);

        TextView textView=findViewById(R.id.fruit_content_text);

        Toolbar toolbar=findViewById(R.id.toolbar);

        //将ActionBar换成toolbar

        setSupportActionBar(toolbar);

        ActionBar actionBar=getSupportActionBar();

        if(actionBar!=null){

            actionBar.setDisplayHomeAsUpEnabled(true);

        }

        CollapsingToolbarLayout collapsingToolbarLayout=findViewById(R.id.collapsing_toolbar);

        Intent intent=getIntent();

        String name=intent.getStringExtra(fruitName);

        int id=intent.getIntExtra(fruitId,0);

        //用Glide来加载图片

        Glide.with(this).load(id).into(imageView);

        textView.setText(ExtraText(name));

        //为可折叠标题栏设置标题。

        collapsingToolbarLayout.setTitle(name);

 

充分利用状态栏空间。

为ImageView的父布局和其本身添加fitsSystemWindows属性。

<?xml version="1.0" encoding="utf-8"?>

<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:app="http://schemas.android.com/apk/res-auto"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    android:fitsSystemWindows="true"

    >

    <com.google.android.material.appbar.AppBarLayout

        android:fitsSystemWindows="true"

        android:layout_width="match_parent"

        android:layout_height="250dp"

        android:id="@+id/appbar">

        <com.google.android.material.appbar.CollapsingToolbarLayout

            android:fitsSystemWindows="true"

            android:id="@+id/collapsing_toolbar"

            android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar"

            app:contentScrim="?attr/colorPrimary"

            app:layout_scrollFlags="scroll|exitUntilCollapsed"

            android:layout_width="match_parent"

            android:layout_height="match_parent">

            <ImageView

                android:fitsSystemWindows="true"

                android:layout_width="match_parent"

                android:layout_height="match_parent"

                android:scaleType="centerCrop"

                app:layout_collapseMode="parallax"

                android:id="@+id/fruit_image_view"/>

            <androidx.appcompat.widget.Toolbar

                android:layout_width="match_parent"

                android:layout_height="?attr/actionBarSize"

                android:id="@+id/toolbar"

                app:layout_collapseMode="pin"/>

        </com.google.android.material.appbar.CollapsingToolbarLayout>

    </com.google.android.material.appbar.AppBarLayout>

    <androidx.core.widget.NestedScrollView

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        app:layout_behavior="@string/appbar_scrolling_view_behavior">

        <LinearLayout

            android:orientation="vertical"

            android:layout_width="match_parent"

            android:layout_height="wrap_content">

            <androidx.cardview.widget.CardView

                android:layout_marginTop="35dp"

                android:layout_marginLeft="15dp"

                android:layout_marginRight="15dp"

                android:layout_marginBottom="15dp"

                app:cardCornerRadius="4dp"

                android:layout_width="match_parent"

                android:layout_height="wrap_content">

                <TextView

                    android:id="@+id/fruit_content_text"

                    android:layout_width="wrap_content"

                    android:layout_height="wrap_content"

                    android:layout_margin="10dp"/>

            </androidx.cardview.widget.CardView>

        </LinearLayout>

    </androidx.core.widget.NestedScrollView>

    <com.google.android.material.floatingactionbutton.FloatingActionButton

        android:src="@drawable/ic_comment"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        app:layout_anchor="@id/appbar"

        app:layout_anchorGravity="bottom|end"/>

</androidx.coordinatorlayout.widget.CoordinatorLayout>

 

为FruitActivity自定义一个主题。

<?xml version="1.0" encoding="utf-8"?>

<resources>

    <style name="FruitActivityTheme" parent="Theme.ListView">

        <item name="android:statusBarColor">

            @android:color/transparent

        </item>

    </style>

</resources>

 

引入这个主题

 <activity android:name=".FruitActivity" android:theme="@style/FruitActivityTheme">

Android沿用了Java的线程模型，一个Android应用在创建时会开启一个线程，常称作主线程，也叫做UI线程，如果有请求网络等耗时操作时，就需要开启子线程去处理。因此，此文对多线程进行梳理总结

线程基础

1. 进程与线程

这两个的区分在我的另一篇文章# Android面向面试复习-操作系统+计网篇中已经提及，简单复习一下。进程是操作系统结构的基础，是程序在一个数据集合上运行的过程，是系统进行资源分配和调度的基本单位。进程可以看作程序的实体，也是线程的容器。线程是操作系统调度的最小单元，一个进程中可以创建多个线程。这些线程拥有各自的计数器，堆栈，局部变量等属性，并且能够访问共享的内存变量

2. 线程的状态

Java线程在运行的生命周期可能会处于六种不同的状态，如下

• New：新创建状态，线程被创建，还没有调用start方法，运行之前还有一些基础工作
• Runnable：可运行状态，一旦调用start方法，就会处于Runnable状态。处于这个状态的线程可能正在运行，也可能没有，取决于操作系统的调度
• Blocked：阻塞状态，表示线程被锁阻塞，暂不能活动
• Waiting：等待状态，线程暂时不活动，并且不运行任何代码，这消耗最少的资源，知道调度器重新激活这个线程
• Timed Waiting：超时等待，可以在指定的时间自行返回
• Terminated：终止状态，表示当前线程已经执行完毕，比如run方法正常执行退出，或者因为没有被捕获的异常而终止

3. 创建线程

• 继承Thread类，重写run方法
• 实现Runnable接口，重写run方法
• 实现Callable接口，重写call方法

4. 理解中断

当线程的run方法执行完毕，或者方法里出现没有捕获的异常时，线程就要终止。早期Java版本中有stop方法可以终止线程，现在已经被弃用。现版本用interrupt来中断线程，当一个线程调用interrupt方法时，它的中断标志位将被置为true。线程会时不时的检测这个中断标记位，以判断线程是否应该被中断，要想知道线程是否被置位，可以调用isInterrupted方法查看返回值。还可以调用静态方法interrupted来对中断标志位进行复位。但是如果一个线程被阻塞，就无法检测中断状态。如果一个线程处于阻塞状态，那么线程在检查中断标志位时若发现中断标志位为true，就会在阻塞方法调用处抛出阻塞异常，并且在抛出异常前将线程中断标志位复位，即重新设置为false。需要注意的是被中断的线程不一定会终止，中断线程是为了引起线程的注意，被中断的线程可以决定如何响应中断。如果是比较重要的线程，则不会理会中断。而大部分情况是线程会将中断作为一个终止的请求。另外，不要在底层代码里捕获InterruptedException不做处理，这里介绍两种合适的处理方式

1. 在catch子句中，调用Thread.currentThread().interrupt()来设置中断状态。因为在抛出异常后中断标志位会复位，让外界通过判断isInterrupted()来决定是终止还是继续下去

void test(){

     try{

        sleep(50);

     }catch(InterruptedException e){

        Thread.currentThread().interrupt();

     }

}

 

2. 更好的做法是直接抛出异常，方便调用者捕获

void test() throw InterruptedException{

     sleep(50);

}

 

5. 安全的终止线程

上一点我们提到了中断，首先用中断来终止线程，如下

public class test{

    public static void main(String[] args) throws InterruptedException {

        MyRunner runner = new MyRunner();

        Thread thread = new Thread(runner, "MyRunner");

        thread.start();

        TimeUnit.MILLISECONDS.sleep(10);

        thread.interrupt();

    }

    

    public static class MyRunner implements Runnable{

        private long i;



        @Override

        public void run() {

            while (!Thread.currentThread().isInterrupted()){

                i++;

                System.out.println("i=" + i);

            }

            System.out.println("stop");

        }

    }

}

 

代码里用sleep方法使得main线程沉睡10ms，留给MyRunner足够的时间来感知中断从而结束，还可以采用boolean变量来控制是否需要停止线程，如下

public class test{

    public static void main(String[] args) throws InterruptedException {

        MyRunner runner = new MyRunner();

        Thread thread = new Thread(runner, "MyRunner");

        thread.start();

        TimeUnit.MILLISECONDS.sleep(10);

        runner.cancel();

    }



    public static class MyRunner implements Runnable{

        private long i;

        private volatile boolean on = true;

        @Override

        public void run() {

            while (on){

                i++;

                System.out.println("i=" + i);

            }

            System.out.println("stop");

        }



        public void cancel(){

            on = false;

        }

    }

}

 

结果如下，两段代码是类似的

此处说明线程执行到了run方法的末尾，即将终止

线程同步

在多线程应用中，两个或者两个以上的线程需要共享对同一个数据的存取，如果两个线程存取相同的对象，并且每一个线程都调用了修改该对象的方法，这种情况被称为竞态条件。此时如果不用同步，是无法保证数据原子性的，所以我们就需要用到锁

1. 重入锁与条件对象

synchronized关键字自动提供了锁以及相关条件。大多数需要显示锁的情况使用synchronized非常方便。但是等我们了解了重入锁和条件对象时，能更好的理解synchronized关键字。重入锁ReentrantLock是Java SE 5.0引入的，就是支持重进入的锁，表示该锁能够支持一个线程对资源的重复加锁。具体结构如下

Lock mLock = new ReentrantLock();

mLock.lock();

try {

    

}catch (){

    

}finally {

    mLock.unlock();

}

 

这一结构确保任何时刻只有一个线程进入临界区，临界区就是同一时刻只有一个任务访问的代码区域。一旦一个线程封锁了锁对象，其他线程都无法进入。把解锁操作放到finally区域内是十分必要的，如果因为某些异常，锁资源是必须要释放的，否则其他资源将被永久阻塞。进入临界区时，却发现在某一个条件满足之后它才能执行，这时可以用一个条件对象来管理那些已经获得了一把锁但是却不能做有用工作的线程，条件对象又被称作条件变量。通过下面例子来说明为何需条件对象。假设一个场景需要用支付宝转账，我们先写支付宝类，它的构造方法需传入支付宝账户的数量和每个账户的账户金额。

public class Alipay{

    private double[] accounts;

    private Lock alipayLock;

    public Alipay(int n, double money){

        accounts = new double[n];

        alipayLock = new ReentrantLock();

        for(int i = 0; i < accounts.length; i++){

            accounts[i] = money;

        }

    }

}

 

接下来实现转账，需要一个from转账方，和to接收方，amount是转账金额，如下

public void transfer(int from, int to, int amount){

    alipayLock.lock();

    try {

        while (accounts[from] < amount){

            //wait

        }

    }catch (){

        

    }finally {

        alipayLock.unlock();

    }

}

 

有可能会出现转账方余额不足的情况，如果有其他线程给这个转账方再转足够的钱，就可以转账成功了，但是这个线程已经获取了锁，具有排他性，别的线程无法获取锁来进行存款操作，这时我们就需要引入对象锁。一个锁对象拥有多个相关条件对象，可以用new Condition方法获得一个条件对象，我们得到条件对象后调用await方法，当前线程就被阻塞了并放弃了锁，相关代码如下

public class Alipay{

    private double[] accounts;

    private Lock alipayLock;

    private Condition condition;

    public Alipay(int n, double money){

        accounts = new double[n];

        alipayLock = new ReentrantLock();

        condition = alipayLock.newCondition();

        for(int i = 0; i < accounts.length; i++){

            accounts[i] = money;

        }

    }



    public void transfer(int from, int to, int amount) throws InterruptedException{

        alipayLock.lock();

        try {

            while (accounts[from] < amount){

                condition.await();

            }

        }catch (){



        }finally {

            alipayLock.unlock();

        }

    }

}

 

一旦一个线程调用await方法，就会进入该条件的等待集并处于阻塞状态，直到另一个线程调用了同一个条件的signalAll()方法时为止。当另一个线程转账给我们此前的转账方时，只重复调用singnalAll()方法，就会重新激活因为这一条件而等待的所有线程，代码如下

public void transfer(int from, int to, int amount) throws InterruptedException{

    alipayLock.lock();

    try {

        while (accounts[from] < amount){

            condition.await();

        }

        accounts[from] = accounts[from] - amount;

        accounts[to] = accounts[to] + amount;

        condition.signalAll();

    }catch (){



    }finally {

        alipayLock.unlock();

    }

}

 

当调用了signalAll时并不是立即激活一个等待线程，它仅仅解除了等待线程的阻塞，以便这些线程能够在当前线程退出同步方法后，通过竞态实现对对象的访问，还有个方法是signal，它则是随机解除某个线程的阻塞。如果该线程仍然不能运行，则再次被阻塞，如果没有其他线程再次调用signal，那么系统就死锁了

2. 同步方法

Lock接口和Condition接口为程序设计提供了高度的锁定控制，然而大多数情况下并不需要那样的控制，并且可以使用一种嵌入到Java语言内部的机制。Java中每一个对象都有一个内部锁，如果一个方法用synchronized关键字修饰，那么对象的锁将保护整个方法，也就是说，要调用该方法，线程必须获得内部的对象锁，如下

public synchronized void method(){

    ···

}

 

这段代码等价于

Lock mLock = new ReentrantLock();

public void method(){

    mLock.lock();

    try{

        ···

    }finally{

        mLock.unlock();

    }

}

 

对于上面转账的例子，可以将Alipay的transfer方法声明为synchronized，而不是使用一个显示的锁。内部对象锁只有一个相关条件，wait方法将一个线程添加到等待集中，使用notifyAll或notify方法解除等待线程的阻塞状态。也就是说wait相当于调用condition.await()，notifyAll等价于signalAll，所以前面例子里的transfer方法也可以这么写

public synchronized void transfer(int from, int to, int amount) throws InterruptedException{

    while (accounts[from] < amount){

        wait();

    }

    accounts[from] = accounts[from] - amount;

    accounts[to] = accounts[to] + amount;

    notifyAll();

}

 

在此可以看到，使用sychronized关键字来编码要简练很多，由该锁来管理那些试图进入synchronized方法的线程，由该锁中的条件来管理那些调用wait的线程

3. 同步代码块

除了调用同步方法来获得锁，还可以通过使用同步代码块，如下

synchronized(obj){

    ···

}

 

其获得了obj的锁，obj是一个对象，我们用同步代码块进行改写上面的例子

public class Alipay{

    private double[] accounts;

    private Object lock = new Object();

    private Condition condition;

    public Alipay(int n, double money){

        accounts = new double[n];

        for(int i = 0; i < accounts.length; i++){

            accounts[i] = money;

        }

    }



    public synchronized void transfer(int from, int to, int amount) throws InterruptedException{

        synchronized (lock){

            accounts[from] = accounts[from] - amount;

            accounts[to] = accounts[to] + amount;

        }

    }

}

 

在这里创建了一个名为lock的Object类，为的是使用Object类所持有的锁。同步代码块是非常脆弱的，通常不推荐使用，一般实现同步最好用Java的并发包下的集合类，比如阻塞队列。如果同步方法适合自己的程序，尽量使用同步方法，这样可以减少编写代码的数量，减少出错的概率，如果特别需要使用Lock/Condition结构提供的独有特性时，才使用Lock/Condition

4. volatile

有时，仅仅为了读写一个或者两个实例域就使用同步的话，显得开销过大，而volatile关键字为实例域的同步访问提供了免锁机制。如果声明一个域为volatile的话，那么编译器和虚拟机知道该域是可能被另一个线程并发更新的。当一个共享变量被volatile关键字修饰后，就具备了两个含义，一个含义是线程修改了变量的值时，变量的新值对于其他线程是立即可见的。另一个含义是禁止使用指令重排序，分为编译期重排序和运行时重排序。先来看一段代码，假设线程1先执行，2后执行，如下

//线程1

boolean stop = false;

while(!stop){

    //doSomething

}



//线程2

stop = true;

 

这是一个线程中断的代码，但是这段代码不一定会将线程中断，虽说无法中断线程这个情况出现的概率很小，但是一旦发生便是死循环。因为每个线程都有私有的工作内存，因此线程1运行时会拷贝一份stop的值放入私有工作内存中，当线程2更改了stop的变量值并返回后，线程2突然需要做其他操作，这时就无法将更改的stop变量写入主存中，这样线程1就不知道线程2对stop变量进行了更改，因此线程1会一直执行下去。当stop用volatile修饰，线程2修改stop值时，会强制将修改的值立刻写入主存，这样使得线程1的工作内存中的stop变量缓存无效，这样线程1在此读取变量stop的值时就会去主存读取

volatile不保证原子性

另外volatile不保证原子性，可看如下代码演示

class Test {

    public volatile int inc = 0;

    public void increase() {

        inc++;

    }



    public static void main(String[] args) {

        final Test test = new Test();

        for(int i=0;i<10;i++){

            new Thread(() -> {

                for(int j=0;j<1000;j++)

                    test.increase();

            }).start();

        }

        //保证前面的线程都执行完

        while(Thread.activeCount()>1)

            Thread.yield();

        System.out.println(test.inc);

    }

}

 

这段代码每次运行的结果都不一致，因为自增操作是不具备原子性的。自增操作里包含了读取原始值、加1、写入工作内存这三个子操作，也就是说这三个子操作可能被割裂执行。

volatile保证有序性

volatile关键字能禁止指令重排序，因此能保证有序性。禁止指令重排序有两层含义，其一是指代码运行到volatile变量操作时，在其前面的操作已经全部执行完毕，并且结果会对后面的操作可见，在其后面的操作还未执行。其二是进行指令优化时，在volatile变量之前的语句不能在volatile变量之后执行

正确使用volatile关键字

synchronized关键字可防止多个线程同时执行一段代码，但是这会很影响程序的执行效率。volatile关键字在有些时候会优于synchronized关键字。但是要注意volatile关键字时无法替代synchronized关键字的，因为其无法保证原子性，通常来说，使用volatile关键字需要具备以下两个条件：

1. 对变量的写操作不依赖于当前值
2. 该变量没有包含在具有其他变量的不变式中

关于第一点，就是上面提到的自增自减操作。关于第二点，举个例子，包含一个不变式：下界总是小于或等于上界，代码如下

public class NumberRange {

    private volatile int lower, upper;

    public int getLower() { return lower; }

    public int getUpper() { return upper; }

    public void setLower(int value) { 

        if (value > upper) 

            throw new IllegalArgumentException(...);

        lower = value;

    }

    public void setUpper(int value) { 

        if (value < lower) 

            throw new IllegalArgumentException(...);

        upper = value;

    }

}

 

这种方式定义的upper和lower并不能充分实现类的线程安全，如果两个线程在同一时间使用不一致的值执行setLower和setUpper的话，就会使范围处于不一致的状态。例如，如果初始状态是(0,5)，同一时间内，两个线程分别调用setLower(4)和setUpper(3)，虽然这两个交叉存入的值是不符合条件的，但是这两个线程都会通过用于保护不变式的检查，使得最后范围是(4,3)，显然是不对的

1. Builder

Retrofit通过Retrofit.Builder创建，主要是配置各种工厂Factory。

val retrofit = Retrofit.Builder()

    .baseUrl("this is baseUrl")

    .addCallAdapterFactory(RxJava2CallAdapterFactory.create())

    .addConverterFactory(GsonConverterFactory.create())

    .build()

 

Builder.builder()主要有五个步骤：

1. 获取Platform对象，Platform是平台适配器，主要为了跨平台使用，类如安卓平台实现就是Android。
2. 初始化CallFactroy，CallFactroy的作用是生产realCall，网络请求由他发出。默认值是OkHttp的OKHttpClient。
3. 初始化Executor，默认通过Platform获取。
4. 初始化CallAdapter.Factroy，CallAdapter.Factroy生产CallAdapter，CallAdapter是realCall的适配器，通过对realCall的包装，实现Executor，java8的Futrue，rxjava等调度方法。存在多个，顺序是自定义配置-->默认配置。默认配置通过Platform获得。
5. 初始化Converter.Factory，Converter.Factory生产Converter，Converter是数据转换器，将返回的数据转换为需要的数据，一般转换为我们要用的对象。存在多个，顺序是内置配置-->自定义配置-->默认配置。默认配置通过Platform获得。

class Builder{



    Builder(Platform platform) {

        this.platform = platform;

    }



    public Builder() {

        //step 0

        this(Platform.get());

    }



    public Retrofit build() {

        if (baseUrl == null) {

            throw new IllegalStateException("Base URL required.");

        }



        // step1

        okhttp3.Call.Factory callFactory = this.callFactory;

        if (callFactory == null) {

            callFactory = new OkHttpClient();

        }



        //step2

        Executor callbackExecutor = this.callbackExecutor;

        if (callbackExecutor == null) {

            callbackExecutor = platform.defaultCallbackExecutor();

        }



        //step3

        List<CallAdapter.Factory> callAdapterFactories = new ArrayList<>(this.callAdapterFactories);

        callAdapterFactories.addAll(platform.defaultCallAdapterFactories(callbackExecutor));



        //step4

        List<Converter.Factory> converterFactories = new ArrayList<>(

                1 + this.converterFactories.size() + platform.defaultConverterFactoriesSize());

        converterFactories.add(new BuiltInConverters());

        converterFactories.addAll(this.converterFactories);

        converterFactories.addAll(platform.defaultConverterFactories());



        return new Retrofit(callFactory, baseUrl, unmodifiableList(converterFactories),

                unmodifiableList(callAdapterFactories), callbackExecutor, validateEagerly);

    }

}

 

到这里，Retrofit对象创建完成，一个大致的结构如下图：

2. 创建API对象

Retrofit通过定义网络请求的接口设置请求参数和返回类型，通过调用retrofit.create()创建这个接口的对象，调用这个对象的方法生成最终的网络请求。

interface MyService {

    @GET("/user")

    fun getUser(): Observable<Response<User>>

}



val myServiceClass: MyService = retrofit.create(MyService::class.java)

 

进入到create方法，可以看到是直接调用Proxy.newProxyInstance()方法创建出对象。这是标准库提供的动态代理机制，在运行时创建接口的实例对象。

Proxy.newProxyInstance()方法有三个参数：

• classLoader: 类加载器

• interfaces:需要实现的接口

• InvocationHandler:代理方法

public <T> T create(final Class<T> service) {

    return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service },

            new InvocationHandler() {

                private final Platform platform = Platform.get();

                private final Object[] emptyArgs = new Object[0];



                @Override public @Nullable Object invoke(Object proxy, Method method,

                                                         @Nullable Object[] args) throws Throwable {

                    if (method.getDeclaringClass() == Object.class) {

                        return method.invoke(this, args);

                    }

                    if (platform.isDefaultMethod(method)) {

                        return platform.invokeDefaultMethod(method, service, proxy, args);

                    }

                    return loadServiceMethod(method).invoke(args != null ? args : emptyArgs);

                }

            });

}

 

为了更好的理解动态代理，可以当做动态代理自动帮我们生成一个接口的实现类。将所有的方法都通过handler.invoke()代理，如下面的代码所示。只不过动态代理是运行时生成的这个类，并且是直接生成了字节码。

interface MyService {

    @GET("/user")

    fun getUser(): Observable<Response<User>>



    @GET("/name")

    fun getName(userId: String): Observable<Response<String>>

}



//自动生成的代码示例

class SuspendServiceProxy implements SuspendService {

    InvocationHandler handler;



    @NonNull

    @Override

    public Observable<Response<User>> getUser() {

        return handler.invoke(

                this,

                SuspendService.class.getMethod("getUser", String.class),

                new Object[]{}

        );

    }



    @NonNull

    @Override

    public Observable<Response<String>> getName(@NonNull String userId) {

        return handler.invoke(

                this,

                SuspendService.class.getMethod("getName", String.class),

                new Object[]{userId}

        );

    }

}

 

3. 创建请求对象

创建好API对象之后，就可以调用它的方法创建请求对象。

val observable = myServiceClass.getUser()

 

根据前面可以知道，这个方法代理给了InvocationHandler，在这个方法首先判断这个方法对象是不是实体对象，如果是的话就直接调用就行。

如果不是一个对象，就把调用再代理给ServiceMethod。首先调用loadServiceMethod()创建ServiceMethod对象，然后调用invoke()方法得到返回值。

public @Nullable Object invoke(Object proxy, Method method, @Nullable Object[] args) throws Throwable {

    // 判断这个方法对象是不是实体对象，如果是的话就直接调用

    if (method.getDeclaringClass() == Object.class) {

        return method.invoke(this, args);

    }

    // 判断这个方法对象是不是实体对象，如果是的话就直接调用

    if (platform.isDefaultMethod(method)) {

        return platform.invokeDefaultMethod(method, service, proxy, args);

    }

    return loadServiceMethod(method).invoke(args != null ? args : emptyArgs);

}

 

3.1. 创建ServiceMethod对象

ServiceMethod是Retrofit内部的自定义的代理方法，实际的逻辑是交给它处理。

abstract class ServiceMethod<T> {

    abstract @Nullable T invoke(Object[] args);

}

 

loadServiceMethod()方法获取ServiceMethod对象。

方法对象Method作为Key缓存ServiceMethod对象在Retrofit中，因为创建ServiceMethod是一个耗时过程，所以弄成单例模式。

如果拿不到缓存，就调用ServiceMethod.parseAnnotations()创建一个ServiceMethod对象。

private final Map<Method, ServiceMethod<?>> serviceMethodCache = new ConcurrentHashMap<>();





ServiceMethod<?> loadServiceMethod(Method method) {

    ServiceMethod<?> result = serviceMethodCache.get(method);

    if (result != null) return result;



    synchronized (serviceMethodCache) {

        result = serviceMethodCache.get(method);

        if (result == null) {

            result = ServiceMethod.parseAnnotations(this, method);

            serviceMethodCache.put(method, result);

        }

    }

    return result;

}

 

ServiceMethod.parseAnnotations()中只做了一件事，创建RequestFactory然后将创建ServiceMethod的工作又交给了子类HttpServiceMethod处理。

RequestFactory是接口的参数配置，通过解析接口的注解，返回值，入参及其注解等获得这些参数。

之后将解析完成的数据传递给HttpServiceMethed，由它继续创建ServiceMethod。

abstract class ServiceMethod<T> {

    static <T> ServiceMethod<T> parseAnnotations(Retrofit retrofit, Method method) {

        RequestFactory requestFactory = RequestFactory.parseAnnotations(retrofit, method);

        ...

        return HttpServiceMethod.parseAnnotations(retrofit, method, requestFactory);

    }



    abstract @Nullable T invoke(Object[] args);

}

 

3.1.1. 创建RequstFactory

RequestFactory内部也是一个Builder模式。主要做了两件事：

1. 遍历接口注解，初始化配置参数，这里读取的是POST、GET等注释。
2. 遍历入参及其注解，将入参转换为ParameterHandler对象，将每个参数的设置配置的逻辑代理给了它处理。

final class RequestFactory {

    static RequestFactory parseAnnotations(Retrofit retrofit, Method method) {

        return new RequestFactory.Builder(retrofit, method).build();

    }



   

    }

}

  

3.1.2.2. OkHttpCall

最终创建的网络请求对象是OkHttpCall。

OkHttpCall实现了Retrofit.Call接口，这个接口与OkHttp.Call基本一致，这里只介绍它的三个方法：

1. execute()同步发起请求并且返回请求体Response。
2. enqueue()异步发起请求，通过Callback通信，需要注意的是处理的回调也是在异步中调用的。
3. cancel()取消请求。

查看OkHttpCall的实现，可以发现所有的Call接口方法的具体实现都是代理给了rawCall。

cancel()直接代理给rawCall.cancel()。

execute()代理给rawCall.execute()，将返回值交给parseResponse()转换了一次。

enqueue()代理给rawCall.enqueue()，多加了一层Callback回调，在成功回调中也是交给parseResponse()转换之后再回调给原始的Callback。

也就是说OkHttpCall把所有的逻辑静态代理给了rawCall，这样做的好处是可以在对应的地方做一下额外的处理，也就是获得返回值通过parseResponse()转换数据。

fAndroid平台默认的CallBackExecutor在Platform的实现类Android中，将Runnable抛到MainHandler中，实现回调到主线程。

static final class Android extends Platform {



    @Override public Executor defaultCallbackExecutor() {

        return MainThreadExecutor();

    }



    static class MainThreadExecutor implements Executor {

        private final Handler handler = new Handler(Looper.getMainLooper());



        @Override public void execute(Runnable r) {

            handler.post(r);

        }

    }

}

 

3.1.2.3.2. RxJava2CallAdapterFactory

RxJava2CallAdapterFactory只在返回类型是Observable之类的时候创建CallAdapter。

public final class RxJava2CallAdapterFactory extends CallAdapter.Factory {



    @Override

    public @Nullable CallAdapter<?, ?> get(

            Type returnType, Annotation[] annotations, Retrofit retrofit) {

        Class<?> rawType = getRawType(returnType);

        

        if (rawType != Observable.class) { //省略了其他类型

            return null;

        }



        boolean isResult = false;

        boolean isBody = false;

        Type responseType;

        



        Type observableType = getParameterUpperBound(0, (ParameterizedType) returnType);

        Class<?> rawObservableType = getRawType(observableType);

        if (rawObservableType == Response.class) {

            responseType = getParameterUpperBound(0, (ParameterizedType) observableType);

        }

        ...

        return new RxJava2CallAdapter(...);

    }

}

 

RxJava2CallAdapter中的adapt()将Call封装成observable返回。

final class RxJava2CallAdapter<R> implements CallAdapter<R, Object> {

    

    @Override public Object adapt(Call<R> call) {

        Observable<Response<R>> observable = new CallExecuteObservable<>(call);

        ...

        return RxJavaPlugins.onAssembly(observable);

    }

}

 

最后进到CallExecuteObservable，在启动的时候调用call.execute()并将结果抛给观察者。

final class CallExecuteObservable<T> extends Observable<Response<T>> {

    private final Call<T> originalCall;



    CallExecuteObservable(Call<T> originalCall) {

        this.originalCall = originalCall;

    }



    @Override protected void subscribeActual(Observer<? super Response<T>> observer) {

        Call<T> call = originalCall.clone();

        try {

            ...

            Response<T> response = call.execute();

            observer.onNext(response);

        }

    }

}

 

3.2. 回顾

1. Api接口实例动态代理给HttpServiceMethod。
2. 网络请求的真实执行者是OkHttpClient创建的RealCall。
3. Api接口的调用到RealCall直接有两层静态代理 OkHttpCall和CallAdapter。
4. OkHttpCall代理了RealCall，额外调用Converter做序列化处理。
5. CallAdapter代理了OkHttpCall，可以在这里做扩展，将Call转换为实际的返回类型。

4. 协程实现

在看Retrofit如何实现协程之前，先梳理一下协程的基本概念。

当有一个延迟任务，后续的逻辑又需要等待这个任务执行完成返回数据，能继续执行，为了不阻塞线程，一般就需要就需要通过线程调度和传递回调来通信。在使用了协程之后，却只需要像同步代码那样书写，就可以完成这些操作。

但这并不是什么黑魔法，并不是用了协程之后不需要线程调度和传递回调，而是将这些繁琐的事进行复杂的封装并且为我们自动生成。将回调封装成Continuation，将线程的调度封装成调度器。

Continuation ，调用它的 resume 或者 resumeWithException 来返回结果或者抛出异常，跟我们所说的回调一模一样。

调度器的本质是一个协程拦截器，它拦截的对象就是Continuation，进而在其中实现回调的调度。调度器一般使用现成的，类如Dispatchers.Main，如果去挖它的源码，你会发现到了最后，还是使用的handler.post()，也跟我们所说的线程调度一模一样。

而前面有讲到Retrofit的实现很多时候需要依据返回类型做不同的处理，所以就需要了解协程是如何自动生成的回调代码和如何传递回调。写一个简单的协程接口，看一下转换后的Java代码，以及尝试在Java代码中调用协程接口。

可以看到返回值String被封装成了Continuation<String>作为入参传递，思考一下回调不也是这样实现的。

真实的返回值成了Object(用于状态机状态切换)。

//Kotlin代码

interface SuspendService {

    suspend fun C(c1: Long): String

}



//字节码转化的Java代码

public interface SuspendService {

   @Nullable

   Object C(long var1, @NotNull Continuation var3);

}



//尝试在Java中调用suspend方法

class MMM {

    SuspendService service;



    public static void main(String[] args) {

        MMM mmm = new MMM();

        mmm.service.C(1L, new Continuation<String>() {

            @NonNull

            @Override

            public CoroutineContext getContext() {

                return null;

            }



            @Override

            public void resumeWith(@NonNull Object o) {



            }

        });

    }

}

 

接着回到动态代理那部分，因为suspend生成的代码会多加一个回调参数Continuation，那么动态代理的时候这个参数就会传入到代理的handler中。

Continuation的创建和使用十分的繁琐，最好的处理方法应该是把它再丢进一个kotlin的suspend方法中，让编译器去处理这些东西，而这个也就是Retrofit实现协程的原理。

interface SuspendService {

    @GET("/user")

    suspend fun getUser(): Response<User>



    @GET("/name")

    suspend fun getName(userId: String): Response<String>

}



//动态代理生成字节码示例

class SuspendServiceProxy implements SuspendService {

    InvocationHandler handler;



    @Nullable

    @Override

    public Object getUser(@NonNull Continuation<? super Response<User>> $completion) {

        return handler.invoke(

                this,

                SuspendService.class.getMethod("getUser", Continuation.class),

                new Object[]{$completion}

        );

    }



    @Nullable

    @Override

    public Object getName(@NonNull String userId, @NonNull Continuation<? super Response<String>> $completion) {

        return handler.invoke(

                this,

                SuspendService.class.getMethod("getName", String.class, Continuation.class),

                new Object[]{userId, $completion}

        );

    }

}

 

接着再回到HttpServiceMethod，看看刚才被省略的代码。

在这里面会判断是不是suspend方法，判断的逻辑在RequestFactory中，判断的方法就是判断参数有没有Continuation对象，感兴趣可以去RequestFactory源码瞅瞅。

现在如果是suspend方法，会直接自定义一个类型adapterType，它的实际类型是Call，泛型是实际的返回类型(Response<T>里面的T)。之后将他作为返回类型去创建CallAdapter，而这里实际创建的就是DefaultCallAdapterFactory的ExecutorCallbackCall。最后创建SuspendForResponse对象返回。

abstract class HttpServiceMethod<ResponseT, ReturnT> extends ServiceMethod<ReturnT> {



    static <ResponseT, ReturnT> retrofit2.HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(

            Retrofit retrofit, Method method, RequestFactory requestFactory) {



        /**

         * 通过判断参数是不是Continuation，标志函数是不是suspend

         * 在requestFactory内部处理

         */

        boolean isKotlinSuspendFunction = requestFactory.isKotlinSuspendFunction;

				...

        Annotation[] annotations = method.getAnnotations();

        Type adapterType;

        if (isKotlinSuspendFunction) {

            Type[] parameterTypes = method.getGenericParameterTypes();

            Type responseType = Utils.getParameterLowerBound(0,

                    (ParameterizedType) parameterTypes[parameterTypes.length - 1]);

          

          if (getRawType(responseType) == Response.class && responseType instanceof ParameterizedType) {

            // Unwrap the actual body type from Response<T>.

            responseType = Utils.getParameterUpperBound(0, (ParameterizedType) responseType);

            continuationWantsResponse = true;

     		  }

          	/**

 						 * 自己新建一个返回类型，将实际的返回例行包装给Call

 						 */

            adapterType = new Utils.ParameterizedTypeImpl(null, Call.class, responseType);

        } else {

            adapterType = method.getGenericReturnType();

        }



        CallAdapter<ResponseT, ReturnT> callAdapter =

                createCallAdapter(retrofit, method, adapterType, annotations);

        Type responseType = callAdapter.responseType();



        Converter<ResponseBody, ResponseT> responseConverter =

                createResponseConverter(retrofit, method, responseType);



        okhttp3.Call.Factory callFactory = retrofit.callFactory;

        if (!isKotlinSuspendFunction) {

            return new CallAdapted<>(requestFactory, callFactory, responseConverter, callAdapter);

        } else {

            return (HttpServiceMethod<ResponseT, ReturnT>) new SuspendForResponse<>(requestFactory,

                    callFactory, responseConverter, (CallAdapter<ResponseT, Call<ResponseT>>) callAdapter);

        }

    }

}

 

在SuspendForResponse中，adapt()的返回类型对应到了suspend的返回类型Object。并且其中的逻辑就是解析出Call和Continuation对象，然后有调用KotlinExtensions.awaitResponse()，就如之前说的，它是一个suspend方法，在代理中不处理Continuation，而是交给编译器去处理。

static final class SuspendForResponse<ResponseT> extends HttpServiceMethod<ResponseT, Object> {

    private final CallAdapter<ResponseT, Call<ResponseT>> callAdapter;



    SuspendForResponse(RequestFactory requestFactory, okhttp3.Call.Factory callFactory,

                       Converter<ResponseBody, ResponseT> responseConverter,

                       CallAdapter<ResponseT, Call<ResponseT>> callAdapter) {

        super(requestFactory, callFactory, responseConverter);

        this.callAdapter = callAdapter;

    }



    @Override

    protected Object adapt(Call<ResponseT> call, Object[] args) {

        call = callAdapter.adapt(call);



        Continuation<Response<ResponseT>> continuation =

                (Continuation<Response<ResponseT>>) args[args.length - 1];

        ...

        return KotlinExtensions.awaitResponse(call, continuation);

    }

}

 

KotlinExtensions.awaitResponse()是Call的扩展函数，扩展函数的实现是通过静态方法传入this的方法实现的，所以前面传入awaitResponse()的参数有两个，分别是Call对象和Continuation对象。

KotlinExtensions.awaitResponse()的主体是suspendCancellableCoroutine方法，suspendCancellableCoroutine运行在协程当中并且帮我们获取到当前协程的 CancellableContinuation 实例，CancellableContinuation是一个可取消的Continuation。通过调用它的 invokeOnCancellation 方法可以设置一个取消事件的回调，一旦这个回调被调用，那么意味着调用所在的协程被取消了，这时候我们也要相应的做出取消的响应，也就是把OkHttp发出去的请求给取消掉。这段建议多读几遍。

之后调用Call.enqueue()发送网络请求，在Callback中调用CancellableContinuation的 resume 或者 resumeWithException 来返回结果或者抛出异常。

这里的Callback也是经过了callAdapter和OkHttpCall处理，乏了。

suspend fun <T> Call<T>.awaitResponse(): Response<T> {

  return suspendCancellableCoroutine { continuation ->

    continuation.invokeOnCancellation {

      cancel()

    }

    enqueue(object : Callback<T> {

      override fun onResponse(call: Call<T>, response: Response<T>) {

        continuation.resume(response)

      }



      override fun onFailure(call: Call<T>, t: Throwable) {

        continuation.resumeWithException(t)

      }

    })

  }

}



//扩展函数示例

fun <T> Call<T>.awaitResponse(){

    toString()

}



//扩展函数示例转换为Java代码

public static final void awaitResponse(@NotNull Call $this$awaitResponse) {

    $this$awaitResponse.toString();

}