快应用宣布支持第三方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简历推荐

若是您对快应用的研发工做感兴趣，有意提高对平台的架构/设计能力，或者可以跨越浏览器的限制提出更多的规范思路，欢迎联系咱们；