用js調用android和ios底層功能，用html5展示界面。性能比不上原生app

瞎猜的：用Native抹平了系統間的差異，搞套DSL把系統的API暴露給前端開發。可以理解為沒有編譯過程的React Native/Weex，有WebAPP的靈活性，又有接近Native的性能。

根據小程序開發文檔-框架(https://mp.weixin.qq.com/debug/wxadoc/dev/framework/MINA.html)部分，可以從微信小程序提供的開發接口上看出：1. 提供了JavsScript運行環境，由JavaScript編寫的業務代碼完成邏輯層的處理2. 通過數據傳輸接口（注冊Page時的data屬性及后續的setData方法調用）將邏輯層的數據傳輸給視圖層3. 視圖層由WXML語言編寫的模板通過“數據綁定”與邏輯層傳輸過來的數據merge成展現結果并展現4. 視圖的樣式控制由WXSS語言編寫的樣式規則進行配置再分別來看這4點各自的細節問題：1. 提供了JavsScript運行環境，由JavaScript編寫的業務代碼完成邏輯層的處理JavaScript運行環境是什么？開發文檔Q&A(https://mp.weixin.qq.com/debug/wxadoc/dev/qa/qa.html)中這句已給出，JS運行環境是在JsCore里：為什么腳本內不能使用window等對象頁面的腳本邏輯在是在JsCore中運行2. 通過數據傳輸接口（注冊Page時的data屬性及后續的setData方法調用）將邏輯層的數據傳輸給視圖層數據在邏輯層與視圖層間如何傳輸？視圖為純native渲染，故位于native端。而邏輯層如上所述，是跑在JsCore中的JavaScript代碼。有了JsCore，微信小程序框架的native端與js端就可以通過JsCore來相互通信了。于是，微信小程序框架的native端與js端可以約定好通信協議/規范，再把js端通過此通信協議/規范與native通信的部分封裝并暴露接口為API（最上層的傳輸或說設置數據的API也就是上面說的注冊Page時的data屬性與后續的setData方法），這樣邏輯層的業務代碼就可以實現向視圖層傳輸數據了。（對native其他API的調用也用類似的方法即能走通）3. 視圖層由WXML語言編寫的模板通過“數據綁定”與邏輯層傳輸過來的數據merge成展現結果并展現視圖層與數據如何merge為展現結果并展現？首先看WXML語言提供的接口，發現它：類似于html/xml，用標簽方式來描述視圖類似angular/vue，通過指令(標簽的特殊屬性)與雙大括號來實現模板的增強功能，使模板與數據merge為結果標簽但細看發現，指令其實很簡單，只提供了用于循環列表的wx:for指令，與用于控制邏輯的wx:if,wx:else,wx:elif指令雙大括號內支持簡單的表達式，表達式中的變量即邏輯層輸入的數據每次邏輯層更新數據，視圖層會相應更新merge并更新渲染考慮最簡單的情況，要完成這3個功能，大致可以通過做如下事來完成：native端讀取WXML模板文件，再根據邏輯層傳來的數據將其中的指令與雙大括號處理解析(可根據大括號表達式從數據中取值并計算，再以對表達式值進行循環與判斷便可相應解除wx:for,wx:if指令)，生成與數據merge后、可以表征最終展現內容的標簽串，再以解析xml的方式解析標簽為帶有屬性的節點樹，并對應節點樹中各節點相應創建native中的視圖元素(可能為系統組件、也可能為微信框架中的視圖組件)、設置相應屬性、維護為正確的父子關系即可。邏輯層數據更新時，也更新相應屬性即可。當然實際處理中，要考慮的因素要多許多，也會做許多優化，但基本思路應大致如此。4. 視圖的樣式控制由WXSS語言編寫的樣式規則進行配置樣式如何匹配與設置？構建出各視圖元素后，仍由native讀取WXSS文件，用簡單字符串匹配即可將其解析為一對一對的"選擇器-規則"對，規則內即為屬性鍵值。之后再對各視圖元素與"選擇器-規則"對中的選擇器進行匹配，匹配成功設置相應屬性值（還要考慮全局樣式與頁面樣式及style屬性樣式中的優先級）即可如何使用css樣式對native元素進行布局？最基本的flex布局可以由facebook的css-layout來完成(GitHub - facebook/css-layout: A subset of CSS (specifically flex-box) re-implemented as a stand alone project for use primarily on mobile. Used by react-native)另外，事件方面，native接收到用戶事件后，必要時通過JsCore反向與其內運行的js進行通信，將事件數據傳遞給js端的框架，再由js端框架調起相應回調即可。另有一些細節可參見：微信小程序開發API調研 - 呂晟的文章 - 知乎專欄歡迎討論，望輕拍 : )

通過網頁代碼調用原生的api/控件，然后一堆限制，始終不理解為什么這些程序員不自己寫個移動網站，非要鉆微信的籠子，沒有性格沒有下限。

作者：phodal鏈接：http://zhuanlan.zhihu.com/p/22607204來源：知乎著作權歸作者所有，轉載請聯系作者獲得授權。本來想的是昨天晚上寫這篇文章的，后來昨天在寫一個Cordova上的iOS插件的時候各種不順。對接的第三方SDK不給力，于是六點多回到家的時候，我就就開始娛樂了，哈哈哈~~其實這篇文章應該算是一篇拾遺。從map組件說起在今天公布的開發文檔里，我們知道使用一個地圖組件的時候是這樣子的：<map longitude="23.099994" latitude="113.324520" markers="{{markers}}" covers="{{covers}}" style="width: 375px; height: 200px;"></map> 在之前的文件里，我們提到過這個文件是wxml文件，然后我們要用wxcc將其轉換為virtual dom中的方法，如：./wcc -d map.xml 它就會返回一個js的方法，如：/*v0.7cc_20160919*/ var $gwxc var $gaic={} $gwx=function(path,global){ function _(a,b){b&&a.children.push(b);} function _n(tag){$gwxc++;if($gwxc>=16000){throw enough, dom limit exceeded, you don do stupid things, do you?};return {tag:tag.substr(0,3)==wx-?tag:wx-+tag,attr:{},children:[]}} function _s(scope,env,key){return typeof(scope[key])!=undefined?scope[key]:env[key]} ... 插播一句：上面有一個count，很有意思$gwxc > 16000，這個就是dom數的count。超了就來個異常：enough, dom limit exceeded, you dont do stupid things, do you?，中文意思就是：你個愚蠢的人類，你是一個前端開發人員嗎？隨后，在瀏覽器里調試一下：JSON.stringify($gwx(map.wxml)(test)) 在小程序中是要這樣調用的： document.dispatchEvent(new CustomEvent("generateFuncReady", { detail: { generateFunc: $gwx(map.wxml) } })) 就會返回下面的結果：{ "children": [ { "attr": { "covers": "", "latitude": "113.324520", "longitude": "23.099994", "markers": "", "style": "width: 375px; height: 200px;" }, "children": [], "tag": "wx-map" } ], "tag": "wx-page" } 看來這個名為wx-map的標簽就是微信下的map標簽，它是wx-page的children。然后讓我們在WAWebview中搜索一下，就會發現一個很有意思的代碼:{ is: "wx-map", behaviors: ["wx-base", "wx-native"], template: <div id="map" style="width: 100%; height: 100%;"></div>, properties: { latitude: {type: Number, reflectToAttribute: !0, observer: "latitudeChanged", value: 39.92}, longitude: {type: Number, reflectToAttribute: !0, observer: "longitudeChanged", value: 116.46}, scale: {type: Number, reflectToAttribute: !0, observer: "scaleChanged", scale: 16}, markers: {type: Array, value: [], reflectToAttribute: !1, observer: "markersChanged"}, covers: {type: Array, value: [], reflectToAttribute: !1, observer: "coversChanged"}, _mapId: {type: Number} } 它的behaviors中有一句：wx-native，這莫非就是傳說中的native組件：順便再看一個video是不是也是一樣的：{ is: "wx-video", behaviors: ["wx-base", "wx-player", "wx-native"], template: <div class="container"> <video id="player" webkit-playsinline style="display: none;"></video> <div id="default" class="bar" style="display: none;"> <div id="button" class$="button {{_buttonType}}"></div> <div class="time currenttime" parse-text-content>{{_currentTime}}</div> <div id="progress" class="progress"> <div id="ball" class="ball" style$="left: {{_progressLeft}}px;"> <div class="inner"></div> </div> <div class="inner" style$="width: {{_progressLength}}px;"></div> </div> <div class="time duration" parse-text-content>{{_duration}}</div> <div id="fullscreen" class="fullscreen"></div> </div> </div> <div id="fakebutton"></div>, properties: { _videoId: {type: Number}, _progressLeft: {type: Number, value: -22}, _progressLength: {type: Number, value: 0} } 好了，你那么聰明，我就這么說一半好了，剩下你自己去猜。可以肯定的是：map標簽在開發的時候會變成HTML + CSSmap標簽在微信上可以使用類似于Cordova的形式調用 Native組件再接著說，virtual dom的事，回到示例代碼里的map.js:Page({ data: { markers: [{ latitude: 23.099994, longitude: 113.324520, name: T.I.T 創意園, desc: 我現在的位置 }], covers: [{ latitude: 23.099794, longitude: 113.324520, icaonPath: ../images/car.png, rotate: 10 }, { latitude: 23.099298, longitude: 113.324129, iconPath: ../images/car.png, rotate: 90 }] } }) js里只放置了data，剩下的都是依據上面的值變動的observer，如：_updatePosition_hiddenChangedlatitudeChangedlongitudeChangedscaleChangedcoversChanged...這種代碼的感覺比React更進了一步的節奏，本來你還需要編碼來觀察state，現在只需要state變動了就可以了。。。23333....，你們這些程序員都會被fire的。好了，這里差不多就這樣了~~。重新審視WXWebview.js于是，我重新逛逛WXWebview.js，發現這個文件里面不只有component的內容，還有：reportSDKwebviewSDK ??virtual_domexparserwx-components.jswx-components.css等等，你是不是已經猜到我在說什么了，上一篇中我們說到了PageFrame： <!-- percodes --> <!--{{WAWebview}}--> <!--{{reportSDK}}--> <!--{{webviewSDK}}--> <!--{{exparser}}--> <!--{{components_js}}--> <!--{{virtual_dom}}--> <!--{{components_css}}--> <!--{{allWXML}}--> <!--{{eruda}}--> <!--{{style}}--> <!--{{currentstyle}}--> <!--{{generateFunc}}--> 在之前的想法里，我覺得我必須要集齊上面的SDK，才能招喚中神龍。后來，我看到了這句：isDev ? { "<!--{{reportSDK}}-->": "reporter-sdk.js", "<!--{{webviewSDK}}-->": "webview-sdk.js", "<!--{{virtual_dom}}-->": "virtual_dom.js", "<!--{{exparser}}-->": "exparser.js", "<!--{{components_js}}-->": "wx-components.js", "<!--{{components_css}}-->": "wx-components.css" } : {"<!--{{WAWebview}}-->": "WAWebview.js"} 如果不是開發環境就使用WAWebview.js，在開發環境中使用使用xxSDK，那么生產環境是怎么回事？如果是在開發環境會去下載最新的SDK，好像不對~~，哈哈。。我猜這部分，我需要一個內測id，才能猜出這個答案。有意思的是，IDE會對比version.json，然后去獲取最新的，用于預覽？{ "WAService.js": 2016092000, "WAWebview.js": 2016092000, "wcc": 2016092000, "wcsc": 2016092000 } 上面已經解釋清楚了WAWebview的功能了，那么WAService.js呢——就是封裝那些API的，如downloadFile：uploadFile: function (e) { u("uploadFile", e, {url: "", filePath: "", name: ""}) && (0, s.invokeMethod)("uploadFile", e) }, downloadFile: function (e) { u("downloadFile", e, {url: ""}) && (0, s.invokeMethod)("downloadFile", e) } 這一點上仍然相當有趣，在我們開發的時候仍然是WAWebview做了相當多的事，而它和WAService的打包是分離的。那么，我們從理論上來說，只需要有WAWebview就可以Render頁面了。

幾天了，沒心情細分代碼我猜測是，js->bridge->系統，然后，系統->bridge->jswebviewbridge這個東西，前端方面我稍微寫過一點，以這個為基礎猜的。微信應用號充當了bridge的功能如果是這樣，性能可以和客戶端媲美，但是組件的定制性差，因為組件是調取系統的不好改。也可能調用的不是系統組件而是微信寫在微信app內的組件，這樣的話定制問題就可以等微信慢慢開放接口了。待我睡醒細看。

總結

以上是生活随笔為你收集整理的微信小程序底层的实现原理是怎样的?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。