组件的生命周期函数：

全局刷新带来的好处：
将所有的更新ui的业务逻辑代码全部移入框架内部，开发者只需要关系数据流的绑定即可，这样让业务逻辑，因为当我们面对不断变化的UI界面时，仅仅需要考虑UI的构成即可。（面向数据流与信号传递编程，响应式编程思想）

全局刷新的性能疑问：
由于全局刷新是需要配合event loop事件周期的，所以操作虚拟dom（内存）的效率比操作dom的效率要高不少，所以性能反而会提供。但对于iOS来说，iOS本来就是以60fps的周期来同步界面的操作然后进行渲染的，所以这点上也不影响iOS的性能。

React中最神奇的部分莫过于虚拟DOM，以及其高效的Diff算法。这让我们可以无需担心性能问题而”毫无顾忌”的随时“刷新”整个页面，由虚拟DOM来确保只对界面上真正变化的部分进行实际的DOM操作。React在这一部分已经做到足够透明，在实际开发中我们基本无需关心虚拟DOM是如何运作的，所以下面介绍一下diff dom算法。

diff dom算法规则：
diff dom结合了web界面提供了两个简单的假设：（1）两个相同组件产生类似的dom结构，不同的组件产生不同的dom结构（2）对于同一层次的一组子节点，它们可以通过唯一的id进行区分。
所以整个算法规则如下
＊逐层进行节点比较：直接以层级横向行进比较，若一旦有不同，则无需比节点的子节点了。
＊不同节点类型的比较：节点类型变了，就直接判断了修改了，直接更新，后面的节点类型无需比较。
＊相同节点类型，不同属性的比较：属性不同，则进行属性重设。
＊列表节点的比较：没提供key按照默认规则，提供了key可以更新属性的方式完成更新。

note：
说明1:对于移动节点的情况，在rn中其实并没有进行移动行为，而是直接将移动的目标删除，重新创建，然后添加到目标位置，更新属性来完成操作，如下图：

note:
说明1:数据模型驱动UI：即是数据模型的变化（网络请求or用户交互导致的更新）需要用户实现响应的业务逻辑实现UI的更新，若遇到一个数据模型的更新会影响多个部分的UI界面的情况下就得全局刷新，过多的全局刷新容易导致性能的下降。过于复杂的UI更新操作

Flux的简单架构图：

Flux的详细架构图：

其中主要模块的分工如下：
＊Action Creators(Action):Action的创建者，通过调用Dispatcher派遣具体的action消息。
＊Dispatcher:分发action、注册action的注册函数，通常就是调用Store完成数据、信息的更新。
＊Store:接受事件、更新公共信息，调用view的注册方法完成view update
＊ReactViews(View):构建界面状态机，交互，调用action creators产生action。
自此，四个主要组件构成一个单向循环的事件流环，让代码更清晰。