微信小程式之啟動頁的重要性

啟動頁在APP中是個很常見的需求，為什麼對於小程式來說也非常重要呢？首先我描述一下我在開發過程中遇到的一些問題以及解決的步驟，到最後為什麼要加啟動頁，看完你就明白了。

小程式的首頁需要展示使用者關注的小區資訊，意味著一開啟小程式我就得先執行登入的邏輯，只有登入了之後才能獲取使用者關注的小區資訊。

在小程式啟動的時候自動登入，目前沒獲取使用者資訊，所以不需要使用者授權，這個邏輯放在根目錄下的app.js的onLaunch方法中。只要啟動小程式就會執行onLaunch方法。

做完之後發現了一個很嚴重的問題，就是app.js的onLaunch方法確實會在小程式啟動的時候執行，但是首頁也會是在app.json檔案的pages中第一個頁面也會同時執行，它不是阻塞的。會導致一個問題就是首頁獲取關注資訊執行完了，登入的邏輯還沒完，獲取不到正確的資料。

於是把登入的邏輯放到首頁的onLoad方法中執行，在登入成功之後再去獲取關注的資料，這樣就能解決上面說的問題了。

後面又有一個需求，就是分享功能，分享出去的頁面中也需要用到使用者資訊，這個就尷尬了，分享出去的頁面，使用者進入的時候還是進入的這個頁面，不會執行首頁的邏輯，是拿不到使用者資訊的。

後面想了下，還是增加一個啟動頁來做中轉吧，登入的邏輯還是放到app.js中，只要小程式啟動了就可以執行，無論是第一次進入還是通過分享的頁面進入，都可以自動登入。

問題是如何實現阻塞功能，就是登入之後再去跳轉到其它的頁面，思路就是通過定時器的方式去檢測登入狀態，成功了之後再跳轉。

分享也是一樣，分享出去的地址不再是本頁面的地址，而是啟動頁的地址，帶一個引數，這個引數才是本頁面的地址，當用戶點選分享的小程式進入之後會先進入啟動頁，啟動頁中獲取引數，等待登入邏輯執行完成之後，再根據引數跳轉到分享的頁面。

啟動頁程式碼：

當檢查超過10秒鐘，登入資訊還獲取不到的時候就會給出提示，後續會加上一個讓使用者手動授權登入的頁面。

這種方式勉強能實現需求，但不是最好的方式，問題一看就知道了，如果加了啟動頁，意味著所有的入口都變成了啟動頁，就沒有必要通過定時去檢測了，直接將登入的邏輯放到啟動頁中來執行，在success中在做跳轉的邏輯，這樣的方式才是最好的，具體程式碼我就不貼出來，大家明白就好。

具體的分享頁面程式碼：

重點關注isshare=1這個引數，當直接開啟分享的頁面時，使用者點選左上角的返回按鈕，基於現有的邏輯會退回到啟動頁，因為是從啟動頁中轉過來的，這是有問題的，要麼就去掉這個返回按鈕，要麼就返回到首頁。

所以對於分享的頁面帶了一個引數識別，當是從分享頁面進來的時候返回就到首頁面。具體邏輯在頁面的onUnload函式中，在頁面解除安裝的時候進行跳轉：

以上就是啟動頁的作用以及需要啟動頁的一些背景，第一次開發小程式，總會碰到很多問題。

總結+分享=積累。