RN与Native混合App的路由方案

一、纯RN路由

1. 适用于纯RN，使用react-navigation即可，仅需使用AppRegistry.registerComponent注册一个根组件
2. 只会存在一个VC或activity，所有的路由跳转其实都是在同一个VC或activity内跳转
3. 纯RN路由设计理念跟前端路由设计比较类似，没有接触过前端的Native刚开始接触可能会有点别扭
4. 如果有后续转混合的计划，建议在设计之初就使用桥接模式管理路由，为以后路由管理铺好路

二、纯Native路由

1. 每个RN页面，都使用AppRegistry.registerComponent单独注册，然后在Native端利用注册的组件创建的单独的RootView，并最终创建单独的VC承载。
2. 性能上肯定是纯Native更好，但相差并不大(用户基本无感知)
3. 在此感谢吉祥老师给的灵感

三、携程 - 混合路由

1. 携程CRN目前走的是混合路线，更多细节查看CRN的一些研究
2. 如果有些模块需要在其他App内复用，建议采用携程的模式，他们对路由进行了优化(没开源)，管理起来应该会方便些。

四、橘子 - 混合路由

1. 我们的核心思路是不让RN路由和Native路由有交叉，因为两者一旦交叉，就会衍生出很多case要处理，最为头疼的就是RN路由栈和Native路由栈的交叉管理
2. 因此我们对纯Native路由做了一个小小的变通，当我们App要嵌入一个跟当前业务完全无关的模块时，单独为这个模块打一个bundle，这个bundle就一个注册组件，内部跳转由navigation接管，类似于微信小程序那种。这样就实现了RN路由和Native路由的隔离，不用在再担心两种路由交叉的问题。

1. 生命周期的管理

1. 每次Native跳转，都要生成一个不会重复的pageId属性跟当前VC或Activity绑定，并且伴随参数传给RN页面，
2. RN页面在componentDidMount利用RN提供的通知DeviceEventEmitter注册生命周期事件，key就是生命周期名字加pageId，比如willAppear_pageId，didAppear_pageId。记得在componentWillUnmount里销毁该事件。
3. 当Native的路由操作触发VC或Activity的生命周期时，在Native的生命周期事件里通过之前注册的pageId发送通知，触发RN中相应的事件
4. 建议所有的页面都被高阶包含，这样就可以在高阶里统一注册和销毁了

2. iOS侧滑的管理

每次新进入一个页面都开启侧滑，然后Native提供RN层关闭的方法，这样当前页面可以根据需要决定是否关闭侧滑

3. 参数的管理

这个没啥好聊的，将跳转的参数在创建RootView的时候传过去就行

4. callback的管理

在创建RootView时传的参数只能包含基本类型，不能包含函数，因此还得通过id的方式来处理

1. 在RN调用Native的路由方法时，首先判断参数里是否有callback回调，没有就正常跳转
2. 有的话，为这个callback生成一个callbackId，并且以该callbackId作为key，callback为value通过DeviceEventEmitter将回调注册到RN中，并且将callbackId伴随参数传给RN页面
3. 执行callback时，其实就是触发key为callbackId所对应的事件
4. 如果设计多Bridge的设计，当跨bridge跳转时事件无法同步，就不能通过RN触发了，得通过Native找到相应的bridge进行触发。

5. 热更新

RN本身提供有热更新的逻辑，但若层级过深，就会失效。而这种路由方式因为每个页面都是一个VC/Activity，所以直接在当前页面reload刷新即可。不用回到首页，在一级级今天当前页面。