前言

最近一段時(shí)間都在做小程序。

雖然是第二次開發(fā)小程序，但是上次做小程序已經(jīng)是一年前的事了，所以最終還是被坑得死去活來。

這次是從零開始開發(fā)一個(gè)小程序，其實(shí)除了一些莫名其妙的兼容性問題，大多數(shù)坑點(diǎn)都是在微信小程序的各個(gè)入口場(chǎng)景處。

所以這里整理一下微信小程序的各個(gè)入口場(chǎng)景，以及從這些入口場(chǎng)景進(jìn)入小程序會(huì)面臨的問題以及解決方案。

這里只列出常用的幾種場(chǎng)景：

• [簡單場(chǎng)景]啟動(dòng)小程序并進(jìn)入
• [簡單場(chǎng)景]退出重進(jìn)（啟動(dòng)小程序后，退出小程序，再次進(jìn)入小程序）
• [簡單場(chǎng)景]退出重進(jìn)首頁（啟動(dòng)小程序后，退出小程序，通過掃二維碼再次進(jìn)入小程序）
• [復(fù)雜場(chǎng)景]啟動(dòng)并進(jìn)入指定頁面（從小程序的分享卡片或者微信發(fā)送的通知消息進(jìn)入小程序）
• [復(fù)雜場(chǎng)景]退出重進(jìn)指定頁面（啟動(dòng)小程序后，退出小程序，從小程序的分享卡片或者微信發(fā)送的通知消息進(jìn)入小程序）

啟動(dòng)小程序并進(jìn)入

微信小程序的入口場(chǎng)景光微信提供的場(chǎng)景值就有幾十種，但是絕大多數(shù)都可以劃分為啟動(dòng)小程序并進(jìn)入。

這是最常用的一種進(jìn)入小程序的方式，比如通過搜索進(jìn)入或者點(diǎn)擊最近使用小程序的方式進(jìn)入，都算是這種類型。

這一場(chǎng)景下，首先我們需要明白發(fā)生了什么：

下載小程序 => 啟動(dòng)小程序 onLaunch事件觸發(fā) => 加載首頁 onLoad事件觸發(fā) => 首頁 onShow事件

然后在這個(gè)場(chǎng)景下，需要注意以下幾個(gè)問題：

1.這個(gè)場(chǎng)景下一般會(huì)涉及到登錄。

所謂登錄，不一定是要在這個(gè)階段做，但是登錄信息的判斷這個(gè)階段是一定要做的。

通常前端肯定是要將登錄的這些信息存儲(chǔ)在小程序的storage里，然后在onLaunch事件中判斷是否登錄，沒登錄就跳轉(zhuǎn)到登錄頁面，登錄了就跳轉(zhuǎn)到首頁。

這里的登錄判斷一定要放在onLaunch，而不要放在首頁的onLoad里面，因?yàn)樾〕绦騿?dòng)一定會(huì)進(jìn)入onLaunch，而不一定會(huì)進(jìn)入首頁的onLoad。

2.而登錄頁面在設(shè)計(jì)的時(shí)候最好要加上一個(gè)url參數(shù)

傳入登錄成功后跳轉(zhuǎn)到的頁面地址，而不是登錄之后始終跳轉(zhuǎn)到首頁，后面會(huì)講為什么需要這么做。

3.onLaunch階段是否有發(fā)出請(qǐng)求

并在請(qǐng)求完成后進(jìn)行了頁面跳轉(zhuǎn)，或者請(qǐng)求完成設(shè)置storage，并在onLoad頁面中使用？
這種情況的出現(xiàn)，會(huì)導(dǎo)致在請(qǐng)求時(shí)間過長時(shí)，首頁的onLoad已經(jīng)執(zhí)行了，此時(shí)就會(huì)出現(xiàn)BUG。

對(duì)于這個(gè)問題，有的人會(huì)用定時(shí)器去判斷是否完成這個(gè)操作，但是我的建議是盡量避免在onLaunch中進(jìn)行這些操作。
如果一定要有，那么最好的方式就是做一個(gè)加載頁面去承載這些功能。

4.首頁數(shù)據(jù)的初始化

一般是放在onLoad中執(zhí)行。當(dāng)然總是有些特殊的需求是要放在onShow里面的。

關(guān)于onLoad和onShow，最常見的處理區(qū)別就在跳轉(zhuǎn)頁面時(shí)。

