一、纯RN路由
- 适用于纯RN,使用react-navigation即可,仅需使用
AppRegistry.registerComponent
注册一个根组件- 只会存在一个VC或activity,所有的路由跳转其实都是在同一个VC或activity内跳转
- 纯RN路由设计理念跟前端路由设计比较类似,没有接触过前端的Native刚开始接触可能会有点别扭
- 如果有后续转混合的计划,建议在设计之初就使用桥接模式管理路由,为以后路由管理铺好路
二、纯Native路由
- 每个RN页面,都使用
AppRegistry.registerComponent
单独注册,然后在Native端利用注册的组件创建的单独的RootView,并最终创建单独的VC承载。- 性能上肯定是纯Native更好,但相差并不大(用户基本无感知)
- 在此感谢吉祥老师给的灵感
三、携程 - 混合路由
- 携程CRN目前走的是混合路线,更多细节查看CRN的一些研究
- 如果有些模块需要在其他App内复用,建议采用携程的模式,他们对路由进行了优化(没开源),管理起来应该会方便些。
四、橘子 - 混合路由
- 我们的核心思路是不让RN路由和Native路由有交叉,因为两者一旦交叉,就会衍生出很多case要处理,最为头疼的就是RN路由栈和Native路由栈的交叉管理
- 因此我们对纯Native路由做了一个小小的变通,当我们App要嵌入一个跟当前业务完全无关的模块时,单独为这个模块打一个bundle,这个bundle就一个注册组件,内部跳转由navigation接管,类似于微信小程序那种。这样就实现了RN路由和Native路由的隔离,不用在再担心两种路由交叉的问题。
1. 生命周期的管理
- 每次Native跳转,都要生成一个不会重复的pageId属性跟当前VC或Activity绑定,并且伴随参数传给RN页面,
- RN页面在
componentDidMount
利用RN提供的通知DeviceEventEmitter
注册生命周期事件,key就是生命周期名字加pageId,比如willAppear_pageId
,didAppear_pageId
。记得在componentWillUnmount
里销毁该事件。- 当Native的路由操作触发VC或Activity的生命周期时,在Native的生命周期事件里通过之前注册的pageId发送通知,触发RN中相应的事件
- 建议所有的页面都被高阶包含,这样就可以在高阶里统一注册和销毁了
2. iOS侧滑的管理
每次新进入一个页面都开启侧滑,然后Native提供RN层关闭的方法,这样当前页面可以根据需要决定是否关闭侧滑
3. 参数的管理
这个没啥好聊的,将跳转的参数在创建RootView的时候传过去就行
4. callback的管理
在创建RootView时传的参数只能包含基本类型,不能包含函数,因此还得通过id的方式来处理
- 在RN调用Native的路由方法时,首先判断参数里是否有callback回调,没有就正常跳转
- 有的话,为这个callback生成一个callbackId,并且以该callbackId作为key,callback为value通过
DeviceEventEmitter
将回调注册到RN中,并且将callbackId伴随参数传给RN页面- 执行callback时,其实就是触发key为callbackId所对应的事件
- 如果设计多Bridge的设计,当跨bridge跳转时事件无法同步,就不能通过RN触发了,得通过Native找到相应的bridge进行触发。
5. 热更新
RN本身提供有热更新的逻辑,但若层级过深,就会失效。而这种路由方式因为每个页面都是一个VC/Activity,所以直接在当前页面reload刷新即可。不用回到首页,在一级级今天当前页面。