微信小程序入口场景的问题整理与相关解决方案

前言

最近一段时间都在作小程序。

虽然是第二次开发小程序，可是上次作小程序已是一年前的事了，因此最终仍是被坑得死去活来。

此次是从零开始开发一个小程序，其实除了一些莫名其妙的兼容性问题，大多数坑点都是在微信小程序的各个入口场景处。

因此这里整理一下微信小程序的各个入口场景，以及从这些入口场景进入小程序会面临的问题以及解决方案。

这里只列出经常使用的几种场景：

• [简单场景]启动小程序并进入
• [简单场景]退出重进（启动小程序后，退出小程序，再次进入小程序）
• [简单场景]退出重进首页（启动小程序后，退出小程序，经过扫二维码再次进入小程序）
• [复杂场景]启动并进入指定页面（从小程序的分享卡片或者微信发送的通知消息进入小程序）
• [复杂场景]退出重进指定页面（启动小程序后，退出小程序，从小程序的分享卡片或者微信发送的通知消息进入小程序）

启动小程序并进入

微信小程序的入口场景光微信提供的场景值就有几十种，可是绝大多数均可以划分为启动小程序并进入。

这是最经常使用的一种进入小程序的方式，好比经过搜索进入或者点击最近使用小程序的方式进入，都算是这种类型。

这一场景下，首先咱们须要明白发生了什么：

下载小程序 => 启动小程序 onLaunch事件触发 => 加载首页 onLoad事件触发 => 首页 onShow事件

而后在这个场景下，须要注意如下几个问题：

1. 这个场景下通常会涉及到登陆。
   所谓登陆，不必定是要在这个阶段作，可是登陆信息的判断这个阶段是必定要作的。
   一般前端确定是要将登陆的这些信息存储在小程序的storage里，而后在onLaunch事件中判断是否登陆，没登陆就跳转到登陆页面，登陆了就跳转到首页。
   这里的登陆判断必定要放在onLaunch，而不要放在首页的onLoad里面，由于小程序启动必定会进入onLaunch，而不必定会进入首页的onLoad。
2. 而登陆页面在设计的时候最好要加上一个url参数，传入登陆成功后跳转到的页面地址，而不是登陆以后始终跳转到首页，后面会讲为何须要这么作。
3. onLaunch阶段是否有发出请求，并在请求完成后进行了页面跳转，或者请求完成设置storage，并在onLoad页面中使用？
   这种状况的出现，会致使在请求时间过长时，首页的onLoad已经执行了，此时就会出现BUG。
   对于这个问题，有的人会用定时器去判断是否完成这个操做，可是个人建议是尽可能避免在onLaunch中进行这些操做。
   若是必定要有，那么最好的方式就是作一个加载页面去承载这些功能。
4. 首页数据的初始化，通常是放在onLoad中执行。固然老是有些特殊的需求是要放在onShow里面的。
   关于onLoad和onShow，最多见的处理区别就在跳转页面时。
   当载入首页时，先触发onLoad，再触发onShow。
   此时经过wx.navigateTo 的方式跳转到页面A，这个时候首页并无被关闭，那么从页面A再返回首页时，onLoad就不会触发，但onShow会触发。
   一般在加载数据时，通常会用到onLoad。
   可是若是说页面A更新了数据，而后返回首页时，首页的相关数据也须要更新。
   那么初始化数据就不能放在onLoad里，而须要放在onShow里。
   （固然还有一种方式是经过getCurrentPages的方式在页面A中调用首页的方法。可是这里极不推荐这种方式，属于某个页面的事情必定要给这个页面。最好不要将页面间的职责经过这种方式打乱，容易引发代码混乱，不易维护。）

退出重进（启动小程序后，退出小程序，再次进入小程序）

这种场景其实是对第一种场景的扩展。

而所谓的退出小程序无论你是点右上角的退出按钮仍是Home键直接切出都算是这类退出。