當(dāng)載入首頁時(shí)，先觸發(fā)onLoad，再觸發(fā)onShow。

此時(shí)通過wx.navigateTo 的方式跳轉(zhuǎn)到頁面A，這個(gè)時(shí)候首頁并沒有被關(guān)閉，那么從頁面A再返回首頁時(shí)，onLoad就不會(huì)觸發(fā)，但onShow會(huì)觸發(fā)。

通常在加載數(shù)據(jù)時(shí)，一般會(huì)用到onLoad。

但是如果說頁面A更新了數(shù)據(jù)，然后返回首頁時(shí)，首頁的相關(guān)數(shù)據(jù)也需要更新。

那么初始化數(shù)據(jù)就不能放在onLoad里，而需要放在onShow里。

（當(dāng)然還有一種方式是通過getCurrentPages的方式在頁面A中調(diào)用首頁的方法。但是這里極不推薦這種方式，屬于某個(gè)頁面的事情一定要給這個(gè)頁面。最好不要將頁面間的職責(zé)通過這種方式打亂，容易引起代碼混亂，不易維護(hù)。）

退出重進(jìn)（啟動(dòng)小程序后，退出小程序，再次進(jìn)入小程序）

這種場(chǎng)景實(shí)際上是對(duì)第一種場(chǎng)景的擴(kuò)展。

而所謂的退出小程序不管你是點(diǎn)右上角的退出按鈕還是Home鍵直接切出都算是這類退出。

但是退出后再立即進(jìn)入小程序的時(shí)候，依然會(huì)進(jìn)入你退出小程序時(shí)所在的頁面，而不會(huì)觸發(fā)onLaunch，也不會(huì)觸發(fā)這個(gè)頁面的onLoad，不過onShow是肯定會(huì)觸發(fā)的。

這一場(chǎng)景下，首先我們需要明白發(fā)生了什么：

再次進(jìn)入小程序 => 進(jìn)入退出小程序時(shí)所在頁面 觸發(fā)onShow

在這個(gè)場(chǎng)景下，只需要注意onShow中是否有不可重復(fù)執(zhí)行的操作。

例如onShow中會(huì)獲取用戶喜歡吃的食物，加載到頁面的列表中，在這種場(chǎng)景下，如果不清空之前的列表或者加個(gè)判斷的話，就會(huì)出現(xiàn)重復(fù)數(shù)據(jù)。

退出重進(jìn)首頁（啟動(dòng)小程序后，退出小程序，通過掃二維碼再次進(jìn)入小程序）

這種場(chǎng)景實(shí)際上是對(duì)第二種場(chǎng)景的擴(kuò)展。

我們通常給二維碼配置的是一個(gè)無參數(shù)的小程序首頁地址，當(dāng)我們退出小程序，通過掃二維碼再次進(jìn)入小程序時(shí)會(huì)進(jìn)入首頁。

這一場(chǎng)景下，首先我們需要明白發(fā)生了什么：

再次進(jìn)入小程序 => 進(jìn)入退出小程序時(shí)所在頁面A 不觸發(fā)onShow => 觸發(fā)頁面A onHide => 觸發(fā)頁面A onUnload=> 進(jìn)入首頁 onLoad => 首頁onShow

在這個(gè)場(chǎng)景下，除了需要注意第二種場(chǎng)景存在的問題，還需要注意頁面A的onHide事件中是否會(huì)觸發(fā)奇怪的操作，例如頁面跳轉(zhuǎn)。

啟動(dòng)并進(jìn)入指定頁面（從小程序的分享卡片或者微信發(fā)送的通知消息進(jìn)入小程序）

這塊場(chǎng)景常見于邀請(qǐng)他人進(jìn)入小程序，需要注意的是他們往往被賦予了更多的業(yè)務(wù)功能，也就往往增大了小程序的實(shí)現(xiàn)難度。

這一場(chǎng)景下，首先我們需要明白發(fā)生了什么：

下載小程序 => 啟動(dòng)小程序 onLaunch事件觸發(fā) => 加載指定頁面 onLoad事件觸發(fā) =>指定頁面 onShow事件

這里就可以看出，并不是進(jìn)入小程序就一定會(huì)進(jìn)入首頁的onLoad。

所以這就是為什么之前強(qiáng)調(diào)不要將登錄判斷放在首頁的onLoad中，而一定要放在onLaunch里。

但是這里又和掃二維碼不同，掃二維碼的鏈接一般都是指定的首頁。

