什么是响应式编程（Reactive Programming）
In computing, reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change. This means that it becomes possible to express static (e.g. arrays) or dynamic (e.g. event emitters) data streams with ease via the employed programming language(s), and that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the change involved with data flow.
-- Wikipedia
以上解释来自维基百科，在计算机领域，响应式编程是一个专注于数据流和变化传递的异步编程范式。这意味着可以使用编程语言很容易地表示静态（例如数组）或动态（例如事件发射器）数据流，并且在关联的执行模型中，存在着可推断的依赖关系，这个关系的存在有利于自动传播与数据流有关的更改。
抛开大段大段的概念，我们先搞清楚一件事情：什么是编程范式？
通俗的说：编程是为了解决问题，而解决问题可以有多种视角和思路，其中具有普适性的模式被归结为范式。我们常说的：“面向对象”，“面向过程”都是编程范式。
响应式编程是一种从数据流和变化出发的解决问题的模式。所以要研究响应式编程，一定要牢记已经掌握的OO（面向对象，笔者妄断大家OO的思想都是很根深蒂固了）来做对比，也一定要抛开OO避免钻牛角尖。
为什么是异步？
响应式编程，本质上是对数据流或某种变化所作出的反应，但是这个变化什么时候发生是未知的，所以他是一种基于异步、回调的方式在处理问题。
怪圈：似乎绝大多数博客说着说着就开始讲解RxAndroid
正如副标题，在网上搜索到的绝大多数的博客都会说着说着就在教你如何使用RxAndroid。各位，请记住以下几点：
-
RxAndroid(或RxJava)是很优秀的响应式编程框架。
-
你并非一定需要使用RxAndroid。
-
RxAndroid并不像那些博客里面说的那样会让你的代码变得更可读。
这里我直接进入第三点。取用扔物线推荐RxJava中的例子：如下这段代码：
Observable.from(folders)
.flatMap((Func1) (folder) -> { Observable.from(file.listFiles()) })
.filter((Func1) (file) -> { file.getName().endsWith(".png") })
.map((Func1) (file) -> { getBitmapFromFile(file) })
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe((Action1) (bitmap) -> { imageCollectorView.addImage(bitmap) });
就这段代码，是否需要从上到下仔细阅读一遍之后才能才会知道他的意图？
甚至，为了精读代码，他可能是这样：
Observable.from(folders)
.flatMap(new Func1<File, Observable<File>>() {
@Override
public Observable<File> call(File file) {
return Observable.from(file.listFiles());
}
})
.filter(new Func1<File, Boolean>() {
@Override
public Boolean call(File file) {
return file.getName().endsWith(".png");
}
})
.map(new Func1<File, Bitmap>() {
@Override
public Bitmap call(File file) {
return getBitmapFromFile(file);
}
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Action1<Bitmap>() {
@Override
public void call(Bitmap bitmap) {
imageCollectorView.addImage(bitmap);
}
});
ok,请允许我再问一个问题，如此简介的代码，您打算单独用一个类来放吗？
如果对于任何一个处理类似业务逻辑的rx代码段都使用类来放，可能类数量会爆炸，而且这些类的命名看起来会很奇葩。若不这样，您的业务实现类中将充斥诸如此类不精读不敢确定语义、容易被误修改、不容易测试的代码。面对这样的代码的时候只会是如履薄冰战战兢兢。
我是在反对使用RxAndroid吗？
No，我只是反对滥用Rx，我赞成对某些高度抽象的异步行为使用Rx构建具有语义性的框架代码，例如：编写MVVM分层框架。反对对任何业务细节都去做“一切皆流”的无脑工作。毕竟：业务是需要逐渐迭代发展的，对于有测试代码支撑的、同时有较强语义性的类，我们泛读代码就可以“闻弦歌而知雅意”，对于需要重构何处代码，修改何处逻辑心中有数，而不必将“流”再反转回“实际的相互关系”，再打乱，修改，再组织成流，再恶心下一次迭代，而且，最关键的是“你可能要从很多的流中找出这一个流”。
"我为什么要采用响应式编程？"
响应式编程可以加深你代码抽象的程度，让你可以更专注于定义与事件相互依赖的业务逻辑，而不是把大量精力放在实现细节上，同时，使用响应式编程还能让你的代码变得更加简洁。
特别对于现在流行的webapps和mobile apps，它们的 UI 事件与数据频繁地产生交互，在开发这些应用时使用响应式编程的优点将更加明显。十年前，web页面的交互是通过提交一个很长的表单数据到后端，然后再做一些简单的前端渲染操作。而现在的Apps则演变的更具有实时性：仅仅修改一个单独的表单域就能自动的触发保存到后端的代码，就像某个用户对一些内容点了赞，就能够实时反映到其他已连接的用户一样，等等。
当今的Apps都含有丰富的实时事件来保证一个高效的用户体验，我们就需要采用一个合适的工具来处理，那么响应式编程就正好是我们想要的答案。
响应式编程相关概念
举个简单的例子，某电商网站正在搞促销活动，任何单品都可以参加“满199减40”的活动，而且“满500包邮”。吃货小明有选择障碍（当然主要原因还是一个字：穷），他有个习惯，就是先在Excel上根据预算算好自己要买的东西：
1. 变化传递（propagation of change）
为什么说电子表格软件是“响应式典范”呢，因为“单价”和“数量”的任何变动，都会被引用（“监听”）它的单元格实时更新计算结果，如果还有图表或数据透视图引用了这块数据，那么也会相应变化，做到了实时响应。变化的时候甚至还有动画效果，用户体验一级棒！
这是响应式的核心特点之一：变化传递（propagation of change）。一个单元格变化之后，会像多米诺骨牌一样，导致直接和间接引用它的其他单元格均发生相应变化。
看到这里，你可能会说，“切~ 不就是算付款金额吗，购物网站上都有这个最基础不过的功能啊~”，这就“响应式”啦？但凡一个与用户交互的系统都得“响应”用户交互啊~
但是在响应式编程中，基于“变化传递”的特点，触发响应的主体发生了变化。假设购物车管理和订单付款是两个不同的模块，或者至少是两个不同的类——Cart和Invoice。
2. 数据流（data stream）
这些数据/事件在响应式编程里会以数据流的形式发出。
我们再观察一下购物车，这里有若干商品，小明每次往购物车里添加或移除一种商品，或调整商品的购买数量，这种事件都会像过电一样流过这由公式串起来的多米诺骨牌一次。这一次一次的操作事件连起来就是一串数据流（data stream），如果我们能够及时对数据流的每一个事件做出响应，会有效提高系统的响应水平。这是响应式的另一个核心特点：基于数据流（data stream）。
如下图是小明选购商品的过程，为了既不超预算，又能省邮费，有时加有时减：
3. 声明式（declarative）
我们再到listenOn方法去看一下：
Invoice模块中，上边的一串公式被组装成如下的伪代码：
public void listenOn(DataStream<CartEvent> cartEventStream) { // 1
double sum = 0；
double total = cartEventStream
// 分别计算商品金额
.map(cartEvent -> cartEvent.getProduct().getPrice() * cartEvent.getQuantity()) // 2
// 计算满减后的商品金额
.map(v -> (v > 199) ? (v - 40) : v)
// 将金额的变化累加到sum
.map(v -> {sum += v; return sum;})
// 根据sum判断是否免邮，得到最终总付款金额
.map(sum -> (sum > 500) ? sum : (sum + 50));
...
cartEventStream是数据流，DataStream是某种数据流类型，可以暂时想象成类似在Java 8版本增加的对数据流进行处理的Stream API（下节会说到为啥不用Java Stream）。
map方法用于对数据流中的元素进行映射，比如第一个将cartEvent中的商品价格和数量拿到，然后算出本次操作的金额；第二个判断是否能享受“满199减40”的活动。
这里的伪代码用到了lambda，它非常适用于数据流的处理。没有接触过lambda的话没有关系，我们后续会再聊到它。
这是一种“声明式（declarative）”的编程范式。通过四个串起来的map调用，我们先声明好了对于数据流“将会”进行什么样的处理，当有数据流过来时，就会按照声明好的处理流程逐个进行处理。
比如对于第一个map操作：
声明式编程范式的威力在于以不变应万变。无论到来的元素是什么，计算逻辑是不变的，从而形成了一种对计算逻辑的“绑定”。
再举个简单的例子方便理解：
a = 1;
b = a + 1;
a = 2;
这个时候，b是多少呢？在Java以及多数语言中，b的结果是2，第二次对a的赋值并不会影响b的值。
假设Java引入了一种新的赋值方式:=，表示一种对a的绑定关系，如
a = 1;
b := a + 1;
a = 2;
由于b保存的不是某次计算的值，而是针对a的一种绑定关系，所以b能够随时根据a的值的变化而变化，这时候b==3，我们就可以说:=是一种声明式赋值方式。而普通的=是一种命令式赋值方式。事实上，我们绝大多数的开发都是命令式的，如果需要用命令式编程表达类似上边的这种绑定关系，在每次a发生变化并需要拿到b的时候都得执行b = a + 1来更新b的值。
如此想来，“绑定美元政策”不也是一种声明式的范式吗~
总结来说，命令式是面向过程的，声明式是面向结构的。
不过命令式和声明式本身并无高低之分，只是声明式比较适合基于流的处理方式。这是响应式的第三个核心特点：声明式（declarative）。结合“变化传递”的特点，声明式能够让基于数据流的开发更加友好。
总结
总结起来，响应式编程（reactive programming）是一种基于数据流（data stream）和变化传递（propagation of change）的声明式（declarative）的编程范式。
响应式编程的“变化传递”就相当于果汁流水线的管道；在入口放进橙子，出来的就是橙汁；放西瓜，出来的就是西瓜汁，橙子和西瓜、以及机器中的果肉果汁以及残渣等，都是流动的“数据流”；管道的图纸是用“声明式”的语言表示的。
这种编程范式如何让Web应用更加“reactive”呢？
我们设想这样一种场景，我们从底层数据库驱动，经过持久层、服务层、MVC层中的model，到用户的前端界面的元素，全部都采用声明式的编程范式，从而搭建一条能够传递变化的管道，这样我们只要更新一下数据库中的数据，用户的界面上就相应的发生变化，岂不美哉？尤其重要的是，一处发生变化，我们不需要各种命令式的调用来传递这种变化，而是由搭建好的“流水线”自动传递。
这种场景用在哪呢？比如一个日志监控系统，我们的前端页面将不再需要通过“命令式”的轮询的方式不断向服务器请求数据然后进行更新，而是在建立好通道之后，数据流从系统源源不断流向页面，从而展现实时的指标变化曲线；再比如一个社交平台，朋友的动态、点赞和留言不是手动刷出来的，而是当后台数据变化的时候自动体现到界面上的。
资料整理来自：
https://www.jianshu.com/p/1765f658200a
https://www.cnblogs.com/android-blogs/p/5586395.html
https://blog.csdn.net/get_set/article/details/79455258