快應用宣佈支持第三方DSL

1. 背景介紹

你們好，這裏是快應用聯盟的前端研發團隊；

自去年3月，快應用聯盟成立以後，已經有不少開發者使用快應用的標準DSL（以ux文件後綴的項目形式）上線了對應產品。

以「旅遊出行」的品類爲例，就有：攜程、去哪兒、高鐵管家等；

關於更多的快應用產品與體驗，讀者能夠在Android手機的應用商店 -> 分類 -> 快應用 欄目中查看；

今天呢，研發團隊帶來一個好消息，就是：快應用開放平臺接口，能夠支持第三方的DSL啦！

接下來分享主題：以流行的vue框架爲例，讓快應用支持第三方DSL的開發能力；

那麼爲何作這個事呢？主要仍是爲了知足前端同窗的開發習慣，提高開發者的體驗與效率。因此藉助這種契機與接口開放的能力，快應用能夠支持其餘更多的DSL。

1.1過往回溯

自從微信小程序從16年10月內測以來，前端開發在端適配上迎來了巨大的變化；開發者寫的代碼，不只要知足WEB平臺、原生渲染平臺（RN開發），並且還要增長對小程序的支持；

18年3月成立了國內手機廠商成立了快應用聯盟，隨後又涌現了百度/阿里/頭條等多個小程序生態，給開發者提出了更高要求，從"面向模塊的開發"到"面向多端適配"；

可喜的是：在這種背景下，前端圈子裏逐漸衍生出新的框架，就是但願可以提供統一的DSL，讓開發者編寫一套代碼，完成多端自適應的運行效果；

面對市場上衆多的框架，新手開發者如何粗略瞭解與選擇呢？

1.2當前現狀

從歷史發展與職責目標的角度看，當前市場上的DSL框架能夠分爲如下4類：

1) WEB型：

好比：React、Vue、Angular等輕量級的數據驅動框架；

簡述：主要用於瀏覽器的頁面開發，由於語法簡單、容易上手、調試方便而備受開發者的喜歡；

發展：由於擁有普遍的用戶基礎，逐漸發展多個子方向，如：UI組件庫方向（如：Ant Design、ElementUI），簡化版方向（移動端性能好，擴展更多能力）；

職責：提供開發者鍾愛的語法，解決前端項目中組件化、分層架構、工程組織、數據流等問題，讓開發者以最優雅的方式管理項目；

2) 平臺型

好比：Weex初期的we文件語法，微信小程序的wxml語法，快應用提供的ux文件、百度智能小程序的swan文件、Flutter的dart；

簡述：主流的大互聯網公司都會推出自有的渲染平臺，從而爲知足初期自身平臺的渲染而提供一套本身實現的前端框架；

發展：每一個平臺擁有獨特的語法，讓開發者水土不服，針對該平臺從新開發一套產品代碼，學習成本較大；

職責：這類前端框架的存在主要是爲了知足第一版與迭代，更多服務於平臺的系統能力提供，研發方向着重於技術深度的底層渲染（繪製、合成）；對於前端框架而言，僅知足開發需求，指望培養開發者習慣，並引領開發潮流較難，除非這類DSL能夠同時生成到移動端等的適配；

3) 適配型

好比：Weex上支持Vue語法，微信小程序中使用Wepy和mpvue，以及本次介紹的快應用平臺上引入Vue開發方式；

簡述：介於諸多開發者對於上述平臺型DSL不適應，從而引入前端受歡迎的WEB型DSL；

發展：這裏的發展思路差別比較大，有的是平臺自身開發支持的，有的是經過DSL愛好者移植適配完成的，經歷二次編譯（WEB型DSL先轉成平臺型DSL，而後平臺型DSL再轉換成能夠直接運行的平臺編譯代碼）；

二次編譯的優點在於：它不須要了解平臺內部是如何實現的，僅須要根據官方提供的DSL能力進行能力適配便可；缺點在於：比較依賴平臺型DSL能力，若是不支持某個特性則適配困難，或者容易形成性能瓶頸；

若是是平臺自身支持的，那麼開發者代碼，直接就能夠完成對UI的操做，跳過官方標準DSL的模型，減小中間調用，完成加速渲染；這種方式的難點在於：平臺自身須要提供穩定的UI操做接口，作到向後兼容；

毫無疑問，平臺自身的支持，可以比二次轉換，帶來更好的效果；

