【深入理解Kotlin协程】Google的工程师们是这样理解Flow的？

Question：why there is a Flow in kotlin?

问这个问题就好比在问为什么那里会有一座山存在，嗯，这貌似是一个哲学问题。当然，对于kotlin中的Flow的理解可能不会上升到这么高的哲学层次，对于Flow相关的Api掌握并使用它并不是什么难事，但是我们需要思考的是为什么会有Flow这样的存在？

其实flow的背后是协程，那么kotlin中的协程框架已经能够做到异步任务问题的解决方案了，为什么还要设计Flow呢？设计这个玩意的最初的目的和构想是为了什么样的意图？

为了搞明白这个问题的真相，我特意通过科学上网的方式，了解了一下Google的Android工程师们对Flow的理解。下面主要是记录一下理解产生Flow这个想法的过程。

注意看，下面这个男人叫小帅，他每天的一项任务就是提着水桶到湖边去取水。

小帅一年365天都在重复着这样的内容，可是不出意外的话，意外终于发生了，有一天小帅来到湖边后发现湖泊居然干了，于是他不得不尝试跑去寻找其他新的水源。

但是聪明的小帅很快就发现了问题，他在想：与其这样到不同的湖边跑来跑去，为什么不能在湖边架设一根管道，然后让水流沿着管道自动流过来呢？就像下面这样：

这样即使有多个湖泊也可以通过管道将它们连接起来：

这样以后小帅就不必每次亲自跑到湖边去检查湖泊有没有干，只要湖泊没有干，那么小帅在管道的另一头只需要拧开水龙头，就会自动有水流出。

现在回想一下在一个应用当中，其实我们请求应用界面所需的数据跟这个场景很相似，不是吗，想象一下，我们平时是不是在到处请求数据，然后拿到数据以后再返回到使用它的地方去更新View界面？就像下面这样：

我们就跟小帅一样，不停的在应用的各个地方去请求数据，拿到数据后再返回到UI界面去更新，而且这样的地方非常的多，因此我们总是为此而疲于奔命，有时甚至感到分身乏术。