而這里通常跳轉(zhuǎn)到的是非首頁的頁面，而且可能還多了復(fù)雜的業(yè)務(wù)功能。

我們?cè)谛枨蠓治龊驮O(shè)計(jì)階段應(yīng)該更多地考慮到這里可能會(huì)引發(fā)的復(fù)雜問題，而盡量將此處的業(yè)務(wù)邏輯簡化，或者加大估時(shí)。

接下來，我們將根據(jù)業(yè)務(wù)從簡單到復(fù)雜，慢慢講解這個(gè)場(chǎng)景下可能存在的問題。

最簡單的邀請(qǐng)函（進(jìn)入小程序首頁）

和第一種場(chǎng)景差不多，這里略過

進(jìn)階邀請(qǐng)函（進(jìn)入小程序指定頁面，帶參數(shù)，需要根據(jù)參數(shù)初始化頁面）

這種情況下，需要考慮以下幾個(gè)問題：

1.首先在onLaunch階段會(huì)判斷是否登錄

沒登錄那么就需要跳轉(zhuǎn)到登錄頁面，登錄頁面登錄之后，肯定要跳轉(zhuǎn)到這個(gè)頁面，而不是首頁。

所以之前說過登錄頁面設(shè)計(jì)的時(shí)候需要傳入一個(gè)url參數(shù)，來明確登錄成功后跳轉(zhuǎn)到哪個(gè)頁面。

2.這種跳轉(zhuǎn)到指定頁面的情況通常都需要一個(gè)回到首頁的按鈕

就比如邀請(qǐng)某人查看一篇文章，點(diǎn)擊邀請(qǐng)卡片后會(huì)進(jìn)入小程序內(nèi)的文章詳情。

一般在小程序內(nèi)通常是通過點(diǎn)擊文章列表跳轉(zhuǎn)到文章詳情，那么這個(gè)時(shí)候可以逐級(jí)返回到首頁。

但是在點(diǎn)擊邀請(qǐng)函進(jìn)入的情況是沒有返回功能的，此時(shí)如果沒有回到首頁功能，那么用戶可能就永遠(yuǎn)沒法回到首頁。

（其實(shí)是可以的，但是小程序的的這個(gè)功能藏得比較深，不要指望所有用戶都那么熱愛摸索）

3.這里一定要特別注意第一種場(chǎng)景的第三個(gè)應(yīng)該注意的問題

對(duì)于第一種場(chǎng)景而言那個(gè)問題因?yàn)閱?dòng)次數(shù)很多容易出現(xiàn)，但是在當(dāng)前的場(chǎng)景下可能很容易被忽略掉。

涉及身份的邀請(qǐng)函（進(jìn)入小程序指定頁面，帶參數(shù)，需要根據(jù)參數(shù)切換身份，更可能涉及到登錄）

為了更好地說明這種情況，我們來列舉一個(gè)場(chǎng)景。

如果有一個(gè)打車軟件，進(jìn)入這個(gè)軟件后有兩種身份，一種是乘客，一種是司機(jī)。

用戶是司機(jī)，那么看到的是頁面A或者選定了TabA，如果是乘客，那么看到的是頁面B或者選定了TabB。

而且還有一個(gè)需求，用戶上次登陸時(shí)什么身份，這次登陸也是什么身份。

考慮到換手機(jī)的場(chǎng)景，那么這個(gè)信息肯定是存儲(chǔ)在服務(wù)端的，所以進(jìn)入小程序的時(shí)候會(huì)去請(qǐng)求服務(wù)端進(jìn)行判斷。

現(xiàn)在我用司機(jī)的身份發(fā)了個(gè)單，微信給了個(gè)通知消息，我沒點(diǎn)開。然后切換到乘客的身份了，再去點(diǎn)擊通知消息，那么我會(huì)以司機(jī)的身份去打開這個(gè)消息。

這個(gè)場(chǎng)景其實(shí)在業(yè)務(wù)上來看是很合理的，但是對(duì)于我們的程序?qū)崿F(xiàn)來看，復(fù)雜度一下子就上來了。

1.首先我們確定一下這個(gè)請(qǐng)求身份信息的請(qǐng)求在哪個(gè)階段發(fā)出？

onLaunch？

那么是不是需要在onLoad階段去獲取這個(gè)身份的信息然后給出不同的頁面？

