小程序是基于WEB規范，采用html,
更多技巧請《轉發 + 關注》哦！css和JS等搭建的一套框架，微信官方給它們取了一個非常牛逼的名字：WXML,WXSS，但本質上還是在整個WEB體系之下構建的。
WXML，個人推測在取這個名字的是微信的Xml，說究竟就是xml的一個子集。
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里注冊時填寫路徑即可。
小程序打包
開發完畢后。我們就能夠通過這里可視化的button。點擊直接打包上傳公布，審核通過后用戶就能夠搜索到了。
相關推薦：《微信小程序》
那么打包怎么實現的呢？
這就涉及到這個編輯器的實現原理和方式了。它本身也是基于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
通過WeixinJSCore.invokeHanlder實現，這個WeixinJSCore是微信提供給JS調用的接口（native實現）
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個等。這些都是為了保證更好的體驗。
以上就是小程序開發原理是什么的詳細內容，更多請關注其它相關文章！
