使用微信小程序開發已經很長時間了，對小程序開發已經相當熟練了；但是作為一名對技術有追求的前端開發，僅僅熟練掌握小程序的開發感覺還是不夠的，我們應該更進一步的去理解其背后實現的原理以及對應的考量，這可能會解釋我們在開發過程中遇到的一些疑惑，比如為啥小程序不能操作dom、小程序是web技術渲染還是native技術渲染等等，另一方面對於我們個人成長也是有幫助的。
首先聲明下，文章查看小程序開發者工具源碼的方法僅限學習使用。
本文將從以下幾個方面來說一下小程序的實現原理
如何查看小程序開發者工具源碼
下面我們通過微信小程序開發者工具的源碼來說說小程序的底層實現原理。以開發者工具版本號State v1.02.1904090的源碼來窺探小程序的實現思路。如何查看微信源碼，對於mac用戶而言，查看微信小程序開發者工具的包內容，然后進入Contents/Resources/app.nw/js/core/index.js，注釋掉如下代碼就可以查看開發者工具渲染后的代碼。
// 打開 inspect 窗口
if (nw.App.argv.indexOf('inspect') !== -1) {
tools.openInspectWin()
}
然后重啟小程序開發者工具，就出現如下左側頁面，點擊其中一個頁面就能看到view層的dom結構，如下圖右側。
|
小程序架構設計
小程序的架構設計與web技術還是有一定的差別，其吸取了web技術的一些優勢，同時也摒棄web技術中體驗等不好的地方。下面通過問題的形式來說說小程序架構中的一些設計點。
1、小程序渲染是在同一個線程嗎？雙線程機制
開發過小程序的都知道，小程序是雙線程設計，即視圖渲染與業務邏輯分別在運行在不同的線程中。這個設計主要是解決web技術中的一個痛點：
web頁面開發渲染線程和腳本線程是互斥的，長時間的腳本運行可能會導致頁面失去響應或者白屏，體驗糟糕。
小程序為了更好體驗，將頁面的渲染線程和腳本線程分開設計在不同線程中執行，具體實現：
- 視圖view層在webview中渲染，一個頁面對應一個webview
- 業務邏輯Appservice層運行在同一個JSCore線程中，具體ios是JavaScriptCore，android是X5 JSCore，開發者工具是webview中；
這樣解決了長時間的腳本阻塞頁面渲染的情況，但是也帶來一些新的問題：
- 天生的延遲，線程間要通信
- 業務邏輯層因為運行在JSCore中無法訪問DOM和BOM的api；
開發者工具使用webview加載業務邏輯層的代碼，雖然依賴的環境有DOM和BOM api，為了保持一致；小程序對所有的模塊進行了局部化處理使其不能訪問這些api。這樣雙線程通過native，開發者工具通過后台websocket服務充當二者消息中轉媒介，並且提供一些基礎功能。具體可以參考官網圖：
2、小程序是web渲染嗎？界面渲染機制
頁面渲染的方式主要有三種：
- 純web渲染
- 純native原生渲染
- Hybrid渲染，即web和native渲染結合
因為小程序的宿主環境是微信，不太可能使用純native渲染，否則所有小程序需要跟微信一起編碼發版。采用純web渲染貌似是可行的，支持快速在線更新，通過加裝最新資源到本地即可渲染；但是純web渲染在一些有復雜交互的頁面上可能會面臨一些性能問題，這是因為在web技術中，UI渲染跟 JavaScript 的腳本執行都在一個單線程中執行，這就容易導致一些邏輯任務搶占UI渲染的資源。所以小程序采用Hybrid方式渲染，用官網的描述如下：
界面主要由成熟的 Web 技術渲染，輔之以大量的接口提供豐富的客戶端原生能力。同時，每個小程序頁面都是用不同的WebView去渲染，這樣可以提供更好的交互體驗，更貼近原生體驗，也避免了單個WebView的任務過於繁重。
既然采用Hybrid方式渲染，那么頁面的渲染可能會用到原生native來渲染，什么情況會用到原生渲染呢？
答案是使用到小程序提供的map、video、canvas、textarea等組件，頁面中原生渲染的渲染原理可以參考官網原生組件。但是在小程序開發者工具中原生組件是使用html標簽來模擬實現的。具體可以看下一節的map組件渲染結果。
3、小程序是用web的html標簽渲染嗎？Exparser組件框架
上面說到小程序主要由成熟的web技術渲染，能否直接使用html提供的標簽如div、table等組織頁面呢，答案不可以。主要考量：
- 管控與安全：web技術可以通過腳本獲取修改頁面敏感內容或者隨意跳轉其它頁面
- 能力有限，會限制小程序的表現形式
- 標簽眾多，增加理解成本
所以，小程序不能直接使用html標簽渲染頁面，其提供了10多個內置組件來收斂web標簽，並且提供一個JavaScript沙箱環境來避免js訪問任何瀏覽器api。
既然小程序不能直接使用html標簽來渲染頁面，那它提供的如view、cover-view等內置組件是否意味着最終都轉換為html提供的內置標簽來渲染呢？答案當不是。我們來看如下代碼:
<view class="map-container">
<map latitude='39.9088230000' style="height: 100%; width:100%;" longitude='116.3974700000' scale='16' id="id" bindregionchange="onRegionChange"></map>
<view catchtap="onTap">test</view>
</view>
上面代碼在開發者工具中最終渲染元素如下圖：
可以看出，小程序提供的組件並沒有最終轉換為為html對應的標簽來渲染，而是使用自定義的元素來渲染。這些內置組件都是由Exparser框架負責管理，它內置在小程序基礎庫中，為小程序的各種組件提供基礎的支持。
Exparser框架基於Shadow DOM模型，模型上與WebComponents的ShadowDOM高度相似，具體可以參考官網組件系統。
內置組件的命名規范都是以wx-開頭的，外部引用內置組件如view，最終會調用底層的wx-view組件；Exparser的view組件創建方式如下：
4、小程序可以操作dom嗎？數據驅動
小程序為了管控與安全，提供一個JavaScript沙箱環境來運行JavaScript代碼，js代碼不能訪問任何瀏覽器相關的接口，那就意味着js是不能操作dom和bom的，否則可能報錯。小程序實現沙箱環境呢？即通過將業務邏輯封裝到一個局部環境中，局部環境修改dom和bom的相關api指向。具體封裝形式如下：
那么問題來了，小程序是怎么給業務代碼加上以上封裝的呢？其實很簡單，在小程序開發者工具中有一個后台服務，訪問小程序的每個模塊的path時，后台服務會調用wrapSourceCodeInDefine方法將請求的JS文件的內容分別包裹在define域中，方法的代碼如下圖所示：
這里的define是小程序底層實現模塊化的方法之一，還有一個是require方法；通過define來定義一個模塊，require來引用一個define定義的模塊。從上面小程序對業務模塊代碼的封裝可以看出：
-
define定義的模塊對傳遞了跟瀏覽器相關的接口同名的API，如window、document、localStroage等等
可能有人會說通過Function('return this')()來訪問全局作用域window對象，但是小程序堵死了這條路，重寫了Function，eval重置為undefined。例如下圖：
-
require在引用模塊時只傳遞require、module、exports三個參數，那么其他參數值就為undefined，不能在業務代碼中訪問這些接口
可以看看require定義的源碼：
在實際的微信環境，業務邏輯層運行在JSCore中，其沒有瀏覽器相關的信息，訪問dom無從談起；但是小程序開發者工具使用webview來運行業務邏輯代碼，它有dom相關接口；所以通過上面沙箱環境來統一使js無法操作dom。
業務代碼無法訪問dom，怎么實現頁面動態更新呢？
答案就是采用類vue這種MVVM框架的數據驅動思想，即讓視圖狀態和視圖綁定在一起，狀態變更時，視圖也能自動變更，這樣就不用直接操作dom。
視圖的動態更新具體是采用virtual dom技術實現，virtual DOM相信大家都已有了解，大概是這么個過程如下圖：
實際處理可以簡單描述如下：
用JS對象模擬DOM樹 -> 比較兩棵虛擬DOM樹的差異 -> 把差異應用到真正的DOM樹上。
其中，virtual dom是通過內置的wcc可以將wxml轉換為js對象形式，以此來表示DOM樹結構。
下面以官網的一幅圖來說視圖動態更新的過程：
// wxml
<view>{{msg}}</view>
// js
data: {
msg: 'Hello World'
}
上面說明了視圖如何更新的，其實在數據響應的過程中，還有最重要的一環，即業務邏輯層的如何將變化的數據同步到視圖層呢，這就涉及到雙線程的通信了，具體可以參考從微信小程序開發者工具源碼看實現原理（三）- - 雙線程通信。
5、小程序基礎庫作用到底是什么？
我們在開發者工具開發小程序時，一般都會選擇一個基礎庫，如小程序開發者工具選擇界面：
小程序基礎庫是用JavaScript寫的，但是我們並沒有在我們的小程序中直接引用，那么我們是怎么使用基礎庫提供功能的呢？答案是：
微信宿主環境會提前內置基礎庫，打開小程序時會自動將基礎庫注入到小程序的視圖層和業務邏輯層中，小程序開發者工具則是由底層HTTP服務負責注入。
下圖是小程序底層HTTP服務通過script腳本注入的相關代碼：
小程序基礎庫功能包括兩個部分視圖層的WAWebview.js和業務邏輯層的WAService.js。下面就簡單說下對應功能：
WAService為業務邏輯層提供基礎功能
下看看一下WAService.js源碼內容縮略圖：
從源碼可以看出基礎庫提供的WAService.js有很多功能，主要包括以下幾部分
- WeixinJSBridge：消息通信的統一封裝易於調用，主要微信環境與native，開發環境與開發者工具后台服務的通信。
- wx: wx對象下面的api方法封裝
- appServiceEngine：定義了全局的方法如define，require, App，Page，Component，getApp，getCurrentPages等
- virtualDOM: VirtualDOM，Diff和Render UI實現
- expraser: expraser框架組件的方法定義，這意味着邏輯層也具有一定的組件樹組織能力。
- Reporter: 小程序日志組件
WAWebview為視圖層提供基礎功能
小程序基礎庫為視圖層提供的基礎功能有些與WAService相同，主要功能如下：
- 消息通信封裝為WeixinJSBridge
- 日志組件Reporter封裝
- wx對象下的api，跟WAService里的不同的是其大部分都是處理UI顯示相關的方法
- 小程序Expraser組件框架的實現和內置組件的注冊
- VirtualDOM，Diff和Render UI實現
- 定義頁面相關事件觸發