现在我用司机的身份发了个单，微信给了个通知消息，我没点开。然后切换到乘客的身份了，再去点击通知消息，那么我会以司机的身份去打开这个消息。
这个场景其实在业务上来看是很合理的，但是对于我们的程序实现来看，复杂度一下子就上来了。
1.首先我们确定一下这个请求身份信息的请求在哪个阶段发出？
onLaunch？
那么是不是需要在onLoad阶段去获取这个身份的信息然后给出不同的页面？
这样一下子就会出现进阶邀请函的第三个问题，而且还不仅仅是这一个问题，之后我们会讲到。
所以这个地方需要做一个专门的邀请加载页面去处理这个事情。
2.分离出一个单独的加载页面之后，其实我们的工作会变的简单清晰起来。
因为我们只需要去做我们这个页面所需要做的事情就行了。
根据参数去获取我们现在的身份，然后以这种身份跳转到相应的页面。
3.这里还涉及到一个问题，那就是正常启动而不是通过通知消息进入的时候，也需要去请求服务端获取身份信息。
我给的建议是一定要另外单独建一个页面去承载这个功能，而不要将这两个加载页面糅合到一起。
里面的页面展示我们可以用组件化的方式去做，但是页面的逻辑一点更要分开。
因为这两种情况真的很容易混杂，也是为了利于后面的维护工作。
4.正常启动时的加载页面也可以看情况糅合到首页的onLoad里面。
但是如果有可能，还是希望放在单独的页面里。
首页往往功能很多，代码量比较大，不要将本来可以分离出去的功能放进去。
还是那句话，页面的职责分开。
我这里讲的其实还是一个比较常见的功能，通常我们的业务也不一定像上面这样简单。
所以如果涉及到这方面的操作，在需求分析和设计的时候就应该考虑清楚。
如果等到功能开发的时候再去考虑这些事情，那么等待你的一定是延期或者加班。
退出重进指定页面（启动小程序后，退出小程序，从小程序的分享卡片或者微信发送的通知消息进入小程序）
这种场景同样是第四种场景的进阶，但是如果你在第四种场景中使用了我所说的加载页面，那么接下来的问题会简单很多。
这一场景下，首先我们需要明白发生了什么：