React Native应用实现步骤
在整个应用设计中，始终按照自下而上的原则进行。在大型的项目中，自下而上的设计方式简单，可以并行工作，并且可以在构建的同时写测试用例。
React Native设计大体为五个步骤。
一、应用原型
设计各界面的草图。从主界面开始，处理各种跳转的关系。
二、基础组件结构设计
原型设计完成后，需要设计每个界面的React Native基础组件的分层结构。
2.1 列出所有需要使用的基础组件
首先要做的是从UI界面上找出所有需要使用的基础组件。基础组件需要遵循“责任唯一原则”，意思是一个基础组件只应当负责一个工作。如果一个组件负责多个工作，就应该将这个组件拆分为多个子组件。
2.2 对基础组件进行分层
对基础组件进行分层，目的是为了能使用功能强大的flexbox布局来实现界面。分层就是把显示在同一个行区域或者列区域中的多个组件放在同一个view中。
开发者需要在界面上画出一个个方框，每个方框对应一个flexbox样式的React Native组件。需要在方框中再画出小方框，对应组件的子组件，直到无法画出更小的方框。这时，就得到了界面对应的组件分层结构。
2.3 自下而上的设计
从UI界面的底部（最基础的React Native组件）开始构建，每分出的一层组件构成了一个上层React Native组件，直到向上分层到一个界面的根View组件。
三、使用React Native组件搭建静态界面
得到了组件结构后，就需要搭建React Native组件的静态界面。
这一步只编写各个界面对应组件的render函数，排列render函数中使用到的基础React Native组件，生成对应的样式。在编写中，开发者会不断地发现在某个界面中需要填入数据，这就是数据表。如果数据表比较多，则可以用一个文本文件记录下来。
四、React Native组件分层
静态界面搭建完成后，开发者需要对React Native组件进行分层。不同于基础组件的分层，React Native组件分层是区分控制React Native组件 与显示React Native组件的（当然也可能有两个功能都有的组件）。
4.1 分析界面之间的联系
如果业务逻辑需要从界面A跳转到界面B，或者需要把界面A呈现时得到（用户输入或者网络获取等）的数据展示在界面B上，我们就说界面A需要给界面B发送消息。如果界面A需要给界面B发送消息。但界面B不需要给界面A发送消息，那么在React Native应用设计中，界面B对应的React Native组件应当成为成为界面A对应的React Native组件的子组件。如果界面A、B都需要给对方发信息，那么它们对应的React Native组件就应当有一个共同的父控制组件。
显示组件与控制组件的分层也是按照自下而上的原则进行的。
4.2 确定数据的显示者与拥有者
在React Native框架中，数据是沿着组件树从上到下单向流动。拥有数据的React Native组件不一定负责显示该数据，它经常把自己拥有的数据（存储在它的状态机变量中）作为一个子组件的属性传递给子组件，由子组件来显示它。
确定数据的显示者与拥有者，同样遵循从下到上的原则。对生成的数据表中的每一个数据，找出负责在手机界面上渲染数据的组件，然后判断该数据是否可以被该组件的上层拥有。如果可以（意味着这个数据不会在本组件中被改变），把它丢给上层组件（意味着这个数据由上层组件通过props传递下来）；如果不可以，那么这个数据可能会是本组件的一个状态机变量。继续将这个数据向上丢的过程，直到数据被丢到了最上层或者无法向上丢了。当这一步完成后，对于每一个组件，开发者就得到了该组件需要使用的属性表，以及该组件可能拥有的状态机变量表。
4.3 确定状态机变量
React Native应用程序工作时，React Native组件接收各种事件，对所接收到的事件的处理可能导致处理结果中的某些数据需要显示在UI界面上。这些数据可以成为该React Native组件的状态机变量。我们把他们称作状态机变量备选名单。
开发者需要对这份名单上的数据做进一步分析，找出重复的数据。重复的数据是指：（1）该数据可以由备选名单上的其他数据通过某种规则计算得出；（2）该数据可以由组件中的数据通过某种规则计算得出；（3）该数据可以由备选名单上的其他数据再加上属性上的某些数据按某种规则计算得出。
把这些重复的数据踢出备选名单，就得到了一个状态机变量的最小集。
4.4 确定各事件的接收者与处理者
对上一步得到的事件列表中的每一个事件，确定其处理者。
如果事件是在上层处理的，那么把事件丢给上层组件（意味着上层需要提供给事件接收层一个回调函数，并且把这个回调函数作为属性传给负责接收事件的组件）。在上层组件中写出这个回调函数的原型，并且将它传递到下层组件，下层组件再将它与按钮的按下事件挂上钩。
如果事件是由本层组件处理的，那么写出这个处理函数的原型。
继续这个过程，直到每个事件都被丢到了负责处理它的组件，并且实现了该事件的处理函数原型。
4.5 非界面出发事件的接收者与处理者
非界面出发事件，是指不能由React Native基础组件（React Native框架提供的组件称为React Native基础组件）上报的事件。比如各种监听事件（Android手机后退键监听、混合开发原生代码测消息监听等）、定时器事件等。
首先需要确定这些事件的接收者在React Native组件分层结构中的位置。思路是：观察分析某个事件会造成哪些React Native组件（每个组件代表一个界面）被改变，将这些React Native组件看成一个树形结构（可能需要补充某些控制React Native组件），将接收者确定为这个树形结构的最高节点，然后让这个事件被触发的消息按业务逻辑处理，在这个树形结构中通过属性从上到下流动。
五、实现各组件业务逻辑
各组件的属性、状态机变量定型后，就可以实现各组件业务逻辑了。在实现业务逻辑的过程中，有可能需要给某组件增加成员变量、成员方法等。业务逻辑包括但不限于：
5.1 直接渲染状态机变量和属性
在各组件的render函数的相应位置填入状态机变量和属性名称。
5.2 将状态机变量以属性的方法交给下层组件
很多组件的状态机变量是由其子组件负责显示的，需要通过属性将状态机变量传给子组件。在render函数的子组件声明中添加对属性的赋值语句，实现状态机变量的传递。
5.3 实现状态机变量的其他业务控制逻辑
某些状态机变量是用来进行业务逻辑控制的。比如说，声明一个状态机变量来控制当前显示哪一个界面。