小程式是基於WEB規範，採用HTML,
更多技巧請《轉發 + 關注》哦！CSS和JS等搭建的一套框架，微信官方給它們取了一個非常牛逼的名字：WXML,WXSS，但本質上還是在整個WEB體系之下構建的。
WXML採用微信自己定義的少量標籤WXSS，大家能夠理解為就是自己定義的CSS。實現邏輯部分的JS還是通用的ES規範。而且runtime還是Webview（IOS WKWEBVIEW, ANDROID X5）。
小程式
小程式資料夾結構
一個完整的小程式主要由下面幾部分組成：
一個入口檔案：app.js
一個全域性樣式：app.wxss
一個全域性配置：app.json
頁面：pages下。每一個頁面再按資料夾劃分。每一個頁面4個檔案
檢視：wxml，wxss
邏輯：js。json（頁面配置，不是必須）
注：pages裡面還能夠再依據模組劃分子資料夾，孫子資料夾。僅僅須要在app.json裡註冊時填寫路徑即可。
小程式打包
那麼打包怎麼實現的呢？
這就涉及到這個編輯器的實現原理和方式了。它本身也是基於WEB技術體系實現的，nwjs+react，nwjs是什麼：簡單是說就是node+webkit，node提供給我們本地api能力，而webkit提供給我們web能力，兩者結合就能讓我們使用JS+HTML實現本地應用程式。
既然有nodejs，那上面的打包選項裡的功能就好實現了。
ES6轉ES5：引入babel-core的node包
CSS補全：引入postcss和autoprefixer的node包（postcss和autoprefixer的原理看這裡）
程式碼壓縮：引入uglifyjs的node包
注：在android上使用的x5核心。對ES6的支援不好。要相容的話，要麼使用ES5的語法或者引入babel-polyfill相容庫。
打包後的資料夾結構
小程式打包後的結構例如以下：
全部的小程式基本都最後都被打成上面的結構
1、WAService.js 框架JS庫。提供邏輯層基礎的API能力
2、WAWebview.js 框架JS庫，提供檢視層基礎的API能力
3、WAConsole.js 框架JS庫。控制檯
4、app-config.js 小程式完整的配置。包括我們通過app.json裡的全部配置，綜合了預設配置型
5、app-service.js 我們自己的JS程式碼，全部打包到這個檔案
6、page-frame.html 小程式檢視的模板檔案，全部的頁面都使用此載入渲染。且全部的WXML都拆解為JS實現打包到這裡
7、pages 全部的頁面。這個不是我們之前的wxml檔案了，主要是處理WXSS轉換，使用js插入到header區域。
小程式架構
微信小程式的框架包括兩部分View檢視層、App Service邏輯層。View層用來渲染頁面結構，AppService層用來邏輯處理、資料請求、介面呼叫。它們在兩個程序（兩個Webview）裡執行。
檢視層和邏輯層通過系統層的JSBridage進行通訊，邏輯層把資料變化通知到檢視層，觸發檢視層頁面更新，檢視層把觸發的事件通知到邏輯層進行業務處理。
小程式架構圖：
小程式啟動時會從CDN下載小程式的完整包。通常是數字命名的,如：_-2082693788_4.wxapkg
小程式技術實現
小程式的UI檢視和邏輯處理是用多個webview實現的，邏輯處理的JS程式碼全部載入到一個Webview裡面，稱之為AppService，整個小程式僅僅有一個。而且整個生命週期常駐記憶體，而全部的檢視（wxml和wxss）都是單獨的Webview來承載，稱之為AppView。所以一個小程式開啟至少就會有2個webview程序，正式由於每一個檢視都是一個獨立的webview程序，考慮到效能消耗，小程式不同意開啟超過5個層級的頁面，當然同是也是為了體驗更好。
AppService
能夠理解AppService即一個簡單的頁面，主要功能是負責邏輯處理部分的執行，底層提供一個WAService.js的檔案來提供各種api介面，主要是下面幾個部分：
訊息通訊封裝為WeixinJSBridge（開發環境為window.postMessage, IOS下為WKWebview的window.webkit.messageHandlers.invokeHandler.postMessage。android下用WeixinJSCore.invokeHandler）
1、日誌元件Reporter封裝
2、wx物件下面的api方法
3、全域性的App,Page,getApp,getCurrentPages等全域性方法
4、還有就是對AMD模組規範的實現
然後整個頁面就是載入一堆JS檔案，包括小程式配置config，上面的WAService.js（除錯模式下有asdebug.js）。剩下就是我們自己寫的全部的js檔案，一次性都載入。
在開發環境下
1、頁面模板：app.nw/app/dist/weapp/tpl/appserviceTpl.js
2、配置資訊，是直接寫入一個js變數。__wxConfig。
3，其它配置
線上環境
而在上線後是應用部分會打包為2個檔案，名稱app-config.json和app-service.js，然後微信會開啟webview去載入。線上部分應該是微信自身提供了對應的模板檔案，在壓縮包裡沒有找到。
1、WAService.js（底層支援）
2、app-config.json（應用配置）
3、app-service.js（應用邏輯）
然後執行在JavaScriptCore引擎裡面。
AppView
這裡能夠理解為h5的頁面。提供UI渲染，底層提供一個WAWebview.js來提供底層的功能,詳細例如以下：
1、訊息通訊封裝為WeixinJSBridge（開發環境為window.postMessage, IOS下為WKWebview的window.webkit.messageHandlers.invokeHandler.postMessage。android下用WeixinJSCore.invokeHandler）
2、日誌元件Reporter封裝
3、wx物件下的api。這裡的api跟WAService裡的還不太一樣，有幾個跟那邊功能差點兒相同，可是大部分都是處理UI顯示相關的方法
4、小程式元件實現和註冊
5、VirtualDOM，Diff和Render UI實現
6、頁面事件觸發
在此基礎上，AppView有一個html模板檔案，通過這個模板檔案載入詳細的頁面。這個模板主要就一個方法，$gwx，主要是返回指定page的VirtualDOM，而在打包的時候，會事先把全部頁面的WXML轉換為ViirtualDOM放到模板檔案中，而微信自己寫了2個工具wcc（把WXML轉換為VirtualDOM）和wcsc（把WXSS轉換為一個JS字串的形式通過style標籤append到header裡）。
Service和View通訊
使用訊息publish和subscribe機制實現兩個Webview之間的通訊，實現方式就是統一封裝一個WeixinJSBridge物件。而不同的環境封裝的介面不一樣。詳細實現的技術例如以下：
windows環境
通過window.postMessage實現（使用chrome擴充套件的介面注入一個contentScript.js。它封裝了postMessage方法，實現webview之間的通訊。而且也它通過chrome.runtime.connect方式，也提供了直接操作chrome native原生方法的介面）
傳送訊息：window.postMessage(data, ‘*’);。// data裡指定 webviewID
接收訊息：window.addEventListener(‘message’, messageHandler); // 訊息處理並分發，相同支援呼叫nwjs的原生能力。
在contentScript裡面看到一句話。證實了appservice也是通過一個webview實現的，實現原理上跟view一樣，僅僅是處理的業務邏輯不一樣。
'webframe' === b ? postMessageToWebPage(a) : 'appservice' === b && postMessageToWebPage(a)
IOS
通過 WKWebview的window.webkit.messageHandlers.NAME.postMessage實現微信navite程式碼裡實現了兩個handler訊息處理器：
invokeHandler: 呼叫原生能力
publishHandler: 訊息分發
Android
invokeHandler: 呼叫原生能力
publishHandler: 訊息分發
在WAWebview.js裡有個物件叫exparser。它完整的實現小程式裡的元件，看詳細的實現方式，思路上跟w3c的web components規範神似，可是詳細實現上是不一樣的，我們使用的全部元件，都會被提前註冊好，在Webview裡渲染的時候進行替換組裝。
exparser有個核心方法：
regiisterBehavior: 註冊組件的一些基礎行為，供元件繼承
registerElement：註冊組件，跟我們互動介面主要是屬性和事件
元件觸發事件（帶上webviewID），呼叫WeixinJSBridge的介面，publish到native。然後native再分發到AppService層指定webviewID的Page註冊事件處理方法。
總結
小程式底層還是基於Webview來實現的。並沒有發明創造新技術，整個框架體系。比較清晰和簡單，基於Web規範，保證現有技能價值的最大化，僅僅需了解框架規範即可使用已有Web技術進行開發。易於理解和開發。
MSSM：對邏輯和UI進行了全然隔離，這個跟當前流行的react，agular，vue有本質的差別，小程式邏輯和UI全然執行在2個獨立的Webview裡面，而後面這幾個框架還是執行在一個webview裡面的，假設你想。還是能夠直接操作dom物件，進行ui渲染的。
元件機制：引入元件化機制，可是不全然基於元件開發。跟vue一樣大部分UI還是模板化渲染，引入元件機制能更好的規範開發模式，也更方便升級和維護。
多種剋制：不能同一時候開啟超過5個窗體。打包檔案不能大於1M，dom物件不能大於16000個等。這些都是為了保證更好的體驗。
以上就是小程式開發原理是什麼的詳細內容，更多請關注其它相關文章！