可是退出后再当即进入小程序的时候，依然会进入你退出小程序时所在的页面，而不会触发onLaunch，也不会触发这个页面的onLoad，不过onShow是确定会触发的。

这一场景下，首先咱们须要明白发生了什么：

再次进入小程序 => 进入退出小程序时所在页面 触发onShow

在这个场景下，只须要注意onShow中是否有不可重复执行的操做。

例如onShow中会获取用户喜欢吃的食物，加载到页面的列表中，在这种场景下，若是不清空以前的列表或者加个判断的话，就会出现重复数据。

退出重进首页（启动小程序后，退出小程序，经过扫二维码再次进入小程序）

这种场景其实是对第二种场景的扩展。

咱们一般给二维码配置的是一个无参数的小程序首页地址，当咱们退出小程序，经过扫二维码再次进入小程序时会进入首页。

这一场景下，首先咱们须要明白发生了什么：

再次进入小程序 => 进入退出小程序时所在页面A 不触发onShow => 触发页面A onHide => 触发页面A onUnload=> 进入首页 onLoad => 首页onShow

在这个场景下，除了须要注意第二种场景存在的问题，还须要注意页面A的onHide事件中是否会触发奇怪的操做，例如页面跳转。

启动并进入指定页面（从小程序的分享卡片或者微信发送的通知消息进入小程序）

这块场景常见于邀请他人进入小程序，须要注意的是他们每每被赋予了更多的业务功能，也就每每增大了小程序的实现难度。

这一场景下，首先咱们须要明白发生了什么：

下载小程序 => 启动小程序 onLaunch事件触发 => 加载指定页面 onLoad事件触发 =>指定页面  onShow事件

这里就能够看出，并非进入小程序就必定会进入首页的onLoad。

因此这就是为何以前强调不要将登陆判断放在首页的onLoad中，而必定要放在onLaunch里。

可是这里又和扫二维码不一样，扫二维码的连接通常都是指定的首页。

而这里一般跳转到的是非首页的页面，并且可能还多了复杂的业务功能。

咱们在需求分析和设计阶段应该更多地考虑到这里可能会引起的复杂问题，而尽可能将此处的业务逻辑简化，或者加大估时。

接下来，咱们将根据业务从简单到复杂，慢慢讲解这个场景下可能存在的问题。

最简单的邀请函（进入小程序首页）

和第一种场景差很少，这里略过

进阶邀请函（进入小程序指定页面，带参数，须要根据参数初始化页面）

这种状况下，须要考虑如下几个问题：

1. 首先在onLaunch阶段会判断是否登陆，没登陆那么就须要跳转到登陆页面，登陆页面登陆以后，确定要跳转到这个页面，而不是首页。
   因此以前说过登陆页面设计的时候须要传入一个url参数，来明确登陆成功后跳转到哪一个页面。
2. 这种跳转到指定页面的状况一般都须要一个回到首页的按钮。
   就好比邀请某人查看一篇文章，点击邀请卡片后会进入小程序内的文章详情。
   通常在小程序内一般是经过点击文章列表跳转到文章详情，那么这个时候能够逐级返回到首页。
   可是在点击邀请函进入的状况是没有返回功能的，此时若是没有回到首页功能，那么用户可能就永远无法回到首页。
   （实际上是能够的，可是小程序的的这个功能藏得比较深，不要期望全部用户都那么热爱摸索）
3. 这里必定要特别注意第一种场景的第三个应该注意的问题，对于第一种场景而言那个问题由于启动次数不少容易出现，可是在当前的场景下可能很容易被忽略掉。

涉及身份的邀请函（进入小程序指定页面，带参数，须要根据参数切换身份，更可能涉及到登陆）

为了更好地说明这种状况，咱们来列举一个场景。

若是有一个打车软件，进入这个软件后有两种身份，一种是乘客，一种是司机。

