用WEB技术栈开发NATIVE应用：WEEX 前端SDK原理详解

来源：网络浏览：120 2022-11-15 02:39:01

摘要： WEEX仍然采用传统的web开发技术堆栈进行开发，同时app在终端的运行体验不输native app。同时解决了三个主要问题：开发效率、发布速度和用户体验。那么WEEX是怎么实现的呢？目前，WEEX完全开源，已捐赠给Apache基金会。通过分析源代码，可以调查该源代码。

作者：阿里-移动云-领先前端团队

在传统的移动开发中，完整的业务需要维护Android、iOS和H5三个终端代码，大大增加了开发和维护成本。特别是在业务初期需要迅速进行反复试验的业务，以及需要支持定期运营活动的业务方面。因此，业界也在探索跨平台的方案，通过一组代码完成每个终端的业务逻辑。相关方案不断演进，从早期的H5、Hybrid到现在的云原生，在开发效率和用户体验上一点点接近最初的构想。

初始的H5和Hybrid程序的核心是利用终端的内置浏览器( webview )功能，通过开发web APP应用程序来满足跨平台的需求。这个解决方案解决了跨平台的问题，提高了发布效率。但是，最大的弊端是，用户体验与native开发的app相比有很大的差距，分页纸箱和加载缓慢等问题频发。

此后，业界依然开始探索利用web技术堆栈开发与原生体验app相媲美的方案，以WEEX为代表的云原生开发框架开始问世。云原生( Cloud Native )是指可以在云中快速发布(类似于远程web APP发布过程)，同时实现与原生App体验相媲美的计划。 WEEX仍然采用传统的web开发技术堆栈进行开发，同时app在终端的运行体验不输给native app。同时解决了三个主要问题：开发效率、发布速度和用户体验。那么WEEX是怎么实现的呢？目前，WEEX完全开源，已捐赠给Apache基金会。通过分析源代码，可以调查该源代码。

WEEX框架主要分为两个部分。

前端JavaScript框架

Native SDK

上一篇博客介绍了Native SDK的原理。本文主要介绍了前端JavaScript框架的原理。

1总体架构首先，我们来看看WEEX开发的总体架构。

在JS-Native Bridge向Android或iOS渲染引擎发送渲染命令之前，您将看到我们的业务代码正在JSCore/v8的执行引擎上运行。除了业务JSBundle外，该执行引擎还运行JS Framework。 js框架不仅提供JSBundle，还提供js框架

而且，这个JS Framework是今天介绍的重点。

这是前端框架的主要体系结构。

FRONTEND FRAMEWORK/DSL :这是WEEX的开发框架，目前WEEX主要使用Vue.js进行开发

weex-vue-loader :用于将vue文件编译为es5代码的前端编译器

weex-vue-framwork:weex核心框架，主要负责将virtual dom转换为weex的native dom api

weex-runtime :负责与native渲染引擎的对接，将native dom api转换为相应平台( Android，iOS )的平台API，并转换为native渲染引擎后者负责渲染工作。

2 Vue.js首先来看看前端开发框架Vue.js。 Vue.js现在与React、Angular构成了三个最受欢迎的前端开发框架。 Vue.js具有组件化、virtual dom及MVVM三个特性，学习了React的Redux，引入了状态管理模块Vuex，同时与React主要基于JSX相比，Vue.js的开发模式更加完善. vue文件通常分为三个部分。3weex-vue-loader.vue文件不是标准的JavaScript代码，因此JS执行引擎无法直接识别此代码，因此必须在编译过程中将. vue文件转换为标准的es5代码。负责这个的是WEEX-VUE-LOADER。

4编译4weex-vue-frameworkweex-runtime后，js执行引擎可以识别输出的bundle.JS并执行其逻辑。那么接下来我们来看看bundle.js的运行过程。

4.1初始化

首先来看看初始化过程。

图中描绘了Weex SDK的部分内容。其中，weex-vue-framework和Vue.js对等，语法和内部机制都相同。但是，Vue.js最终会创建DOM元素，weex-vue-framework将渲染指令发送到本机端，最终渲染并生成的是本机组件。 Weex Runtime与顶级前端框架( Vue.js )协作，负责与本机通信。 Render Engine是一种针对不同端点开发的本机渲染器，具有内置于Weex中的组件和模块的实现和可扩展性。

4.2创建组件

weex在接收到bundle.js后，首先检查其合法性，如果发现使用的是Vue版本( weex的早期版本使用. we语法)，则在weex-vue-framework中提供bundle.js对应于一个weex实例，每个实例都有唯一的实例id。实例和实例相互隔离，互不干扰。

在创建实例时，bundle.js将运行new Vue ( )以创建vue组件，然后通过其render函数创建VNode节点或virtual dom节点。第2部分中的示例代码最终将生成vnode节点，如下所示：

4.3修补程序

生成VNode后，接下来需要将VNode同步到实际Dom上。此过程在Vue.js中称为patch，它比较新旧VNode之间的差异并将操作集最小化。最后，将整个Virual Dom更新到实际Dom之上。因为执行patch之前的所有进程都是Web和Weex通用的，所以文件格式、包编译进程、模板指令、组件生命周期和数据绑定等更高级别的语法是一致的。

但是，由于目标的运行环境不同(浏览器和Weex容器)，渲染实际UI时调用的接口也不同。

在vue.js内部，weex平台和web平台的patch方法不同。简单来说，在web平台上，patch必须使用标准Dom API将Virtual Dom更新为实际的Dom。下次UI的更新交给浏览器就可以了。

但是，在weex平台上，最终的UI渲染由native渲染引擎执行，native渲染引擎无法识别Dom API，因此在weex平台上，将Virtual DOM转换为native

4.4发送渲染命令

在高级前端框架调用Weex平台提供的Native DOM API后，Weex Runtime将构建用于渲染的节点树，并将操作转换为渲染指令并将其发送到客户端。

回顾文中提到的例子，上层框架调用Weex Runtime的createBody、createElement、appendChild个界面，简单地构筑渲染用的节点树，最终形成2个渲染

平台API是本机环境提供的API。这些API由Weex SDK的本机模块提供，既不是js方法，也不是浏览器界面，而是Weex内部不同模块之间的约定。

目前，渲染命令是基于JSON编写的，具体格式如下：

4.5渲染本机组件

接下来是WEEX NATIVE SDK的工作。具体的逻辑在之前的博客中详细说明了，这里只简单说明一下。

本机渲染器从更高层接收渲染命令，并逐渐将其渲染到其本机组件。

渲染命令分为许多类别，文章中的两个命令用于创建节点，以及其他各种命令，如moveElement、updateAttrs和addEvent。本机渲染器分析渲染命令的说明，然后将其分发到其他模块。所有UI呈现命令都属于“dom”模块，并且SDK中包含组件实现。其他一些没有接口的功能模块，如stream、navigator，也可以通过发送命令调用。

在此示例中，第一个createBody命令创建了本机组件，并将样式应用于更改组件。第二个addElement命令将组件添加到，并声明组件的样式和属性值。

上述过程不是逐步执行的，而是可以进行“流”渲染，并且可能还没有渲染第一个本机组件，您收到了渲染命令。当一个页面很大的时候，可以看到一个个内容逐渐渲染的过程。

5总结

还有很多实现的细节尚未展开，感兴趣的朋友可以留言大家讨论。另外，也请指出文章中有错误的地方。