距离上篇文章已有半年的时间，虽然这期间没什么输出，但是还是关注着RxJava和国内一些动向/文章等等，感觉很多人对RxJava还有些许误会和“错误”的理解。所以今天我们从最基础的开始，来了解一下RxJava。
我们先退回一步，忘了RxJava，讨论一个我们Android开发，甚至很多开发都会遇到的非常棘手的问题，异步问题。
举个例子，我们需要向 MVP/MVVM中的 Model层 取到一组数据，来做我们的首页展示，比如这样的：
一个简单的Dribbble页面，由于图片很多，我们不希望在第一次请求就获得所有的图片，我们更希望先获得一些图片的MetaData，比如url等等。然后在分别异步加载，来实现一个比较好的用户体验。这里我们先不考虑RecyclerView加Glide的组合，用简单的伪代码来显示。
我们的 Model 层需要两个方法，一个是获取到我们首页图片的MetaData，一个是根据MetaData获取Bitmap。
如果万物皆可同步，那么代码非常简单：
interface Model{
fun getList() : List<MetaData>
fun getBitmap(metaData : MetaData) : Bitmap
}
很多同学喜欢RxJava都是因为链式调用看起来非常舒服，而链式调用或者说高阶函数或者操作符并不是RxJava的专利，Java8的 Stream API和Kotlin都有相关的操作，比如我们的代码在kotlin中可以这样调用
model.getList()
.map { model.getBitmap(it) }
.forEach { showBitMap(it) }
是不是看起来和你们所谓的优雅，简洁的RxJava链式调用一样呢？
但是同步意味着阻塞，而网络加载Bitmap大家都知道是非常耗时的。为了不阻塞用户界面（UI线程），我们希望他在后台异步执行，执行后再输出到前台。 所以我们Android中最简单直接的方法就是加入CallBack，来实现异步通信。我们的代码就变成这样
//定义CallBack
interface CallBack<T> {
fun onSuccess(t:T)
fun onError(error:Error)
}
interface Model{
fun getList(callback:CallBack<List<MetaData>>)
fun getBitmap(metaData:MetaData, callback:Callback<MetaData>)
}
看过很多RxJava教程的同学肯定觉得这里我要讲Callback Hell（回调地狱）了，然后开始展示代码RxJava来解决回调地狱的问题，但如果这样我这篇文章也没什么意义了，岂不是和很多入门文章都一样了？
我们先来看看为什么我们会出现回调地狱？而在同步的时候却可以保持我们喜欢的**“链式调用”** 我们在同步的时候，我们做的事情可以简化成这样： 进入主界面 -> 通过getList方法获取 List -> 根据list逐一操作获取bitmap -> 显示bitmap 可以看到，我们确实是一条链，所以很简单的通过stream api来实现**“链式调用”**。
但是异步的时候呢？ 进入主界面 -> getList(callback:CallBack<List>)方法将我们的CallBack传给后台 -> 等待后台回调我们的CallBack
重点来了，与同步的不同，我们这里不是直接获得了我们的List。而是在等待着异步的另一方通知我们。 同步的时候，我们直接拉取数据 ：
而异步的时候，直观的看我们应该是在“等待”数据，异步对象向我们推送数据。
所以在我们的角度，我们是被动的，也就是英语中的reactive ，也就是所谓的响应式
我们回到我们的例子：
同步的时候，我们是这样的
interface Model{
fun getList() : List<MetaData>
fun getBitmap(metaData : MetaData) : Bitmap
}
而异步的时候，我们的方法没有了返回值，多了个参数，所以不能使用漂亮的**“链式调用”。 这是因为List 本身，就是一种同步的类型。我们每次操作List，都是对List来拉取**数据。不信？我们来看下：
大家都知道List并不是最基础的集合，常用的集合还有HashMap,Set,Table，Vector等等等等。他们都有一个共同的父类： Iterable
interface Iterable<out T> {
fun iterator(): Iterator<T>
}
这里的iterator就是迭代器，他是这个样子的
interface Iterator<out T> {
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<MetaData>
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<T> {
fun iterator(iterator : AsyncIterator<T>)
}
(看起来好像有点眼熟？)
我们再来设计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<T> {
fun onNext(current:T):
fun onComplete()
fun onError(e:Throwable)
}
对的，他就是我们RxJava中的 Observer,而我们的 Asynciterable 就对应着我们的Observable。
interface Observable<T> {
fun subscribe(observer : Observer<T>)
}
由此，我给Observable下一个的定义：
Observable 是一组异步数据的集合
对的，他就是一个集合，和List,Set,Vector一样。他是一组数据，Collection可以包含0,1很多甚至无限个数据。所以Observable也可以包含0,1，n,甚至无限个数据。
当我们在处理Collection出现异常时（比如NullPointerException），我们的程序会崩溃，不会有接下来的处理。所以我们的Observable在收到onError之后，也不会再有数据推送给我们。
Collection可以通过高阶函数（High Oroder Function）进行组合，变换等等，所以作为集合之一的Observable也可以进行组合，变换。
对Iterable进行操作，我们是通过getIterator方法，来获得Iterator来进行主动询问，拉取数据实现迭代。
对Observable进行操作，我们是通过subscribe方法，来注册Observer来进行被动获取数据，由Obseravble来推送数据，实现迭代。
我们费了这么大力气，终于抽象出来一个异步的集合。那么他的好处是什么呢？
-
首先，这种推送数据的方式才是我们直观的，异步操作方法，我们在上文了解了，异步操作的时候，作为接收方。我们是被动的，我们没办法询问生产方到底有没有完成异步任务。只有生产方自己才知道他有没有完成生产，所以他在完成生产后通知我们，并把结果交给我们这是一种直观的解决方案。而Java或者其他高级语言没有提供这一方案。我们才自定义CallBack来实现回调。
-
在使用CallBack方案的时候，你知道的信息太多了。举个例子，我们上文中的
fun getList(callback:CallBack<List<MetaData>>)
这个方法。我们通过callback知道了，这应该是一个异步操作。可能是耗时的，所以我们可能需要一个线程来执行他，执行之后，他又会给我一个List，而这个list却又是同步的。你需要关心的事情太多了。 俗话说，把握现在 展望未来！ 我们能处理好现在的事情就已经很不错了，Observable则解决了这一问题。我们上面的方法改完之后应该是这样的
fun getList() : Observable<List<MetaData>>
最正确的可能应该是这样的：
fun getList() : Observable<MetaData>
对的，因为Observable本身就是个集合，无需再和同步的List嵌套使用。但是由于服务器设计原因， Observable<List>这种使用方式还是很常见的。 在Observable我们无需关心这个方法究竟是怎么生成的。我们像往常一样迭代数据，我们只需要知道，他生产出数据之后，会通知我即可。 至于你到底怎么生产数据给我？在什么线程？是同步的异步的？有没有阻塞？
I don't really care！
- 操作符，对的因为Observable是一个数学上的集合。集合就可以进行一系列的变换，通过我们定义的高阶函数，比如map,filter等等。这些操作符不是RxJava的专利，他是我们对集合的一些常见操作。我们对List,Vector等等也应该可以进行这些操作，而Java本身没有提供这些。在Java 8后通过stream API补充了这些方法，而RxJava的一大优势就是不仅仅提供了这个异步的集合类Observable。还提供了上百个常用的操作符。
##总结
通过这篇文章，我的目的是让你理解究竟什么是Observable，为什么Observable是这么设计的，好处是什么，解决了什么问题。 而答案也很明显。 Observable是一组异步数据的集合，因为异步操作和同步操作有着本质上的区别（推送数据和拉取数据）所以我们根据iterable反过来设计observable。 好处是保持了数学上的集合定义，摆脱了Callback，通过操作符(高阶函数)可以对集合实现一些变换操作。解决了通常情况异步操作不直观，复杂，回调地狱等等问题。
####参考文献(部分链接可能需要梯子)
