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下一个的定义：
对的，他就是一个集合，和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
这个方法。我们通过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。还提供了上百个常用的操作符。
##总结
通过这篇文章，我的目的是让你理解究竟什么是Observable，为什么Observable是这么设计的，好处是什么，解决了什么问题。 而答案也很明显。 Observable是一组异步数据的集合，因为异步操作和同步操作有着本质上的区别（推送数据和拉取数据）所以我们根据iterable反过来设计observable。 好处是保持了数学上的
集合定义，摆脱了Callback，通过操作符(高阶函数)可以对集合实现一些变换操作。解决了通常情况异步操作不直观，复杂，回调地狱等等问题。
####参考文献(部分链接可能需要梯子)
数据）所以我们根据iterable反过来设计observable。 好处是保持了数学上的
集合定义，摆脱了Callback，通过操作符(高阶函数)可以对集合实现一些变换操作。解决了通常情况异步操作不直观，复杂，回调地狱等等问题。
####参考文献(部分链接可能需要梯子)
