前言

小程序是什么？

在小程序誕生前，微信團(tuán)隊(duì)開發(fā)的JS-SDK使web開發(fā)者可以通過暴露的API使用微信原生能力去完成一些事，如調(diào)用接口打開微信支付等。針對(duì)移動(dòng)端設(shè)備網(wǎng)絡(luò)狀態(tài)不穩(wěn)定導(dǎo)致的白屏問題，微信又推出增強(qiáng)版JS-SDK，也就是“微信 Web 資源離線存儲(chǔ)”，但在復(fù)雜的頁面上依然會(huì)出現(xiàn)白屏的問題，原因表現(xiàn)在頁面切換的生硬和點(diǎn)擊的遲滯感。這個(gè)時(shí)候需要一個(gè)JS-SDK處理不了的，使用戶體驗(yàn)更好的一個(gè)系統(tǒng)，即小程序。

小程序是一種全新的連接用戶與服務(wù)的方式，它可以在微信內(nèi)被便捷地獲取和傳播，同時(shí)具有出色的使用體驗(yàn)。

其本質(zhì)是運(yùn)行在webview上的H5應(yīng)用，但與H5又有著本質(zhì)上的不同。H5可以理解為運(yùn)行在移動(dòng)端的web頁面，本質(zhì)還是由HTML+CSS+JS構(gòu)成的web應(yīng)用。小程序和H5的區(qū)別也就是小程序和網(wǎng)頁的區(qū)別。

小程序與普通網(wǎng)頁開發(fā)的區(qū)別

小程序的主要開發(fā)語言是 JavaScript ，小程序的開發(fā)同普通的網(wǎng)頁開發(fā)相比有很大的相似性。對(duì)于前端開發(fā)者而言，從網(wǎng)頁開發(fā)遷移到小程序的開發(fā)成本并不高，但是二者還是有些許區(qū)別的。

• 網(wǎng)頁開發(fā)的渲染和腳本執(zhí)行是在同一個(gè)線程上執(zhí)行的，這也是網(wǎng)頁腳本長(zhǎng)時(shí)間運(yùn)行有可能會(huì)導(dǎo)致頁面失去響應(yīng)的原因；而小程序的視圖層和邏輯層是完全分離在兩個(gè)不同的線程上執(zhí)行
• 開發(fā)網(wǎng)頁時(shí)我們可以在JS代碼中通過Dom API對(duì)節(jié)點(diǎn)進(jìn)行各種操作，通過window對(duì)象實(shí)現(xiàn)原生事件響應(yīng)、頁面跳轉(zhuǎn)；由于小程序的JS代碼運(yùn)行在JSCore,與渲染層分離，所以在邏輯層中無法獲得Dom和Bom，從而無法使用各種Dom API
• 網(wǎng)頁開發(fā)者需要面對(duì)的環(huán)境是各式各樣的瀏覽器，PC 端需要面對(duì) IE、Chrome、QQ瀏覽器等，在移動(dòng)端需要面對(duì)Safari、Chrome以及 iOS、Android 系統(tǒng)中的各式 WebView 。而小程序開發(fā)過程中需要面對(duì)的是兩大操作系統(tǒng) iOS 和 Android 的微信客戶端，以及用于輔助開發(fā)的小程序開發(fā)者工具

小程序架構(gòu)

渲染機(jī)制

處于性能和實(shí)現(xiàn)的考慮，小程序采用 Hybrid渲染機(jī)制 ，這樣做有幾點(diǎn)好處：

• 擴(kuò)展 Web 的能力。比如像輸入框組件（input, textarea）有更好地控制鍵盤的能力
• 體驗(yàn)更好，同時(shí)也減輕 WebView 的渲染工作
• 繞過 setData、數(shù)據(jù)通信和重渲染流程，使渲染性能更好
• 用客戶端原生渲染內(nèi)置一些復(fù)雜組件，可以提供更好的性能

架構(gòu)

如下圖所示，原生小程序框架采用雙線程模型：視圖層和邏輯層完全分離為兩個(gè)不同的線程。每個(gè)頁面的渲染在一個(gè)webview線程上執(zhí)行，視圖層包含多個(gè)webview線程，而邏輯層則統(tǒng)一在JSCore上執(zhí)行。

這樣做的目的是防止邏輯層對(duì)Dom和window的操作（如跳轉(zhuǎn)到外部頁面），使整個(gè)應(yīng)用變得安全可控。

