前言
我們這邊最近一直在做基礎服務，這一切都是為了完善技術體系，這裡對於前端來說便是我們需要做一個Hybrid體系，如果做App，React Native也是不錯的選擇，但是一定要有完善的分層：
① 底層框架解決開發效率，將複雜的部分做成一個黑匣子，給頁面開發展示的只是固定的三板斧，固定的模式下開發即可
② 工程部門為業務開發者封裝最小化開發環境，最優為瀏覽器，確實不行便為其提供一個類似瀏覽器的除錯環境
如此一來，業務便能快速迭代，因為業務開發者寫的程式碼大同小異，所以底層框架配合工程團隊（一般是同一個團隊），便可以在底層做掉很多效率效能問題。
稍微大點的公司，稍微寬裕的團隊，還會同步做很多後續的效能監控、錯誤日誌工作，如此形成一套文件->開發->除錯->構建->釋出->監控、分析 為一套完善的技術體系
如果形成了這麼一套體系，那麼後續就算是內部框架更改、技術革新，也是在這個體系上改造，但很可惜，很多團隊只會在這個路徑上做一部分，後面由於種種原因不在深入，有可能是感覺沒價值，而最恐怖的行為是，自己的體系沒形成就貿然的換基礎框架，戒之慎之啊！
從第三方應用接入來說，微信應該是做的最好的，百度這邊有直達號等類似的產品，但是其體系化感覺還是有待提高的，阿里應該也有類似的技術產品誕生，從我們這層來說，都沒有太多知曉，所以要麼是運營的不好要麼是做的不好。
而從小程式誕生以來，我這邊便一直在關注，至今整個小程式體系已經十分完備了，騰訊小程式和騰訊雲深度整合了，如果使用內測的開發者工具，全免費，純js就搞定小程式前後端，不用伺服器、儲存、cdn、服務程式碼，都是免費，開發完後端不用自己運維，大殺器的節奏，我有時候在想，騰訊的技術實力真的是強啊！
小程式的結構追溯
小程式的開發文件還是比較完善的，依舊是 賬號申請->demo 流程，等熟悉後便可以走程式碼上架等流程了，前端程式碼用工具構建後上傳，後臺服務自己維護，配置地址對映，我們這裡僅關注開發流程，所有使用其測試賬號即可。
|
1 2 |
appid wx0c387cc8c19bdf78 appsecret acd6c02e2fdca183416df1269d2e3fb9 |
經過一年多的發展，小程式形成的文件已經比較完善了，我們可以從文件和demo對小程式做出大概的判斷：
這裡就是小程式給業務人員可以看到的程式碼了，我們從這個程式碼以及執行，基本可以將小程式的梗概猜測一番，這裡首先看看其全域性控制器APP：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
//app.js App({ onLaunch: function () { // 展示本地儲存能力 var logs = wx.getStorageSync('logs') || [] logs.unshift(Date.now()) wx.setStorageSync('logs', logs) // 登入 wx.login({ success: res => { // 傳送 res.code 到後臺換取 openId, sessionKey, unionId } }) // 獲取使用者資訊 wx.getSetting({ success: res => { if (res.authSetting['scope.userInfo']) { // 已經授權，可以直接呼叫 getUserInfo 獲取頭像暱稱，不會彈框 wx.getUserInfo({ success: res => { // 可以將 res 傳送給後臺解碼出 unionId this.globalData.userInfo = res.userInfo // 由於 getUserInfo 是網路請求，可能會在 Page.onLoad 之後才返回 // 所以此處加入 callback 以防止這種情況 if (this.userInfoReadyCallback) { this.userInfoReadyCallback(res) } } }) } } }) }, globalData: { userInfo: null } }) |
一個應用只會有一個APP例項，而小程式為這個單例提供了幾個基本的事件定義，我們用的最多的應該是onLaunch、onShow、onHide（我還沒寫小程式，所以猜測）：
我們這裡來追溯一下小程式架構層的執行邏輯，從APP到一個view例項化是怎麼做的，這裡首先明確幾個點：
① 微信小程式事實上依舊是提供的webview執行環境，所以我們依舊可以在js環境中訪問window、location等屬性
② 微信小程式提供的展示的全部是Native定製化的UI，所以不要去想DOM操作的事
這裡各位可以想象為，小程式介面中有一塊webview在執行真正的程式碼邏輯，只不過這個webview除了裝載js程式什麼都沒做，而所有的頁面渲染全部是js通過URL Schema或者JSCore進行的Native通訊，叫Native根據設定的規則完成的頁面渲染。
全域性控制器App
這裡我們重點關注全域性控制器App這個類做了什麼，因為拿不到原始碼，我們這裡也只能猜測加單步除錯了，首先微信容器會準備一個webview容器為我們的js程式碼提供宿主環境，容器與構建工具會配合產出以下頁面：
他在這裡應該執行了例項化App的方法：
這一坨程式碼，在這個環境下便相當晦澀了：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 |
y = function() { function e(t) { var n = this; o(this, e), s.forEach(function(e) { var o = function() { var n = (t[e] || i.noop).bind(this); Reporter.__route__ = "App", Reporter.__method__ = e, (0, i.info)("App: " + e + " have been invoked"); try { n.apply(this, arguments) } catch (t) { Reporter.thirdErrorReport({ error: t, extend: "at App lifeCycleMethod " + e + " function" }) } }; n[e] = o.bind(n) }); for (var r in t) !function(e) { g(e) ? (0, i.warn)("關鍵字保護", "App's " + e + " is write-protected") : v(e) || ("[object Function]" === Object.prototype.toString.call(t[e]) ? n[e] = function() { var n; Reporter.__route__ = "App", Reporter.__method__ = e; try { n = t[e].apply(this, arguments) } catch (t) { Reporter.thirdErrorReport({ error: t, extend: "at App " + e + " function" }) } return n } .bind(n) : n[e] = t[e]) }(r); this.onError && Reporter.registerErrorListener(this.onError); var l = function() { "hang" === (arguments.length > 0 && void 0 !== arguments[0] ? arguments[0] : {}).mode && (f = !0); var e = (0, a.getCurrentPages)(); e.length && (e[e.length - 1].onHide(), (0, u.triggerAnalytics)("leavePage", e[e.length - 1], !0)), this.onHide(), (0, u.triggerAnalytics)("background") } , h = function() { var e = arguments.length > 0 && void 0 !== arguments[0] ? arguments[0] : {}; if (0 === e.scene || "0" === e.scene ? e.scene = c : c = e.scene, e.query = e.query || {}, (0, i.hasExitCondition)(e) && (p = !0), this.onShow(e), (0, u.triggerAnalytics)("foreground"), d || e.reLaunch) d = !1; else { var t = (0, a.getCurrentPages)(); t.length && (t[t.length - 1].onShow(), (0, u.triggerAnalytics)("enterPage", t[t.length - 1], !0)) } }; if ("undefined" != typeof __wxConfig && __wxConfig) { var y = __wxConfig.appLaunchInfo || {}; y.query = y.query || {}, c = y.scene, (0, i.hasExitCondition)(y) && (p = !0), this.onLaunch(y), (0, u.triggerAnalytics)("launch"), h.call(this, y) } else (0, i.error)("App Launch Error", "Can not find __wxConfig"); wx.onAppEnterBackground(l.bind(this)), wx.onAppEnterForeground(h.bind(this)), _.call(this, "function" == typeof t.onPageNotFound) } return r(e, [{ key: "getCurrentPage", value: function() { (0, i.warn)("將被廢棄", "App.getCurrentPage is deprecated, please use getCurrentPages."); var e = (0, a.getCurrentPage)(); if (e) return e.page } }]), e }(); |
這裡會往App中註冊一個事件，我們這裡註冊的是onLaunch事件，這裡對應的是當小程式初始化時候會執行這個回撥，所以原則上應該是Native裝在成功後會執行這個函式，這裡再詳細點說明下H5與Native的互動流程（這裡是我之前做Hybrid框架時候跟Native同事的互動約定，小程式應該大同小異）：
|
1 2 3 |
我們一般是在全域性上會有一個物件，儲存所有需要Native執行函式的物件，比如這裡的onLaunch，Native在執行到一個狀態時候會呼叫js全域性環境該物件上的一個函式 因為我們js註冊native執行是以字串key作為標誌，所以Native執行的時候可能是window.app['onLauch...']('引數') 而我們在window物件上會使用bind的方式將對應的作用域環境保留下來，這個時候執行的邏輯便是正確的 |
這裡在小程式全域性沒有找到對應的標識，這裡猜測是直接在app物件上，Native會直接執行APP物件上面的方法，但是我這裡有個疑問是View級別如果想註冊個全域性事件該怎麼做，這個留到後面來看看吧，這裡是Native載入webview時，會執行物件定義的onLaunch事件，在下面的程式碼看得到：
這裡會結合app.json獲取首先載入頁面的資訊，預設取pages陣列第一個，但是具體哪裡獲取和設定的程式碼沒有找到，也跟主流程無關，我們這裡忽略……然後我們看到程式碼執行了onShow邏輯：
然後流轉到註冊微信容器層面的事件，我覺得，無論如何，這裡應該是像微信容器註冊事件了吧，但是我找不到全域性的key?
Page流程
如果有微信小程式的同學，麻煩這裡指點一下，是不是猜測正確，順便可以幫忙說明下這裡，這裡也是我覺得全域性key，被Native呼叫的點，然後，邏輯上會獲取預設view的類開始做例項化，我們這裡來到view級別程式碼：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
//index.js //獲取應用例項 const app = getApp() Page({ data: { motto: 'Hello Wor11ld', userInfo: {}, hasUserInfo: false, canIUse: wx.canIUse('button.open-type.getUserInfo') }, //事件處理函式 bindViewTap: function() { wx.navigateTo({ url: '../logs/logs' }) }, onLoad: function () { if (app.globalData.userInfo) { this.setData({ userInfo: app.globalData.userInfo, hasUserInfo: true }) } else if (this.data.canIUse){ // 由於 getUserInfo 是網路請求，可能會在 Page.onLoad 之後才返回 // 所以此處加入 callback 以防止這種情況 app.userInfoReadyCallback = res => { this.setData({ userInfo: res.userInfo, hasUserInfo: true }) } } else { // 在沒有 open-type=getUserInfo 版本的相容處理 wx.getUserInfo({ success: res => { app.globalData.userInfo = res.userInfo this.setData({ userInfo: res.userInfo, hasUserInfo: true }) } }) } }, getUserInfo: function(e) { console.log(e) app.globalData.userInfo = e.detail.userInfo this.setData({ userInfo: e.detail.userInfo, hasUserInfo: true }) } }) |
他首先一來便獲取了當前app例項：
|
1 |
const app = getApp() |
其次開始了view例項化流程，這個是Page的類入口，大家要注意view.js只是定義的類，但是其例項化應該在全域性的控制器，其例項化在這裡完成的：
Page例項化後會自己執行onLoad以及onShow，但是這裡的onLoad以及onShow就看不出來分別了
總結
我們這裡一起瞎子摸象一般對微信小程式架構做了簡單的摸索，這裡發現事實上小程式流程與自己所想有一些出入，這裡初步認為流程是這樣的：
① 我們寫好小程式程式碼後，提交程式碼
② 在釋出流程中我們的程式碼經過構建流程，app.json以及入口的index.html（偽造頁面），重新組裝為一個只有js程式碼的空頁面
③ 這裡開始載入流程，使用者點選一個微信按鈕，進入小程式
④ 微信容器開啟Hybrid容器，webview載入入口頁面（我感覺應該有個規則可以通過url去開啟固定一個小程式頁面，這裡後續碰到開發案例再說）
⑤ webview執行環境例項化App，其後自動裝載預設Page（這裡預設是index）
PS：這裡我有個很疑惑的點，微信Native容器的各個事件點什麼時候執行，由誰執行？
⑥ 進入頁面渲染邏輯
⑦ ……
這裡我還比較在意，執行事件後，對應Native頁面是如何進行更新的，所以我們這裡關注下這段程式碼：
|
1 2 3 4 5 |
debugger; this.setData({ userInfo: app.globalData.userInfo, hasUserInfo: true }) |
這裡出現了一段非常關鍵的程式碼：
可以看到，我們這裡往微信容器註冊了一個appDataChange的非同步事件，而這個時候就將所有的邏輯交給了Native本身，Native執行結束後會根據webviewIds找到後續要執行的回撥繼續執行。
至於，容器如何使用webviewId找到對應函式的程式碼，我沒有找到。至此，我們對小程式結構的初步探索便結束了，我們本週後面時間繼續來對小程式進行深入學習。