小程序是基于WEB規(guī)范，采用html,
更多技巧請《轉(zhuǎn)發(fā) + 關(guān)注》哦！css和JS等搭建的一套框架，微信官方給它們?nèi)×艘粋€非常牛逼的名字：WXML,WXSS，但本質(zhì)上還是在整個WEB體系之下構(gòu)建的。
WXML，個人推測在取這個名字的是微信的Xml，說究竟就是xml的一個子集。
WXML采用微信自己定義的少量標簽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補全：引入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里的全部配置，綜合了默認配置型
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)用。它們在兩個進程（兩個Webview）里執(zhí)行。
視圖層和邏輯層通過系統(tǒng)層的JSBridage進行通信，邏輯層把數(shù)據(jù)變化通知到視圖層，觸發(fā)視圖層頁面更新，視圖層把觸發(fā)的事件通知到邏輯層進行業(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進程，正式由于每一個視圖都是一個獨立的webview進程，考慮到性能消耗，小程序不同意打開超過5個層級的頁面，當然同是也是為了體驗更好。
AppService
能夠理解AppService即一個簡單的頁面，主要功能是負責邏輯處理部分的執(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
這里能夠理解為h5的頁面。提供UI渲染，底層提供一個WAWebview.js來提供底層的功能,詳細例如以下：
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模板文件，通過這個模板文件載入詳細的頁面。這個模板主要就一個方法，$gwx，主要是返回指定page的VirtualDOM，而在打包的時候，會事先把全部頁面的WXML轉(zhuǎn)換為ViirtualDOM放到模板文件中，而微信自己寫了2個工具wcc（把WXML轉(zhuǎn)換為VirtualDOM）和wcsc（把WXSS轉(zhuǎn)換為一個JS字符串的形式通過style標簽append到header里）。
Service和View通信
使用消息publish和subscribe機制實現(xiàn)兩個Webview之間的通信，實現(xiàn)方式就是統(tǒng)一封裝一個WeixinJSBridge對象。而不同的環(huán)境封裝的接口不一樣。詳細實現(xiàn)的技術(shù)例如以下：
windows環(huán)境
通過window.postMessage實現(xiàn)（使用chrome擴展的接口注入一個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)小程序里的組件，看詳細的實現(xiàn)方式，思路上跟w3c的web components規(guī)范神似，可是詳細實現(xiàn)上是不一樣的，我們使用的全部組件，都會被提前注冊好，在Webview里渲染的時候進行替換組裝。
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ù)進行開發(fā)。易于理解和開發(fā)。
MSSM：對邏輯和UI進行了全然隔離，這個跟當前流行的react，agular，vue有本質(zhì)的差別，小程序邏輯和UI全然執(zhí)行在2個獨立的Webview里面，而后面這幾個框架還是執(zhí)行在一個webview里面的，假設(shè)你想。還是能夠直接操作dom對象，進行ui渲染的。
組件機制：引入組件化機制，可是不全然基于組件開發(fā)。跟vue一樣大部分UI還是模板化渲染，引入組件機制能更好的規(guī)范開發(fā)模式，也更方便升級和維護。
多種克制：不能同一時候打開超過5個窗體。打包文件不能大于1M，dom對象不能大于16000個等。這些都是為了保證更好的體驗。
以上就是小程序開發(fā)原理是什么的詳細內(nèi)容，更多請關(guān)注其它相關(guān)文章！
