小程序App生命周期

• 小程序App生命周期是在app.js里面調用的，App(Object)函數用來注冊一個小程序，接受一個 Object 參數，指定其小程序的生命周期回調
• App() 必須在 app.js 中調用，必須調用且只能調用一次，不然會出現無法預期的后果

以上應該一眼就能看明白，以下主要講講前臺、后臺定義和運行機制等

1 . 前臺、后臺定義

• 當用戶點擊左上角關閉，或者按了設備 Home 鍵離開微信，小程序并沒有直接銷毀，而是進入了后臺onHide；當再次進入微信或再次打開小程序，又會從后臺進入前臺onShow。需要注意的是：只有當小程序進入后臺一定時間，或者系統資源占用過高，才會被真正的銷毀。

2 . 運行機制

• 小程序啟動會有兩種情況，一種是「冷啟動」，一種是「熱啟動」。 假如用戶已經打開過某小程序，然后在一定時間內再次打開該小程序，此時無需重新啟動，只需將后臺態的小程序切換到前臺onShow，這個過程就是熱啟動；冷啟動指的是用戶首次打開或小程序被微信主動銷毀后再次打開的情況，此時小程序需要重新加載啟動onLauch
• 小程序沒有重啟的概念
• 當小程序進入后臺，客戶端會維持一段時間的運行狀態，超過一定時間后（目前是5分鐘）會被微信主動銷毀
• 在 iOS 上，當微信客戶端在一定時間間隔內（目前是 5 秒）連續收到兩次及以上系統內存告警時，會主動進行小程序的銷毀，并提示用戶 「該小程序可能導致微信響應變慢被終止」。建議小程序在必要時使用 wx.onMemoryWarning 監聽內存告警事件，進行必要的內存清理。

3 . 更新機制

• 小程序冷啟動時如果發現有新版本，將會異步下載新版本的代碼包，并同時用客戶端本地的包進行啟動，即新版本的小程序需要等下一次冷啟動才會應用上。 如果需要馬上應用最新版本，可以使用 wx.getUpdateManager API 進行處理
• 小程序強制更新

//注意，小程序的更新的api需要基礎庫在1.9.90以上

3 . 再次打開邏輯

• 用戶打開小程序的預期有以下兩類場景：1、打開首頁 2、打開指定頁面
• 現在要打開的是首頁，如果上一次退出的時候是首頁，則保留狀態；否則，清空原來的頁面棧，打開首頁（相當于執行 wx.reLaunch 到首頁）
• 現在要打開的是指定頁面，不管上次在什么頁面，清空原來的頁面棧，打開指定頁面（相當于執行 wx.reLaunch 到指定頁）

小程序Page生命周期

• Page(Object) 函數用來注冊一個頁面。接受一個 Object 類型參數，其指定頁面的初始數據、生命周期回調、事件處理函數等

引用一張不錯的圖片來讓你一目了然，圖片來源于網絡

補充：app.onPageNotFound(Object)

基礎庫 1.9.90 開始支持，低版本需做兼容處理。

• 小程序要打開的頁面不存在時觸發,也可以使用 wx.onPageNotFound 綁定監聽
• 開發者可以在回調中進行頁面重定向，但必須在回調中同步處理，異步處理（例如 setTimeout 異步執行）無效
• 主要用于輪播、魔方等動態指定跳轉頁面的場景，避免出現頁面不存在的情況