職責：儘管各自思路不一樣，可是目標一致，完成開發者從WEB到具體平臺的順利過渡；

4) 全能型

好比：滴滴的chameleon、去哪兒的nanachi、京東的taro等；

簡述：該類型從上面的適配型開始萌芽，圍繞如何解決多端適配問題，但這僅僅只是表象問題；對於後續壯大發展，須要思考面更廣，對抽象概念理解更深入，如： APP容器管理，渲染設計，系統功能調用，動態加載等概念；

發展：儘可能抹平WEB、原生、快應用、小程序等渲染的差別，抽象應用模型，完成頁面渲染設計，最後適配到各平臺；固然適配時若是可以直接完成對平臺API的操做，要比二次轉換效果要好的多；

職責：完成較全面的多端適配，達到一套代碼多端適配的目標；

那麼本文講述的快應用引入Vue DSL，屬於上述的適配型，讓平臺自身支持，同時開發平臺接口，爲日後出現的全能高效型框架服務；

1.3 近期趨勢

在做者看來，新的19年，全能型框架會逐漸取代適配型，而且從規範、架構、設計等角度上，提出新的理念與原則；基於此，各平臺經過自身或者開源愛好者完成適配轉換；

固然，各平臺負責方（快應用、小程序）也會加深對統一的認識，藉助於W3C研討會、興趣組、前端會議，促教交流，考慮抽象出本身的渲染API與能力通道，讓更友好的全能型框架完成高效適配，這塊敬請期待吧；

中間也一定會產生一些兼容性類庫，完成polyfill的輔助角色；

因此基於這種趨勢，快應用採用了這樣的路線：開放頁面渲染接口，輕鬆支持第三方的DSL；

2. 實現方案

那麼快應用本次支持Vue的DSL能力，都作了哪些事情呢？

接下來咱們從渲染流程、架構設計、開發體驗、項目代碼、加載過程、平臺解耦、測試保證的多個角度闡述。

2.1渲染流程

要想完成適配，首先須要對比兩方平臺的頁面渲染過程是否類似；通過抽象彙總，得出主體過程都是這樣的：

步驟1. 工程化工具編譯開發者使用某種DSL而編寫的業務代碼；

步驟2. JS引擎運行時加載完DSL框架後，執行開發者的業務代碼；

步驟3. 基於DSL的核心邏輯，生成MVVM的模型；

步驟4. 業務中對數據的操做，觸發對DOM節點的更新；

步驟5. DOM更新後渲染引擎，發出VSync申請，標記髒值節點；

步驟6. 遍歷待更新節點，依次樣式佈局計算、繪製合成，完成渲染；

當前二者實現的區別主要在於：線程的工做分配與協調機制、渲染實現的具體邏輯；然而這些對於DSL框架而言，是不須要關注深度實現的；

同時快應用自身會構建一套頁面UI的DOM樹，所以抽象出了一套DOM的API提供給DSL；DSL只須要調用快應用提供的節點操做接口，便可輕易完成適配；

爲了方便理解，咱們在Github上增長了 Vue版本的TodoMVC的示例項目quickappcn/todomvc-vue。

實際效果能夠訪問下面地址： github.com/quickappcn/…

既然流程一致，那接下來就看如何架構設計，分層組織了。

2.2架構設計

以當前支持Vue的適配爲例，主要工做在於：編譯時、運行時兩方面；

• 編譯時

提供針對DSL的項目模板化、DSL的解析編譯能力，期間可使用快應用組件與樣式的校驗解析接口；

當前快應用項目的開發，使用的是 官方hap-toolkit工具，這是一個基於NodeJS的npm庫；

關於項目的構建打包、調試等非DSL專有能力的，均已模塊獨立；項目結構採用模塊化的開發方式，藉助於 lerna完成耦合分離；

DSL開發者只須要開發對應的DSL模塊，增長模板化、語法解析，便可完成適配。

• 運行時

負責執行開發者的業務代碼，管理DSL中的驅動模型，完成數據更新到DOM操做的轉換；

快應用平臺運行時會提供DOM的API，針對每一個頁面提供一個document節點；

DSL層除了包含官方Vue的源碼邏輯以外，還有兩部分：

• DOM API調用：完成對節點的操做；
• 容器適配模塊：提供針對應用/頁面概念的適配；

針對這塊，快應用在Github提供瞭如下幾個項目：

項目quickappcn/Vue