這樣一下子就會(huì)出現(xiàn)進(jìn)階邀請(qǐng)函的第三個(gè)問題，而且還不僅僅是這一個(gè)問題，之后我們會(huì)講到。

所以這個(gè)地方需要做一個(gè)專門的邀請(qǐng)加載頁面去處理這個(gè)事情。

2.分離出一個(gè)單獨(dú)的加載頁面之后，其實(shí)我們的工作會(huì)變的簡單清晰起來。

因?yàn)槲覀冎恍枰プ鑫覀冞@個(gè)頁面所需要做的事情就行了。

根據(jù)參數(shù)去獲取我們現(xiàn)在的身份，然后以這種身份跳轉(zhuǎn)到相應(yīng)的頁面。

3.這里還涉及到一個(gè)問題，那就是正常啟動(dòng)而不是通過通知消息進(jìn)入的時(shí)候，也需要去請(qǐng)求服務(wù)端獲取身份信息。

我給的建議是一定要另外單獨(dú)建一個(gè)頁面去承載這個(gè)功能，而不要將這兩個(gè)加載頁面糅合到一起。

里面的頁面展示我們可以用組件化的方式去做，但是頁面的邏輯一點(diǎn)更要分開。

因?yàn)檫@兩種情況真的很容易混雜，也是為了利于后面的維護(hù)工作。

4.正常啟動(dòng)時(shí)的加載頁面也可以看情況糅合到首頁的onLoad里面。

但是如果有可能，還是希望放在單獨(dú)的頁面里。

首頁往往功能很多，代碼量比較大，不要將本來可以分離出去的功能放進(jìn)去。

還是那句話，頁面的職責(zé)分開。

我這里講的其實(shí)還是一個(gè)比較常見的功能，通常我們的業(yè)務(wù)也不一定像上面這樣簡單。

所以如果涉及到這方面的操作，在需求分析和設(shè)計(jì)的時(shí)候就應(yīng)該考慮清楚。

如果等到功能開發(fā)的時(shí)候再去考慮這些事情，那么等待你的一定是延期或者加班。

退出重進(jìn)指定頁面（啟動(dòng)小程序后，退出小程序，從小程序的分享卡片或者微信發(fā)送的通知消息進(jìn)入小程序）

這種場(chǎng)景同樣是第四種場(chǎng)景的進(jìn)階，但是如果你在第四種場(chǎng)景中使用了我所說的加載頁面，那么接下來的問題會(huì)簡單很多。

這一場(chǎng)景下，首先我們需要明白發(fā)生了什么：

再次進(jìn)入小程序 => 進(jìn)入退出小程序時(shí)所在頁面A 不觸發(fā)onShow => 觸發(fā)頁面A onHide => 觸發(fā)頁面A onUnload => 進(jìn)入邀請(qǐng)加載頁面onLoad => 加載頁面onShow

對(duì)于第四種場(chǎng)景中的打車小程序而言，如果按照我們先前所說沒有在onLaunch中獲取身份信息，而是放在了加載頁中，那么現(xiàn)在什么都不用改。

如果獲取身份信息的請(qǐng)求放在onLaunch中，現(xiàn)在又得在onLoad中加一道邏輯。

當(dāng)然這里還是得注意一個(gè)問題，對(duì)于這一類型的進(jìn)入小程序的方式，比如從分享卡片進(jìn)入和微信的通知消息進(jìn)入。

即使他們所進(jìn)入的頁面不同，但是他們都可以使用這個(gè)載入頁面去做判斷。

與正常啟動(dòng)場(chǎng)景的載入頁面是不同的，他們本來就是同一種入口場(chǎng)景。

所以該共用的地方還是得共用，用不同的業(yè)務(wù)code判斷即可。

總結(jié)

總的來說，以上的幾種情況應(yīng)該能涵蓋絕大多數(shù)小程序的入口場(chǎng)景。

整理的目的其實(shí)主要是為了做需求分析和設(shè)計(jì)時(shí)參考使用，以避免在考慮業(yè)務(wù)問題時(shí)漏過這些場(chǎng)景導(dǎo)致后期的工作計(jì)劃受到影響。

所謂加班和項(xiàng)目延期發(fā)布，大都是前期需求分析和設(shè)計(jì)考慮不周。

我們不可能考慮到所有的場(chǎng)景，但是應(yīng)該盡善盡美。

謀定而后動(dòng)，前事不忘后事之師，也算是PDCA了。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。