• 邏輯層：創(chuàng)建一個(gè)單獨(dú)的線程去執(zhí)行 JavaScript，在這里執(zhí)行的都是有關(guān)小程序業(yè)務(wù)邏輯的代碼，負(fù)責(zé)邏輯處理、數(shù)據(jù)請(qǐng)求、接口調(diào)用等
• 視圖層：界面渲染相關(guān)的任務(wù)全都在 WebView 線程里執(zhí)行，通過邏輯層代碼去控制渲染哪些界面。一個(gè)小程序存在多個(gè)界面，所以視圖層存在多個(gè) WebView 線程
• JSBridge 起到架起上層開發(fā)與Native（微信系統(tǒng)）的橋梁，使得小程序可通過API使用原生的功能，且部分組件為原生組件實(shí)現(xiàn)，從而有良好體驗(yàn)

視圖層和邏輯層的通信

雙線程模型下，邏輯層代碼無法直接操作Dom，邏輯層和視圖層的數(shù)據(jù)傳輸（setData）是通過兩邊的evaluateJavaScript實(shí)現(xiàn)的。用戶傳輸?shù)臄?shù)據(jù)，需要將其轉(zhuǎn)換為字符串形式傳遞，同時(shí)把轉(zhuǎn)換后的數(shù)據(jù)內(nèi)容拼接成一份 JS 腳本，再通過執(zhí)行 JS 腳本的形式傳遞到兩邊獨(dú)立環(huán)境。

小程序多端同構(gòu)方案

很多企業(yè)都有自己的小程序平臺(tái)，如微信、支付寶、頭條等，如今市面上很多產(chǎn)品都是基于React、Vue等框架開發(fā)的web應(yīng)用，但web端代碼是不可能運(yùn)行在小程序平臺(tái)上的（詳見上述小程序和web應(yīng)用的不同），而開發(fā)幾套代碼的時(shí)間和維護(hù)成本又太高，為了節(jié)省學(xué)習(xí)和開發(fā)成本，各大公司都推出了自己的多端小程序方案，使開發(fā)者可以用React、Vue框架來開發(fā)小程序。類似框架有微信的Kbone、阿里的Remax、京東的Taro等。

Taro是在編譯時(shí)將代碼適配到小程序平臺(tái)，而Kbone和Remax則是在運(yùn)行時(shí)完成這個(gè)工作。

以下重點(diǎn)解釋 Kbone 和 Remax 。

Kbone

參照微信官方文檔，Kbone在適配層里模擬出了瀏覽器環(huán)境，讓 Web 端的代碼可以不做什么改動(dòng)便可運(yùn)行在小程序里。

kbone實(shí)現(xiàn)原理是在worker線程適配了一套JS Dom API，上層不管是哪種前端框架(react、vue)或原生JS最終都需要調(diào)用JS Dom API操作 dom，適配的 JS Dom API則接管了所有的Dom操作，并在內(nèi)存中維護(hù)了一棵Dom tree，所有上層最終調(diào)用的Dom操作都會(huì)更新到這棵Dom tree中，每次操作(有節(jié)流)后會(huì)把Dom tree同步到webview線程中，通過wxml自定義組件進(jìn)行 render。

Remax

與Kbone上層支持多種框架（React、Vue、Angular）不同，Remax專門實(shí)現(xiàn)React應(yīng)用向小程序的適配。

Remax實(shí)現(xiàn)原理是在worker線程維護(hù)一棵虛擬Dom tree,這棵虛擬Dom tree會(huì)通過小程序原生的setData方法映射到render線程，render層再把虛擬Dom tree進(jìn)行遍歷然后渲染。

Remax和kbone類似，都是在 worker 線程維護(hù)一棵Dom tree，再把這棵 Dom tree傳到render線程進(jìn)行渲染，唯一的區(qū)別是remax dom tree發(fā)生變化時(shí)，會(huì)計(jì)算差異，而不需要把整棵樹都傳到render線程，此功能是react提供的，就是在 diff 完后找出差異，則把差異傳到render線程

總結(jié)

• Kbone和Remax實(shí)現(xiàn)原理基本相同，都在worker線程維護(hù)虛擬Dom tree,再把虛擬Dom tree傳到render線程渲染
• 二者主要有兩點(diǎn)不同：Kbone上層支持多種框架，而Remax僅支持React；Remax的Dom tree發(fā)生變化時(shí)會(huì)計(jì)算diff，把diff映射到render線程，而Kbone是將整個(gè)Dom tree傳過去