從官方Vue站點克隆而來，保存Vue核心源碼、以及針對快應用DOM API的適配；

項目quickappcn/quickapp-dsl-vue

負責DSL在快應用平臺上的應用容器適配，如：生命週期、事件通知等；

有了編譯時/運行時的核心支持，其它工做（如：IDE支持）就是相對較小的任務拆解了。

2.3開發體驗

對於使用DSL Vue的快應用開發者來講，會不會與標準DSL(標準DSL：ux做爲後綴名)開發方式，差異很大呢？

其實開發過程，與快應用標準的DSL項目開發方式基本徹底一致，標準DSL的項目中展現的ux文件，DSL Vue中展現的是vue文件；

使用方式以下：

步驟1：全局安裝npm庫：npm install -g hap-toolkit

步驟2：初始化項目：hap init --vue

步驟3：構建項目：npm run build

步驟4：運行在快應用的APK平臺，開發者能夠選擇「本地安裝「或者」 在線更新「的方式，與標準開發方式一致。

2.4項目代碼

總結一下，本次快應用爲引入Vue DSL而提供的項目：

• 項目quickappcn/todomvc-vue

展現在快應用平臺上運行該DSL項目的實際開發示例；

項目使用了組件化的開發方式，完成展現與表單的頁面交互，文件組織結構以下圖所示：

熟悉快應用開發的讀者，會發現與標準DSL同樣，這樣方便快速上手。

• 項目quickappcn/Vue

從官方Vue站點克隆而來，提供針對快應用DOM API的適配；

項目中新建了一個quickapp-initial的分支，放置適配代碼；

• 項目quickappcn/quickapp-dsl-vue

提供了DSL在平臺上的應用容器適配，如：生命週期、事件通知等；同時包含針對上一個核心DSL源碼項目的構建後代碼；

爲了輔助開發，開發者能夠補充測試用例，完成單元測試、項目測試的功能保證；

其中的單元測試：測試Vue的自身功能表現正常；

其中的項目測試：測試Vue在基於NodeJS的快應用模擬平臺上，是否表現正常；

• 項目quickappcn/hap-toolkit

提供對開發者寫的DSL的模板化、語法校驗、項目打包等功能；

採用lerna模塊化改造後，目前劃分的模塊的依賴關係以下圖所示：

對於DSL開發者來講，只須要關注：hap-dsl-vue的模塊便可，這塊的代碼以源碼的形式保存；其中的templates文件夾存放項目模板，src文件夾存放相關的編譯解析能力；

對於其餘的部分模塊，好比：hap-compiler，hap-server屬於全部的DSL共用模塊，開發者通常無需更新；同時部分模塊並未僅提供了編譯後代碼，如需開放源碼，開發者能夠下來聯繫；

爲了保證穩定性，也能夠增長測試用例（當前使用的是 Jest），完成單元測試與項目測試的編譯功能確認。

hap-toolkit@0.3.0版本上增長了對Vue DSL的支持，不過並未採用lerna管理，後續發佈的0.4版本之後會用這種方式；

注意：因爲新業務功能的開發，當前模塊化組織結構可能還會繼續調整。

2.5加載過程

在快應用完成編譯時/運行時的開發後，DSL是如何加載並調用渲染的呢？你們看下下面的圖例就明白了；

快應用的運行能夠分爲三個階段：

第一階段：環境準備

底層平臺啓動，暴露DOM等相關API，加載DSL代碼，並完成與平臺的橋接通信；

第二階段：業務代碼執行

加載並執行開發者項目中的vue業務代碼（編譯後轉換爲JS），創建驅動模型，完成VDOM的對比；

第三階段：平臺渲染

上一層VDOM對比的結果，轉換成對平臺的DOM API的實際調用，平臺線程而後作佈局計算、繪製等完成界面的展現；

上圖所示，能夠得出：DSL與平臺的解耦與交互發生在第一階段的最後一步，即：平臺接口暴露以後，業務代碼執行以前；所以整個運行，DSL框架僅會加載一次。

2.6平臺解耦

那麼DSL與平臺須要考慮哪些方面的解耦事項呢？主要分爲三個部分：

1) 容器管理

快應用是一個應用形態，包含多個頁面，這點不一樣於瀏覽器，因此就會存在應用/頁面的生命週期；

開發者須要監聽這些生命週期，用於完成：數據請求、統計、性能監控；

爲了保持解耦合，平臺使用了Publish/Subscribe模型，DSL只須要訂閱相關的事件，便可暴露給開發者；