用户是司机，那么看到的是页面A或者选定了TabA，若是是乘客，那么看到的是页面B或者选定了TabB。

并且还有一个需求，用户上次登录时什么身份，此次登录也是什么身份。

考虑到换手机的场景，那么这个信息确定是存储在服务端的，因此进入小程序的时候会去请求服务端进行判断。

如今我用司机的身份发了个单，微信给了个通知消息，我没点开。而后切换到乘客的身份了，再去点击通知消息，那么我会以司机的身份去打开这个消息。

这个场景其实在业务上来看是很合理的，可是对于咱们的程序实现来看，复杂度一会儿就上来了。

1. 首先咱们肯定一下这个请求身份信息的请求在哪一个阶段发出？
   onLaunch？
   那么是否是须要在onLoad阶段去获取这个身份的信息而后给出不一样的页面？
   这样一会儿就会出现进阶邀请函的第三个问题，并且还不只仅是这一个问题，以后咱们会讲到。
   因此这个地方须要作一个专门的邀请加载页面去处理这个事情。
2. 分离出一个单独的加载页面以后，其实咱们的工做会变的简单清晰起来。
   由于咱们只须要去作咱们这个页面所须要作的事情就好了。
   根据参数去获取咱们如今的身份，而后以这种身份跳转到相应的页面。
3. 这里还涉及到一个问题，那就是正常启动而不是经过通知消息进入的时候，也须要去请求服务端获取身份信息。
   我给的建议是必定要另外单独建一个页面去承载这个功能，而不要将这两个加载页面糅合到一块儿。
   里面的页面展现咱们能够用组件化的方式去作，可是页面的逻辑一点更要分开。
   由于这两种状况真的很容易混杂，也是为了利于后面的维护工做。
4. 正常启动时的加载页面也能够看状况糅合到首页的onLoad里面。
   可是若是有可能，仍是但愿放在单独的页面里。
   首页每每功能不少，代码量比较大，不要将原本能够分离出去的功能放进去。
   仍是那句话，页面的职责分开。

我这里讲的其实仍是一个比较常见的功能，一般咱们的业务也不必定像上面这样简单。

因此若是涉及到这方面的操做，在需求分析和设计的时候就应该考虑清楚。

若是等到功能开发的时候再去考虑这些事情，那么等待你的必定是延期或者加班。

退出重进指定页面（启动小程序后，退出小程序，从小程序的分享卡片或者微信发送的通知消息进入小程序）

这种场景一样是第四种场景的进阶，可是若是你在第四种场景中使用了我所说的加载页面，那么接下来的问题会简单不少。

这一场景下，首先咱们须要明白发生了什么：

再次进入小程序 => 进入退出小程序时所在页面A 不触发onShow => 触发页面A onHide => 触发页面A onUnload => 进入邀请加载页面onLoad => 加载页面onShow

对于第四种场景中的打车小程序而言，若是按照咱们先前所说没有在onLaunch中获取身份信息，而是放在了加载页中，那么如今什么都不用改。

若是获取身份信息的请求放在onLaunch中，如今又得在onLoad中加一道逻辑。

固然这里仍是得注意一个问题，对于这一类型的进入小程序的方式，好比从分享卡片进入和微信的通知消息进入。

即便他们所进入的页面不一样，可是他们均可以使用这个载入页面去作判断。

与正常启动场景的载入页面是不一样的，他们原本就是同一种入口场景。

因此该共用的地方仍是得共用，用不一样的业务code判断便可。

总结

总的来讲，以上的几种状况应该能涵盖绝大多数小程序的入口场景。

整理的目的其实主要是为了作需求分析和设计时参考使用，以免在考虑业务问题时漏过这些场景致使后期的工做计划受到影响。

所谓加班和项目延期发布，大都是前期需求分析和设计考虑不周。

咱们不可能考虑到全部的场景，可是应该尽善尽美。

谋定然后动，前事不忘后事之师，也算是PDCA了。