响应式编程是一种面向数据流和变化传播的编程范式：抽象（事件、数据）、流、声明式
响应式编程的三个层次：
1、将事件和数据抽象为流；
2、使用声明式（函数式）编程简化流的处理流程；
3、将各类输入（流）封装（抽象）为流的端口。
4、是交互式编程开发的利器；
1、基于事件和异步；
响应编程能够简化编程，它依赖于事件，代码运行的顺序不是代码行的顺序，而是和一个以上的事件有关，这些事件发生是以随着时间的推移的序列。我们把这一系列事件称为“流”。
响应式编程就是因为我们得“响应”这些事件而得以命名。
https://www.jdon.com/48275
declaratively
"什么是响应式编程"
响应式编程是一种面向数据流和变化传播的编程范式。
在某种程度上，这并不是什么新东西。用户输入、单击事件、变量值等都可以看做一个流，你可以观察这个流，并基于这个流做一些操作。响应式就是基于这种想法。
https://www.cnblogs.com/feng9exe/p/9019773.html
事件来源包括UI事件、网络回调、生命周期回调，通知等等。更新UI往往需要依赖多个事件以及事件包含的数据。所以我们不得不引入共享状态，如下图所示
ReactiveCocoa是IOS广为使用的技术框架，而ReactiveCocoa的核心思想就FRP。FRP不同于JAVA的object-oriented和AOP，FRP能让你的代码像数学一样简洁，业务像流水一样清晰流畅。
2、Callback的缺点显而易见：
The code to manage our state and to update our output is ALL over the place.
状态的修改可能分布在很多地方，UI的更新也可能分布在很多地方。
状态之间的组合以及相互影响。并且容易出现Bug，很有可能出现未考虑到的状态组合。
变量式线程同步管理非常复杂。
---------------------
作者：海洋顶端
来源：CSDN
原文：https://blog.csdn.net/fly1183989782/article/details/62053973
版权声明：本文为博主原创文章，转载请附上博文链接！
响应式编程就是与异步数据流交互的编程范式
一方面，这已经不是什么新事物了。事件总线(Event Buses)或一些典型的点击事件本质上就是一个异步事件流(asynchronous event stream)，这样你就可以观察它的变化并使其做出一些反应(do some side effects)。响应式是这样的一个思路：除了点击和悬停(hover)的事件，你还可以给其他任何事物创建数据流。数据流无处不在，任何东西都可以成为一个数据流，例如变量、用户输入、属性、缓存、数据结构等等。举个栗子，你可以把你的微博订阅功能想象成跟点击事件一样的数据流，你可以监听这样的数据流，并做出相应的反应。
最重要的是，你会拥有一些令人惊艳的函数去结合、创建和过滤任何一组数据流。 这就是"函数式编程"的魔力所在。一个数据流可以作为另一个数据流的输入，甚至多个数据流也可以作为另一个数据流的输入。你可以合并两个数据流，也可以过滤一个数据流得到另一个只包含你感兴趣的事件的数据流，还可以映射一个数据流的值到一个新的数据流里。
数据流是整个响应式编程体系中的核心，要想学习响应式编程，当然要先走进数据流一探究竟了。那现在就让我们先从熟悉的"点击一个按钮"的事件流开始
一个数据流是一个按时间排序的即将发生的事件(Ongoing events ordered in time)的序列。如上图，它可以发出3种不同的事件(上一句已经把它们叫做事件)：一个某种类型的值事件，一个错误事件和一个完成事件。当一个完成事件发生时，在某些情况下，我们可能会做这样的操作：关闭包含那个按钮的窗口或者视图组件。
我们只能异步捕捉被发出的事件，使得我们可以在发出一个值事件时执行一个函数，发出错误事件时执行一个函数，发出完成事件时执行另一个函数。有时候你可以忽略后两个事件，只需聚焦于如何定义和设计在发出值事件时要执行的函数，监听这个事件流的过程叫做订阅，我们定义的函数叫做观察者，而事件流就可以叫做被观察的主题(或者叫被观察者)。你应该察觉到了，对的，它就是观察者模式。
"我为什么要采用响应式编程？"
响应式编程可以加深你代码抽象的程度，让你可以更专注于定义与事件相互依赖的业务逻辑，而不是把大量精力放在实现细节上，同时，使用响应式编程还能让你的代码变得更加简洁。
当今的Apps都含有丰富的实时事件来保证一个高效的用户体验，我们就需要采用一个合适的工具来处理，那么响应式编程就正好是我们想要的答案。
https://blog.csdn.net/zcmain/article/details/52240303
ReactiveX is a combination of the best ideas from
the Observer pattern, the Iterator pattern, and functional programming
Functional
Avoid intricate stateful programs, using clean input/output functions over observable streams.
Less is more
ReactiveX's operators often reduce what was once an elaborate challenge into a few lines of code.
Async error handling
Traditional try/catch is powerless for errors in asynchronous computations, but ReactiveX is equipped with proper mechanisms for handling errors.
Concurrency made easy
Observables and Schedulers in ReactiveX allow the programmer to abstract away low-level threading, synchronization, and concurrency issues.
ReactiveX
ReactiveX is a library for composing asynchronous and event-based programs by using observable sequences.
It extends the observer pattern to support sequences of data and/or events and adds operators that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O.
|
Observables fill the gap by being the ideal way to access asynchronous sequences of multiple items |
||
|
|
synchronous |
Iterable<T> getData() |
|
Future<T> getData() |
Observable<T> getData() |
|
Why Use Observables?
The ReactiveX Observable model allows you to treat streams of asynchronous events with the same sort of simple, composable operations that you use for collections of data items like arrays. It frees you from tangled webs of callbacks, and thereby makes your code more readable and less prone to bugs.
Callbacks Have Their Own Problems
Callbacks solve the problem of premature blocking on Future.get() by not allowing anything to block. They are naturally efficient because they execute when the response is ready.
But as with Futures, while callbacks are easy to use with a single level of asynchronous execution, with nested composition they become unwieldy.
http://reactivex.io
