前言 最近一段時間都在做小程式。 雖然是第二次開發小程式，但是上次做小程式已經是一年前的事了，所以最終還是被坑得死去活來。 這次是從零開始開發一個小程式，其實除了一些莫名其妙的相容性問題，大多數坑點都是在微信小程式的各個入口場景處。 所以這裡整理一下微信小程式的各個入口場景，以及從這些入口場景進入小 ...
前言
最近一段時間都在做小程式。
雖然是第二次開發小程式，但是上次做小程式已經是一年前的事了，所以最終還是被坑得死去活來。
這次是從零開始開發一個小程式，其實除了一些莫名其妙的相容性問題，大多數坑點都是在微信小程式的各個入口場景處。
所以這裡整理一下微信小程式的各個入口場景，以及從這些入口場景進入小程式會面臨的問題以及解決方案。
這裡只列出常用的幾種場景：
- [簡單場景]啟動小程式併進入
- [簡單場景]退出重進（啟動小程式後，退出小程式，再次進入小程式）
- [簡單場景]退出重進首頁（啟動小程式後，退出小程式，通過掃二維碼再次進入小程式）
- [複雜場景]啟動併進入指定頁面（從小程式的分享卡片或者微信發送的通知消息進入小程式）
- [複雜場景]退出重進指定頁面（啟動小程式後，退出小程式，從小程式的分享卡片或者微信發送的通知消息進入小程式）
啟動小程式併進入
微信小程式的入口場景光微信提供的場景值就有幾十種，但是絕大多數都可以劃分為啟動小程式併進入。
這是最常用的一種進入小程式的方式，比如通過搜索進入或者點擊最近使用小程式的方式進入，都算是這種類型。
這一場景下，首先我們需要明白髮生了什麼：
下載小程式 => 啟動小程式 onLaunch事件觸發 => 載入首頁 onLoad事件觸發 => 首頁 onShow事件然後在這個場景下，需要註意以下幾個問題：
- 這個場景下一般會涉及到登錄。
所謂登錄，不一定是要在這個階段做，但是登錄信息的判斷這個階段是一定要做的。
通常前端肯定是要將登錄的這些信息存儲在小程式的storage里，然後在onLaunch事件中判斷是否登錄，沒登錄就跳轉到登錄頁面，登錄了就跳轉到首頁。
這裡的登錄判斷一定要放在onLaunch，而不要放在首頁的onLoad裡面，因為小程式啟動一定會進入onLaunch，而不一定會進入首頁的onLoad。 - 而登錄頁面在設計的時候最好要加上一個url參數，傳入登錄成功後跳轉到的頁面地址，而不是登錄之後始終跳轉到首頁，後面會講為什麼需要這麼做。
- onLaunch階段是否有發出請求，併在請求完成後進行了頁面跳轉，或者請求完成設置storage，併在onLoad頁面中使用？
這種情況的出現，會導致在請求時間過長時，首頁的onLoad已經執行了，此時就會出現BUG。
對於這個問題，有的人會用定時器去判斷是否完成這個操作，但是我的建議是儘量避免在onLaunch中進行這些操作。
如果一定要有，那麼最好的方式就是做一個載入頁面去承載這些功能。 - 首頁數據的初始化，一般是放在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里。
但是這裡又和掃二維碼不同，掃二維碼的鏈接一般都是指定的首頁。
而這裡通常跳轉到的是非首頁的頁面，而且可能還多了複雜的業務功能。
我們在需求分析和設計階段應該更多地考慮到這裡可能會引發的複雜問題，而儘量將此處的業務邏輯簡化，或者加大估時。
接下來，我們將根據業務從簡單到複雜，慢慢講解這個場景下可能存在的問題。
最簡單的邀請函（進入小程式首頁）
和第一種場景差不多，這裡略過
進階邀請函（進入小程式指定頁面，帶參數，需要根據參數初始化頁面）
這種情況下，需要考慮以下幾個問題：
- 首先在onLaunch階段會判斷是否登錄，沒登錄那麼就需要跳轉到登錄頁面，登錄頁面登錄之後，肯定要跳轉到這個頁面，而不是首頁。
所以之前說過登錄頁面設計的時候需要傳入一個url參數，來明確登錄成功後跳轉到哪個頁面。 - 這種跳轉到指定頁面的情況通常都需要一個回到首頁的按鈕。
就比如邀請某人查看一篇文章，點擊邀請卡片後會進入小程式內的文章詳情。
一般在小程式內通常是通過點擊文章列表跳轉到文章詳情，那麼這個時候可以逐級返回到首頁。
但是在點擊邀請函進入的情況是沒有返回功能的，此時如果沒有回到首頁功能，那麼用戶可能就永遠沒法回到首頁。
（其實是可以的，但是小程式的的這個功能藏得比較深，不要指望所有用戶都那麼熱愛摸索） - 這裡一定要特別註意第一種場景的第三個應該註意的問題，對於第一種場景而言那個問題因為啟動次數很多容易出現，但是在當前的場景下可能很容易被忽略掉。
涉及身份的邀請函（進入小程式指定頁面，帶參數，需要根據參數切換身份，更可能涉及到登錄）
為了更好地說明這種情況，我們來列舉一個場景。
如果有一個打車軟體，進入這個軟體後有兩種身份，一種是乘客，一種是司機。
用戶是司機，那麼看到的是頁面A或者選定了TabA，如果是乘客，那麼看到的是頁面B或者選定了TabB。
而且還有一個需求，用戶上次登陸時什麼身份，這次登陸也是什麼身份。
考慮到換手機的場景，那麼這個信息肯定是存儲在服務端的，所以進入小程式的時候會去請求服務端進行判斷。
現在我用司機的身份發了個單，微信給了個通知消息，我沒點開。然後切換到乘客的身份了，再去點擊通知消息，那麼我會以司機的身份去打開這個消息。
這個場景其實在業務上來看是很合理的，但是對於我們的程式實現來看，複雜度一下子就上來了。
- 首先我們確定一下這個請求身份信息的請求在哪個階段發出？
onLaunch？
那麼是不是需要在onLoad階段去獲取這個身份的信息然後給出不同的頁面？
這樣一下子就會出現進階邀請函的第三個問題，而且還不僅僅是這一個問題，之後我們會講到。
所以這個地方需要做一個專門的邀請載入頁面去處理這個事情。 - 分離出一個單獨的載入頁面之後，其實我們的工作會變的簡單清晰起來。
因為我們只需要去做我們這個頁面所需要做的事情就行了。
根據參數去獲取我們現在的身份，然後以這種身份跳轉到相應的頁面。 - 這裡還涉及到一個問題，那就是正常啟動而不是通過通知消息進入的時候，也需要去請求服務端獲取身份信息。
我給的建議是一定要另外單獨建一個頁面去承載這個功能，而不要將這兩個載入頁面糅合到一起。
裡面的頁面展示我們可以用組件化的方式去做，但是頁面的邏輯一點更要分開。
因為這兩種情況真的很容易混雜，也是為了利於後面的維護工作。 - 正常啟動時的載入頁面也可以看情況糅合到首頁的onLoad裡面。
但是如果有可能，還是希望放在單獨的頁面里。
首頁往往功能很多，代碼量比較大，不要將本來可以分離出去的功能放進去。
還是那句話，頁面的職責分開。
我這裡講的其實還是一個比較常見的功能，通常我們的業務也不一定像上面這樣簡單。
所以如果涉及到這方面的操作，在需求分析和設計的時候就應該考慮清楚。
如果等到功能開發的時候再去考慮這些事情，那麼等待你的一定是延期或者加班。
退出重進指定頁面（啟動小程式後，退出小程式，從小程式的分享卡片或者微信發送的通知消息進入小程式）
這種場景同樣是第四種場景的進階，但是如果你在第四種場景中使用了我所說的載入頁面，那麼接下來的問題會簡單很多。
這一場景下，首先我們需要明白髮生了什麼：
再次進入小程式 => 進入退出小程式時所在頁面A 不觸發onShow => 觸發頁面A onHide => 觸發頁面A onUnload => 進入邀請載入頁面onLoad => 載入頁面onShow對於第四種場景中的打車小程式而言，如果按照我們先前所說沒有在onLaunch中獲取身份信息，而是放在了載入頁中，那麼現在什麼都不用改。
如果獲取身份信息的請求放在onLaunch中，現在又得在onLoad中加一道邏輯。
當然這裡還是得註意一個問題，對於這一類型的進入小程式的方式，比如從分享卡片進入和微信的通知消息進入。
即使他們所進入的頁面不同，但是他們都可以使用這個載入頁面去做判斷。
與正常啟動場景的載入頁面是不同的，他們本來就是同一種入口場景。
所以該共用的地方還是得共用，用不同的業務code判斷即可。
總結
總的來說，以上的幾種情況應該能涵蓋絕大多數小程式的入口場景。
整理的目的其實主要是為了做需求分析和設計時參考使用，以避免在考慮業務問題時漏過這些場景導致後期的工作計劃受到影響。
所謂加班和項目延期發佈，大都是前期需求分析和設計考慮不周。
我們不可能考慮到所有的場景，但是應該盡善盡美。
謀定而後動，前事不忘後事之師，也算是PDCA了。
