小程序的開發(fā)原理

這篇文章主要介紹小程序的開發(fā)原理，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

小程序是基于WEB規(guī)范，采用HTML,CSS和JS等搭建的一套框架，微信官方給它們?nèi)×艘粋€非常牛逼的名字：WXML,WXSS，但本質(zhì)上還是在整個WEB體系之下構(gòu)建的。

WXML，個人推測在取這個名字的是微信的Xml，說究竟就是xml的一個子集。

WXML采用微信自己定義的少量標(biāo)簽WXSS，大家能夠理解為就是自己定義的CSS。實現(xiàn)邏輯部分的JS還是通用的ES規(guī)范。而且runtime還是Webview（IOS WKWEBVIEW, ANDROID X5）。

小程序

小程序文件夾結(jié)構(gòu)

一個完整的小程序主要由下面幾部分組成：

一個入口文件：app.js

一個全局樣式：app.wxss

一個全局配置：app.json

頁面：pages下。每一個頁面再按文件夾劃分。每一個頁面4個文件

視圖：wxml，wxss

邏輯：js。json（頁面配置，不是必須）

注：pages里面還能夠再依據(jù)模塊劃分子文件夾，孫子文件夾。僅僅須要在app.json里注冊時填寫路徑即可。

小程序打包

開發(fā)完畢后。我們就能夠通過這里可視化的button。點擊直接打包上傳公布，審核通過后用戶就能夠搜索到了。

相關(guān)

那么打包怎么實現(xiàn)的呢？

這就涉及到這個編輯器的實現(xiàn)原理和方式了。它本身也是基于WEB技術(shù)體系實現(xiàn)的，nwjs+react，nwjs是什么：簡單是說就是node+webkit，node提供給我們本地api能力，而webkit提供給我們web能力，兩者結(jié)合就能讓我們使用JS+HTML實現(xiàn)本地應(yīng)用程序。

既然有nodejs，那上面的打包選項里的功能就好實現(xiàn)了。

ES6轉(zhuǎn)ES5：引入babel-core的node包

CSS補(bǔ)全：引入postcss和autoprefixer的node包（postcss和autoprefixer的原理看這里）

代碼壓縮：引入uglifyjs的node包

注：在android上使用的x5內(nèi)核。對ES6的支持不好。要兼容的話，要么使用ES5的語法或者引入babel-polyfill兼容庫。

打包后的文件夾結(jié)構(gòu)

小程序打包后的結(jié)構(gòu)例如以下：

全部的小程序基本都最后都被打成上面的結(jié)構(gòu)

1、WAService.js 框架JS庫。提供邏輯層基礎(chǔ)的API能力

2、WAWebview.js 框架JS庫，提供視圖層基礎(chǔ)的API能力

3、WAConsole.js 框架JS庫。控制臺

4、app-config.js 小程序完整的配置。包括我們通過app.json里的全部配置，綜合了默認(rèn)配置型

5、app-service.js 我們自己的JS代碼，全部打包到這個文件

6、page-frame.html 小程序視圖的模板文件，全部的頁面都使用此載入渲染。且全部的WXML都拆解為JS實現(xiàn)打包到這里

7、pages 全部的頁面。這個不是我們之前的wxml文件了，主要是處理WXSS轉(zhuǎn)換，使用js插入到header區(qū)域。

小程序架構(gòu)

微信小程序的框架包括兩部分View視圖層、App Service邏輯層。View層用來渲染頁面結(jié)構(gòu)，AppService層用來邏輯處理、數(shù)據(jù)請求、接口調(diào)用。它們在兩個進(jìn)程（兩個Webview）里執(zhí)行。

視圖層和邏輯層通過系統(tǒng)層的JSBridage進(jìn)行通信，邏輯層把數(shù)據(jù)變化通知到視圖層，觸發(fā)視圖層頁面更新，視圖層把觸發(fā)的事件通知到邏輯層進(jìn)行業(yè)務(wù)處理。

小程序架構(gòu)圖：

小程序啟動時會從CDN下載小程序的完整包。通常是數(shù)字命名的,如：_-2082693788_4.wxapkg

小程序技術(shù)實現(xiàn)

小程序的UI視圖和邏輯處理是用多個webview實現(xiàn)的，邏輯處理的JS代碼全部載入到一個Webview里面，稱之為AppService，整個小程序僅僅有一個。而且整個生命周期常駐內(nèi)存，而全部的視圖（wxml和wxss）都是單獨的Webview來承載，稱之為AppView。所以一個小程序打開至少就會有2個webview進(jìn)程，正式由于每一個視圖都是一個獨立的webview進(jìn)程，考慮到性能消耗，小程序不同意打開超過5個層級的頁面，當(dāng)然同是也是為了體驗更好。

AppService

能夠理解AppService即一個簡單的頁面，主要功能是負(fù)責(zé)邏輯處理部分的執(zhí)行，底層提供一個WAService.js的文件來提供各種api接口，主要是下面幾個部分：

消息通信封裝為WeixinJSBridge（開發(fā)環(huán)境為window.postMessage, IOS下為WKWebview的window.webkit.messageHandlers.invokeHandler.postMessage。android下用WeixinJSCore.invokeHandler）

1、日志組件Reporter封裝

2、wx對象下面的api方法

3、全局的App,Page,getApp,getCurrentPages等全局方法

4、還有就是對AMD模塊規(guī)范的實現(xiàn)

然后整個頁面就是載入一堆JS文件，包括小程序配置config，上面的WAService.js（調(diào)試模式下有asdebug.js）。剩下就是我們自己寫的全部的js文件，一次性都載入。

在開發(fā)環(huán)境下

