说明本文是redux使用的全面总结，所以会包含部分之前文章提到一些内容

阅读本文你需要

1. 基础的应用开发经验

2. 了解reductor或者其他redux框架，简单跑过示例代码，有基础的认知

什么是redux

redux是一种编程思路和对应的为了方便实现这种思路的框架

redux的核心思想 数据驱动

以应用的数据为应用的核心，通过事件（交互）产生数据变化，通过数据驱动view的展示。

通过数据和事件将view和业务流程解耦，将不同的业务流程相互解耦。

通过数据的单向流动（Store -> View -> Action ->Store）清晰的展示应用的状态和变化过程

store action view简介

store是应用数据的集合，以树的形式展现，根节点代表整个应用状态，每个子节点代表应用的某一局部状态，可以对任何节点进行数据监听

action是应用中引起数据变化的事件，需要通过reducer处理，反应数据的改变

view是应用的界面，它监听数据的变化，随数据产生变化

reducer是store中每个数据节点响应action的处理方法

数据流说明

store action view的基本关系就是

1. store -> view : view基于store的数据展示相应的界面，view监听store的数据变化，数据变化触发界面变化
2. view -> action : 用户在view上的交互产生影响数据的action（当然其他因素，比如网络变化也会产生action）
3. action -> reducer -> store : action传递给store之后，首先是交给reducer处理数据变化，然后将变化后的数据保存到store（之后就是store->view store又引起了view变化）

所以它是一个单向的数据流动循环 store -> view -> action -> store

redux开发步骤

1. 设计store，用最少的数据集完整的表达应用
2. 设计action，理清楚应用都有哪些产生数据变化的事件
3. 设计reducer，实现在不同action下，数据如何变化
4. 实现view，根据数据展示view，根据view的操作和业务流程发送action

redux设计

首先我们需要想明白为什么要用redux，它和MVP比有什么优势。

第一个区别

redux是数据驱动，有的同学可能会说这和MVP没有区别，MVP也是在P层获取了数据之后，交给V层的，V层也是根据数据展示界面的。

其实是有区别的，在于数据的完整性和数据处理的统一性。

完整性的意思是说redux是一次将你需要的数据完整的给View，统一性是说View可以基于完整的数据统一处理，都在一个方法里。

为什么说MVP不是这样呢，MVP是基于接口解耦的，我们在写的时候经常会在View层写很多接口方法，一个方法用于接收正常数据，一个方法用于接收异常数据，如果界面逻辑复杂点，还可能会出现更多的方法，但是每个方法接收的都是局部的数据，要么只有正常数据，要么只有异常数据，而且这些数据的处理都是在不同的方法里，导致的问题就是View的状态容易不对，比如处理某种异常数据的时候，你不仅需要处理展示这个数据的view，你还需要考虑其他view的状态如何变，如果漏掉了就会出bug。

而redux就不会有这个问题，因为每次拿到的数据都是全面的，所有的状态你都知道，而且都是在这统一处理的，view之间的状态关系应该是什么样的一目了然。

第二个区别

redux是业务解耦

MVP的设计是分层设计，层与层之间是解耦的，但是同一层内耦合性很高，当你的P层承担的不止一个业务逻辑时，就会很容易发生问题，当两个逻辑同时触发时，耦合的状态就容易出错，你会在大脑中模拟各种情况，思考状态位应该在哪些地方修改，然后在代码上打补丁，运行跑一跑感觉没问题，但是这就很容易出问题，第一，你的脑细胞会死很多，第二，有些异常情况，你可能漏掉了，第三，这段代码估计除了你，别人都不敢再碰了。

那为什么redux不会有这个问题，有两个原因第一个数据是不变量，所以不管多少业务，业务逻辑多复杂（包括多线程处理），当前业务逻辑的数据不会变，不受其他业务的影响，第二个每个业务的处理是单独的，分开的。

第三个区别

redux是单向数据流

当数据的修改源有很多的时候，说明业务逻辑已经很复杂了，使用MVP或者其他框架，你会发现哪里都可以修改数据，想要定位问题，必须每个地方都打日志或者断点，才能确定到底是谁修改的数据，想进一步了解到底发生了什么，代码逻辑的关系是什么样，你必须打更多的日志或者断点，即使这样最后你可能还是被搞蒙了，弄不明白为什么一会儿走到这，一会儿走到那。这时候单向数据流的优势就体现出来，因为数据是单向流动的，修改数据的一定是某个action，我们只需在分发action的地方输出是哪个action，它处理之后，数据是什么样的，你就可以清晰的看到，应用都发生了哪些action，每次action都产生了什么样的数据变化，从而快速定位问题

其实他们之间真正的区别是编程思想

MVP是一种分层思想，它将应用看做是界面、业务逻辑、数据三个层次，通过接口对每一层进行解耦，实现每一层的高内聚，层与层的低耦合

redux是数据驱动的思想，它将应用看成一个数据集合，这个集合就代表这个应用，View只是数据的另外一种形态，便于用户交互的一种数据展示方式，而action代表的是数据如何变化，即这个应用如何变化。

如果一个应用或者界面非常简单，我们都写在一个类里，当然没有关系，

但是当它的业务稍微复杂之后，这个类就会很庞大，使用MVP分层就很有必要了，让每个类只负责一个功能，清晰，代码也便于维护

但是当业务更多，逻辑更复杂之后，理论上我们应该进入拆分MVP中的每一层，但是现实是不同的P可能是状态耦合的，V只有一个，只能添加更多的接口方法，代码会越来越难维护，此时就应该使用redux或者其他数据驱动框架了

为什么redux更好

为什么redux能比MVP处理更复杂的情况，我觉得原因是因为MVP的解耦是基于接口的解耦，是类与类的解耦，它只是将View和P的实现类相互之间解耦了，但是View和P的业务关系并没有解耦，全都定义在接口上，导致View和P的实现类在业务逻辑上没有解耦，所以导致业务逻辑复杂之后，维护就困难了。

而redux呢，或者说数据驱动的框架呢，是基于数据解耦，是真正的业务解耦，因为数据是静态的，它是独立于业务流程存在的，业务再多，也仅仅是数据的扩展而已，数据与数据之间没有耦合关系，业务只会修改数据，和其他业务也没有关系，所以业务之间是解耦的，而View和业务没有关系，因为它只基于静态的数据展示。所以数据驱动，让View和业务，业务与业务都解耦了。

store设计

store的设计之前的文章说的很全面，可以直接参考store设计

action设计

action代表的是数据的变化，包括变化的原因，以及会怎么变。

同一个原因肯定是相同的变化，不同的原因可能导致相同的变化。

为了重复的代码仅写一遍，我们可能让不同原因触发相同的action，因为它们的变化相同，此时我们就是根据变化的类型设计action。

结果就是程序运行没有问题，但是当我们定位问题时，我们会发现，触发的action都相同，你肯定想骂人，因为你当然知道发生了什么变化（问题），你真正想知道的是谁触发的action，为什么触发action，此时你就会发现，我们应该按照变化的原因设计action。

其实这里我想说，我们是不应该写重复代码，但是我们也不要为了不写重复代码，就做出愚蠢的设计，重复代码我们可以通过其他手段解决，但是愚蠢的设计，会让你难以维护。

action的设计想清楚这一点，就不会有大问题了。

redux带给我们的启示

1. 简单，越简单越好，不论是类还是方法，使用redux，会发现没有复杂的类和方法
2. 解耦也有不同的层次，基于数据解耦，其实数据就是接口
3. 不要为了复用而复用，首先做好设计