開發者能夠從項目quickappcn/quickapp-dsl-vue的src/shared文件夾 中獲得提示；

2) 頁面渲染

對於每一個頁面來講，頁面的渲染依賴於組件樹的構建，爲了方便對組件進行操做，平臺提供了一套相似瀏覽器的組件操做接口，稱爲：平臺DOM API；

爲了提高DSL適配的簡易性，快應用的DOM與瀏覽器中的DOM很是類似；

好比：建立節點的API（document.createElement()）、節點增刪的API（element.appendChild()、element.insertBefore()）

在Vue DSL中，開發者都會使用哪些接口進行節點操做呢？

能夠從項目quicappcn/vue的src/platforms/quickapp/node-ops.js文件中獲得提示；

3) 接口功能

業務開發中，開發者確定須要調用系統功能，如：fetch請求：require('@sysem.fetch')、地理位置：require('@system.geolocation')

這方面的語法與平臺的標準DSL語法保持一致，會在編譯時進行轉換，如：fetch請求轉換爲：$app_require$("@app-module/system.fetch")$；

平臺執行開發者的JS代碼時，會自動注入一個全局函數$app_require$；那麼JS執行時就會經過該函數完成系統功能的獲取；

因此關於這塊，DSL適配不會有實際工做量；能夠項目quickappcn/quickapp-dsl-vue的src/dsls/vue/page/interface.js文件中獲得提示；

2.7 測試保證

對於DSL開發者來講，經過測試用例保證功能穩定是必不可缺的；

針對編譯時，測試相對簡單，查看項目quickapp/hap-toolkit便可讀懂；

針對運行時，若是每次對源碼修改後，都須要在手機設備上測試運行，確認功能的話，將會很浪費時間；

爲了解決這一難題，快應用平臺的前端層面，提供了在NodeJS環境上的平臺模擬能力；所以開發者能夠經過兩方面的測試用例來保證穩定：

• 單元測試

完成對DSL的基本功能進行測試，如：指令、filter、數據驅動等各類DSL自身特性；

相關代碼請參考：項目quickappcn/quickapp-dsl-vue的 test/suite/dsls/vue/unit文件夾；

測試命令請參考：項目quickappcn/quickapp-dsl-vue的package.json中的"test:suite:framework:main:vue:unit"命令；

• 項目測試

開發者像開發正式的快應用項目同樣，編寫DSL頁面；模擬平臺會將測試項目編譯打包，而後逐個執行開發者的頁面代碼；

開發者能夠在這裏，測試DOM樹的結構一致性、生命週期、接口功能等；

相關代碼請參考：項目quickappcn/quickapp-dsl-vue的test/suite/dsls/vue/project文件夾；

測試命令請參考：項目quickappcn/quickapp-dsl-vue的package.json中的"test:suite:framework:main"命令；

3. 合做交流

若是您是快應用的開發者，或者其餘角色，對於前端開發生態感興趣，歡迎提出各種建議，或合做意向。

快應用平臺對DSL能力的支持，前端與底層研發團隊作了不少耦合分離工做，開源工做得以推動；同時感謝聯盟內各家廠商研發的鼎力支持，你們合做共同管理項目源碼與規範制定。

3.1使用DSL開發

若是您也是Vue框架深度愛好者的話，能夠考慮使用Vue來作快應用產品的開發；

圍繞Vue DSL的最新能力與運行體驗，咱們將會在項目quickappcn/quickapp-dsl-vue中保持更新，您能夠向這裏提交issue反饋需求；

快應用的Vue DSL會在1050版本邀請內測，待功能穩定後，平臺將內置正式版本的Vue DSL；

注意：因爲當前內測期間，Vue DSL暫不支持華爲設備，聯盟內全部剩餘廠商都可以無縫支持；

3.2其它DSL接入

若是您是某個DSL（如：React）的愛好者，或者某個全能型框架的設計者，有意向接入到快應用平臺中，讓更多的開發者受益，歡迎洽談垂詢；

您能夠經過聯盟的任何成員/各類渠道聯繫前端團隊，或者向咱們發送郵件： dongyongqing#xiaomi.com；

謝謝！

3.3簡歷推薦

若是您對快應用的研發工做感興趣，有意提高對平臺的架構/設計能力，或者可以跨越瀏覽器的限制提出更多的規範思路，歡迎聯繫咱們；