1、頁面模板：app.nw/app/dist/weapp/tpl/appserviceTpl.js

2、配置信息，是直接寫入一個js變量。__wxConfig。

3，其它配置

線上環(huán)境

而在上線后是應(yīng)用部分會打包為2個文件，名稱app-config.json和app-service.js，然后微信會打開webview去載入。線上部分應(yīng)該是微信自身提供了對應(yīng)的模板文件，在壓縮包里沒有找到。

1、WAService.js（底層支持）

2、app-config.json（應(yīng)用配置）

3、app-service.js（應(yīng)用邏輯）

然后執(zhí)行在JavaScriptCore引擎里面。

AppView

這里能夠理解為h6的頁面。提供UI渲染，底層提供一個WAWebview.js來提供底層的功能,詳細(xì)例如以下：

1、消息通信封裝為WeixinJSBridge（開發(fā)環(huán)境為window.postMessage, IOS下為WKWebview的window.webkit.messageHandlers.invokeHandler.postMessage。android下用WeixinJSCore.invokeHandler）

2、日志組件Reporter封裝

3、wx對象下的api。這里的api跟WAService里的還不太一樣，有幾個跟那邊功能差點兒相同，可是大部分都是處理UI顯示相關(guān)的方法

4、小程序組件實現(xiàn)和注冊

5、VirtualDOM，Diff和Render UI實現(xiàn)

6、頁面事件觸發(fā)

在此基礎(chǔ)上，AppView有一個html模板文件，通過這個模板文件載入詳細(xì)的頁面。這個模板主要就一個方法，$gwx，主要是返回指定page的VirtualDOM，而在打包的時候，會事先把全部頁面的WXML轉(zhuǎn)換為ViirtualDOM放到模板文件中，而微信自己寫了2個工具wcc（把WXML轉(zhuǎn)換為VirtualDOM）和wcsc（把WXSS轉(zhuǎn)換為一個JS字符串的形式通過style標(biāo)簽append到header里）。

Service和View通信

使用消息publish和subscribe機(jī)制實現(xiàn)兩個Webview之間的通信，實現(xiàn)方式就是統(tǒng)一封裝一個WeixinJSBridge對象。而不同的環(huán)境封裝的接口不一樣。詳細(xì)實現(xiàn)的技術(shù)例如以下：

windows環(huán)境

通過window.postMessage實現(xiàn)（使用chrome擴(kuò)展的接口注入一個contentScript.js。它封裝了postMessage方法，實現(xiàn)webview之間的通信。而且也它通過chrome.runtime.connect方式，也提供了直接操作chrome native原生方法的接口）

發(fā)送消息：window.postMessage(data, ‘*’);。// data里指定 webviewID

接收消息：window.addEventListener(‘message’, messageHandler); // 消息處理并分發(fā)，相同支持調(diào)用nwjs的原生能力。

在contentScript里面看到一句話。證實了appservice也是通過一個webview實現(xiàn)的，實現(xiàn)原理上跟view一樣，僅僅是處理的業(yè)務(wù)邏輯不一樣。

'webframe' === b ? postMessageToWebPage(a) : 'appservice' === b && postMessageToWebPage(a)

IOS

通過 WKWebview的window.webkit.messageHandlers.NAME.postMessage實現(xiàn)微信navite代碼里實現(xiàn)了兩個handler消息處理器：

invokeHandler: 調(diào)用原生能力

publishHandler: 消息分發(fā)

Android

通過WeixinJSCore.invokeHanlder實現(xiàn)，這個WeixinJSCore是微信提供給JS調(diào)用的接口（native實現(xiàn)）

invokeHandler: 調(diào)用原生能力

publishHandler: 消息分發(fā)

微信組件

在WAWebview.js里有個對象叫exparser。它完整的實現(xiàn)小程序里的組件，看詳細(xì)的實現(xiàn)方式，思路上跟w3c的web components規(guī)范神似，可是詳細(xì)實現(xiàn)上是不一樣的，我們使用的全部組件，都會被提前注冊好，在Webview里渲染的時候進(jìn)行替換組裝。

exparser有個核心方法：

regiisterBehavior: 注冊組件的一些基礎(chǔ)行為，供組件繼承

registerElement：注冊組件，跟我們交互接口主要是屬性和事件

組件觸發(fā)事件（帶上webviewID），調(diào)用WeixinJSBridge的接口，publish到native。然后native再分發(fā)到AppService層指定webviewID的Page注冊事件處理方法。

總結(jié)

小程序底層還是基于Webview來實現(xiàn)的。并沒有發(fā)明創(chuàng)造新技術(shù)，整個框架體系。比較清晰和簡單，基于Web規(guī)范，保證現(xiàn)有技能價值的最大化，僅僅需了解框架規(guī)范即可使用已有Web技術(shù)進(jìn)行開發(fā)。易于理解和開發(fā)。

MSSM：對邏輯和UI進(jìn)行了全然隔離，這個跟當(dāng)前流行的react，agular，vue有本質(zhì)的差別，小程序邏輯和UI全然執(zhí)行在2個獨立的Webview里面，而后面這幾個框架還是執(zhí)行在一個webview里面的，假設(shè)你想。還是能夠直接操作dom對象，進(jìn)行ui渲染的。

組件機(jī)制：引入組件化機(jī)制，可是不全然基于組件開發(fā)。跟vue一樣大部分UI還是模板化渲染，引入組件機(jī)制能更好的規(guī)范開發(fā)模式，也更方便升級和維護(hù)。

多種克制：不能同一時候打開超過5個窗體。打包文件不能大于1M，dom對象不能大于16000個等。這些都是為了保證更好的體驗。

以上是“小程序的開發(fā)原理”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！