App({onPageNotFound(res) {// 可以封裝一個小程序跳轉函數，智能解決tabbar頁面跳轉的問題wx.redirectTo({url: 'pages/...'})} })

生命周期執行順序

生命周期執行順序
分別了解了App和Page的生命周期函數，那他們之間有何關聯

吐槽一句，好多文章說什么app的生命周期函數onLauch可能會在page的onLoad之后觸發，搞得我一臉懵逼，說話這么不嚴謹，真的好嗎？？？

先看看正常的生命周期

App

控制臺輸出

應該說永遠是這個順序，現在再加點代碼，就用官方的例子

App

控制臺輸出

• 可以看出小程序生命周期函數并沒有錯亂，只是加了異步操作
• 你永遠不知道異步操作會排在正常周期的哪一個位置

解決方案
例子中已經給出了callback的方案，現在也可以使用promise來解決

1 . callback

• 解釋一波：Page頁面判斷當前app.globalData.userInfo是否有值
• 如果有，說明異步操作很順利，當做同步往下操作即可
• 如果沒有，則定義一個app方法（回調函數）app.userInfoReadyCallback = res => {...}
• 因為Page.onLoad沒有順利拿到app.globalData.userInfo，說明App頁面請求success異步操作滯后了
• 此時APP頁面不僅會給globalData.userInfo賦值，還會執行Page頁面定義的回調方法，完成業務邏輯

以上例子是官方對于授權之后的操作流程示例，實際使用替換自己的初始化函數和業務邏輯

注意事項
app.onLaunch全局只觸發一次，也就是打開的第一個頁面會有異步問題，打開第二個頁面肯定是可以拿到初始化數據的，但是小程序可以從不同場景進入，可能打開的并非是首頁，這時就需要給每一個可能被第一次就打開的頁面，寫回調函數，暫時沒想到類似vue那種設置全局路由回調的方案

2 . promise

• 最終效果應該和回調一樣，之前小程序不支持promise，一直沒有好好用過，等以后單獨研究~

---

Page實例生命周期

先來看一張很熟悉的圖
官方原話（以下內容你不需要立馬完全弄明白，不過以后它會有幫助）

咋一看，什么鬼，好吧~我聽你的，以后再說~

• 轉眼間，以后就到啦！好在有大佬解釋過了，借花獻佛，誰讓我是搬運工呢（最后會貼上參考文章鏈接）

Page實例由兩大線程組成

• 負責界面的線程（view thread）和服務線程（appservice thread），各司其職又互相配合
• 界面線程有四大狀態：

初始化狀態：初始化界面線程所需要的工作，包括工作機制，基本和我們開發者沒有關系，等初始化完畢就向 “服務線程”發送初始化完畢信號，然后進入等待傳回初始化數據狀態

首次渲染狀態：收到“服務線程”發來的初始化數據后（就是 json和js中的data數據），就開始渲染小程序界面，渲染完畢后，發送“首次渲染完畢信號”給服務線程，并將頁面展示給用戶

持續渲染狀態：此時界面線程繼續一直等待“服務線程”通過this.setdata（）函數發送來的界面數據，只要收到就重新局部渲染，也因此只要更新數據并發送信號，界面就自動更新

結束狀態：你懂得

• 服務線程五大狀態：

初始化狀態：無需和其他模塊交流，跟小程序開發也沒多大關聯，此階段就是啟動服務線程所需的基本功能，比如信號發送模塊。系統的初始化工作完畢，就調用自定義的onload和onshow，

然后等待界面線程的“界面線程初始化完成”信號。
onload是只會首次渲染的時候執行一次，onshow是每次界面切換都會執行，簡單理解，這就是唯一差別

等待激活狀態：接收到“界面線程初始化完成”信號后，將初始化數據發送給“界面線程”，等待界面線程完成初次渲染

激活狀態：收到界面線程發送來的“首次渲染完成”信號后，就進入激活狀態既程序的正常運行狀態，并調用自定義的onReady()函數。

此狀態下就可以通過 this.setData 函數發送界面數據給界面線程進行局部渲染，更新頁面

后臺運行狀態：如果界面進入后臺，服務線程就進入后臺運行狀態，從目前的官方解讀來說，這個狀態挺奇怪的，和激活狀態是相同的，也可以通過setdata函數更新界面的

總結一下

小程序的一生

• 打開小程序 -> app.onLaunch -> app.onShow -> Page.onLoad -> Page.onShow -> Page.onReady
• 進入下一個頁面 -> Page.onHide -> Next.onLoad -> Next.onShow -> Next.onReady
• 返回上一個頁面 -> Next.onUnload -> Page.onShow
• 離開小程序 -> app.onHide
• 再次進入 -> app未銷毀 ->app.onShow 否則從頭開始（銷毀判斷看上文運行機制）

注意：Tabbar頁面初始化之后不會被銷毀，也就是只會執行一次 onLoad 函數

只觸發一次的，一般都是用來初始化操作

• onLaunch：初始化全局數據，注意異步問題
• onLoad：初始化頁面數據
• onReady：代表頁面已經準備妥當，界面內容的修改，最好放在這里，如wx.setNavigationBarTitle
• onUnload：清除定時器，因為所有頁面的腳本邏輯都跑在同一個JsCore線程

觸發多次的，一般用來改變狀態

• onShow：刷新
• onHide：重置

總結

以上是生活随笔為你收集整理的小程序onload_小程序生命周期-基础篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。