參考文檔
小程序底層實現原理及一些思考
- 為了安全和管控, 雙線程執行
- Web Worker執行用戶的代碼; UI線程執行大部分的功能.
微信小程序架構原理
- 只通過mvvm模板語法動態改變頁面, 不支持BOM操作
- 編譯過程:
- wcc可執行程序編譯.xml文件生成js腳本, js腳本在傳入正確路徑, 得到了一個virtual dom樹.
- WAWebview.js
- wx下注冊是api, 最終都會調用WeixinJSBrige方法.
- wxparser對象, 提供dom到wx element之間的映射, 元素操作管理, 事件功能管理
- 部分組件使用原生代碼實現, 例如:
wx-video,wx-canvas,wx-map,wx-textarea等 - native組件懸浮在webview之上, 大部分組件使用前端實現.
- WeixinJSBridge
- wx.request實際調用WeixinJSBridge, 區分瀏覽器環境調用.
- WAService.js
- wx API; APP(), Page(); 頁面具有作用域, 提供模塊化; 數據綁定; 事件分發; 生命周期; 路由;
- 具體架構由兩個webview組成: UI層, Logic層
- UI層運行在第一個webview中, 執行DOM操作和交互事件響應, 里面是WAWebview代碼和編譯后內容
- Logic層運行在獨立的JS引擎: ios: JavaScriptCore, android: x5, 開發工具: nwjs chrome內核
- 邏輯層包括WAService.js代碼和業務
- 兩層之間通過WeixinJSBridge, => ? (native) 之間進行交互
微信小程序架構分析 (上)
- 一個程序有多個view, 也就是多個webview
- 一個小程序只有一個service進程, 也是一個webview, 在程序生命周期內在后台運行
- 兩者都通過WeixinJSBridge和后台通信
- view模塊和service模塊均使用postMessage進行通信
- contentScript.js的代碼提供了message消息到chrome.runtime通信接口的轉換
淺談小程序運行機制
- 使用客戶端提供的JavaScript引擎, 沙箱只是單純的提供JavaScript解釋環境, 沒有瀏覽器任何接口
- 小程序的基礎庫分別注入到視圖層和邏輯層運行
- 視圖層: 提供各類組件來組建界面
- 邏輯層: 提供各種API來處理邏輯
- 處理數據綁定, 組件系統, 事件系統, 通信系統等一系列框架
- 基礎庫不會打包到某個小程序代碼, 會提前內置在微信客戶端
- 基於shadow dom模型
- 啟動機制
- 熱啟動: 打開過小程序, 在一定時間內再次打開
- 冷啟動: 首次打開或者被微信銷毀后打開
- 沒有重啟概念
- 進入后台后, 維持一段時間的運行后被銷毀, 目前是五分鍾.
- 短時間(5s), 連續收到兩次系統內存告警, 會進行小程序銷毀.
- 更新機制
- 冷加載讀取緩存/檢查更新
- 熱加載直接后台切前台
- 冷啟動時發現有新版本, 會異步下載新版本的代碼包, 並同時用客戶端本地的包進行啟動
- 即新版小程序發布后, 需要經歷兩次冷啟動, 才會應用
- 如果需要新版本, 可以使用指定API進行更新
- setData
- webview和jsCore是單獨模塊
- 兩邊都通過evaluateJavaScript實現, 即用戶傳輸的數據.
- 需要將其轉換成一份JS腳本, 通過執行腳本進行執行
小程序更新機制
- 未啟動時更新
- 微信客戶端有若干個時機檢查本地緩存的小程序有沒有新版本, 有靜默升級
- 發布新版本后, 無法同步所有的用戶, 24小時, 同步所有新版本信息到用戶手機
- 下次進行冷啟動時, 先更新最新版本再打開.
- 啟動時更新
- 每次冷啟動都會檢查更新, 異步下載最新的版本的代碼包, 但會用本地的包進行啟動
- 新版本在下一次冷啟動時, 應用.
疑問
- 為什么微信小程序兩個webview, 其中有給logic線程, 是跑在webview中, 怎么沒有window對象?
- 如何在某個操作系統寫引入JS解釋環境呢?
- shadowdom是什么?