2.1 响应式编程所涉及的设计模式

<aside> ✍️ API的设计上

迭代器（Iterator）

</aside>

2.2 解读reactivex.Observable

<aside> 〰️ 一连串流动的数据

</aside>

<aside> 〰️ 推送的特性（即push）

</aside>

<aside> ✍️ 换了个视角，对于发布者本身来说，就是在不断地推送元素，在rxjava中对应的是emit元素 对于订阅者来说，看到的是发布者在不断生产元素

推送的特性（即push）

</aside>

<aside> 〰️ Observable不会具有拉取元素的能力，即在订阅者订阅了Observable后，Observable接收到订阅者的通知并立即发出一个元素或者一个null值（没有元素的情况）

</aside>

<aside> 〰️ 无法确定数量的未来事件

</aside>

<aside> 〰️ 在未来某个时间点产生，并推送给客户端，想要得到这个响应值就必须先订阅它

</aside>

<aside> ✍️ org.reactivestream

从响应式的规范（http://reactivex.io/intro.html）可以明确地知道

</aside>

<aside> ✍️ 与之对应的还有LambdaSubscriber，不过其是支持backpressure的观察者.

观察LambdaObserver的源码部分

</aside>

<aside> ✍️ Rxjava初身是基于java7实现，所以底层在实现时定义了LambdaObserver这么一个类

观察LambdaObserver的源码部分

</aside>

<aside> 〰️ 因为create方法中放入的是一连串下发事件，总会有开始与结束，这是一个过程，而且没有返回值，所以函数式接口Consumer最适应这个情况

</aside>

<aside> ✍️ 前后对比设计上的变化很明显

因为create方法中放入的是一连串下发事件，总会有开始与结束，这是一个过程，而且没有返回值，所以函数式接口Consumer最适应这个情况

</aside>

<aside> 〰️ 一个函数式接口和装饰增强模式的典型应用

</aside>

<aside> 〰️ 不发送任何元素但可以正常结束的Observable

</aside>

<aside> 〰️ 提高所发送资源的重用性

</aside>