微信小程序入口場景的問題整理與相關解決方案

前言

最近一段時間都在作小程序。

雖然是第二次開發小程序，可是上次作小程序已是一年前的事了，因此最終仍是被坑得死去活來。

此次是從零開始開發一個小程序，其實除了一些莫名其妙的兼容性問題，大多數坑點都是在微信小程序的各個入口場景處。

因此這裏整理一下微信小程序的各個入口場景，以及從這些入口場景進入小程序會面臨的問題以及解決方案。

這裏只列出經常使用的幾種場景：

• [簡單場景]啓動小程序並進入
• [簡單場景]退出重進（啓動小程序後，退出小程序，再次進入小程序）
• [簡單場景]退出重進首頁（啓動小程序後，退出小程序，經過掃二維碼再次進入小程序）
• [複雜場景]啓動並進入指定頁面（從小程序的分享卡片或者微信發送的通知消息進入小程序）
• [複雜場景]退出重進指定頁面（啓動小程序後，退出小程序，從小程序的分享卡片或者微信發送的通知消息進入小程序）

啓動小程序並進入

微信小程序的入口場景光微信提供的場景值就有幾十種，可是絕大多數均可以劃分爲啓動小程序並進入。

這是最經常使用的一種進入小程序的方式，好比經過搜索進入或者點擊最近使用小程序的方式進入，都算是這種類型。

這一場景下，首先咱們須要明白髮生了什麼：

下載小程序 => 啓動小程序 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了。