[移动开发]一篇不太一样的RxJava介绍，Android MVP模式详解

所以在我们的角度，我们是被动的，也就是英语中的reactive ，也就是所谓的响应式

我们回到我们的例子：

同步的时候，我们是这样的

interface Model{
fun getList() : List

fun getBitmap(metaData : MetaData) : Bitmap
}

而异步的时候，我们的方法没有了返回值，多了个参数，所以不能使用漂亮的**“链式调用”。 这是因为List 本身，就是一种同步的类型。我们每次操作List，都是对List来拉取**数据。不信？我们来看下：

大家都知道List并不是最基础的集合，常用的集合还有HashMap,Set,Table，Vector等等等等。他们都有一个共同的父类： Iterable

interface Iterable {
fun iterator(): Iterator
}

这里的iterator就是迭代器，他是这个样子的

interface Iterator {

fun next(): T

fun hasNext(): Boolean
}

使用的时候也就是我们最麻烦的迭代方式：

val i = iterator()
while(i.hasNext()){
val value = i.next()
}

所以我们在Java中有了foreach，以及后面的stream api等等语法糖。 这里我们看到了，我们每次确实首先询问List,有没有值，如果有我们获取这个值，如果没有，跳出循环，对List的操作结束。读取完毕。

想象一下，如果我们有一种 AsyncList，对他的读取都是AsyncList来通知我们，然后再和同步的时候一样使用高阶函数比如map/foreach等等该多好。比如

interface Model{
fun getList() : AsyncList

fun getBitmap(metaData : MetaData) : Bitmap
}

我们就可以像同步一样，

model.getList()
.map { model.getBitmap(it) }
.forEach { showBitMap(it) }

现在我们来根据Iterable设计我们的 AsyncList，上面我们知道了Iterable是同步的，是拉取数据，我们需要的AsyncList是异步的，是他推送数据给我们。 我们和List一样，给所有的异步集合来一个父类，来设计一个AsyncIterable,我们知道Iterable提供Iterator通过我们主动询问Iterator的next,hasNext等方法我们主动拉取数据。 所以我们的AsyncIterable理论上来说，应该是我们通过注册AsyncIterator的方式，将我们的AsyncIterator传递给AsyncIterable，让他来通知我们，实现异步和推送数据。 所以我们的AsyncIterable的实现应该是这样的

interface AsyncIterable {
fun iterator(iterator : AsyncIterator)
}

(看起来好像有点眼熟？)

我们再来设计AsyncIterator，同步的方式两个方法，一个是hasNext，也就是我们主动询问iterable接下来之后还有没有值的过程，如果是异步的方式，这应该是我们的AsyncIterable,来通知我们，他接下来以后还有没有值。 所以变成了这样：

fun hasNext(has : Boolean)

对的，通过这种类似CallBack的方式，通知我们有没有值。true就是还有值，一旦接收到false，就代表迭代结束，我们的AsyncIterable已经遍历完成了。 另一个方法 next() 就是我们来主动询问，当前的值是什么。所以我们的AsyncIterable就是通过这个方法，来通知我们当前的值是什么，依然还是通过类似CallBack的方式：

fun onNext(current:T)

(是不是有些眼熟？（手动滑稽）)

这里有两个问题： 第一个问题：我们在这里隐藏了一个错误，因为hasNext()方法返回 false的时候不一定是没有接下来的值了，也有可能是处理当前值的时候出现了某些个错误或者异常，这样他就不能处理接下来的值，这时候我们的app就会崩溃。所以在异步的时候，我们希望我们的AsyncIterable在出错的时候，可以通知我们他出错了，我们也就不进行接下来的处理了。所以我们有了：

fun onError(e:Throwable)

(是不是也有些眼熟？（手动滑稽）)

第二个问题，在hasNext方法显然有些过于多余，因为在同步的时候，我们并不知道他究竟接下来有没有值，所以我们每次访问List的时候，要询问还有没有接下来的值，我们再进行下一步。而异步的时候，我们的AsyncIterable肯定知道他自己接下来有没有值了，我们只希望在最后他没有值的时候通知我们结束了即可，也就是说我们之前的 hasNext(true)都是多余的。我们其实只关心hasNext(true)被调用的时候。所以我们把他简化成只有最后结束的时候才调用的方法：

fun onComplete()

这样，我们有了我们的AsyncIterator

interface AsyncIterator {

fun onNext(current:T):

fun onComplete()

fun onError(e:Throwable)
}

对的，他就是我们RxJava中的 Observer,而我们的 Asynciterable 就对应着我们的Observable。

interface Observable {
fun subscribe(observer : Observer)
}

由此，我给Observable下一个的定义：

Observable 是一组异步数据的集合

对的，他就是一个集合，和List,Set,Vector一样。他是一组数据，Collection可以包含0,1很多甚至无限个数据。所以Observable也可以包含0,1，n,甚至无限个数据。

当我们在处理Collection出现异常时（比如NullPointerException），我们的程序会崩溃，不会有接下来的处理。所以我们的Observable在收到onError之后，也不会再有数据推送给我们。

Collection可以通过高阶函数（High Oroder Function）进行组合，变换等等，所以作为集合之一的Observable也可以进行组合，变换。

对`

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》

【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享

Iterable进行操作，我们是通过getIterator方法，来获得Iterator`来进行主动询问，拉取数据实现迭代。

对Observable进行操作，我们是通过subscribe方法，来注册Observer来进行被动获取数据，由Obseravble来推送数据，实现迭代。

我们费了这么大力气，终于抽象出来一个异步的集合。那么他的好处是什么呢？

1. 首先，这种推送数据的方式才是我们直观的，异步操作方法，我们在上文了解了，异步操作的时候，作为接收方。我们是被动的，我们没办法询问生产方到底有没有完成异步任务。只有生产方自己才知道他有没有完成生产，所以他在完成生产后通知我们，并把结果交给我们这是一种直观的解决方案。而Java或者其他高级语言没有提供这一方案。我们才自定义CallBack来实现回调。

2. 在使用CallBack方案的时候，你知道的信息太多了。举个例子，我们上文中的

fun?getList(callback:CallBack<List >)

这个方法。我们通过callback知道了，这应该是一个异步操作。可能是耗时的，所以我们可能需要一个线程来执行他，执行之后，他又会给我一个List，而这个list却又是同步的。你需要关心的事情太多了。 俗话说，把握现在 展望未来！ 我们能处理好现在的事情就已经很不错了，Observable则解决了这一问题。我们上面的方法改完之后应该是这样的

fun getList() : Observable<List >

最正确的可能应该是这样的：

fun getList() : Observable
对的，因为Observable本身就是个集合，无需再和 同步的List嵌套使用。但是由于服务器设计原因， Observable这种使用方式还是很常见的。 在Observable我们无需关心这个方法究竟是怎么生成的。我们像往常一样迭代数据，我们只需要知道，他生产出数据之后，会通知我即可。 至于你到底怎么生产数据给我？在什么线程？是同步的异步的？有没有阻塞？
I don’t really care！
3. 操作符，对的因为Observable是一个数学上的 集合。集合就可以进行一系列的变换，通过我们定义的高阶函数，比如map,filter等等。这些操作符不是RxJava的专利，他是我们对集合的一些常见操作。我们对List,Vector等等也 应该可以进行这些操作，而Java本身没有提供这些。在Java 8后通过stream API补充了这些方法，而RxJava的一大优势就是不仅仅提供了这个异步的集合类Observable。还提供了上百个常用的操作符。
##总结