阿里无线11.11 | Weex——关于移动端动态性的思考、实现和未来

什么是动态性

今天在移动端，尤其是像手机淘宝这样的 App 中，动态性问题逐渐成为一个比较棘手的问题。所谓动态性，就是把移动应用本身的灵活性、迭代更新的周期和成本优化到极致。比如手机淘宝的店铺首页，它允许商家实时装修自己的店铺，更新自家的商品、活动等信息；再比如淘宝、天猫每次大促的会场页面，要求我们非常灵活的及时调整界面信息和状态，确保在瞬息万变的活动当天紧跟促销节奏，应对各种突发情况。

为什么要解决动态化的问题

动态性需求的出现有很多必然的因素：我们的移动应用背后是一个平台级甚至是生态级的电商系统，它需要有海纳百川的能力和高速流通的特点，市场上很多移动应用也有类似的客观形态和诉求；同时整个行业迄今为止在移动端的积累都还不足以对产品形态、用户体验、交互方式等细节有完全的前期把握，一个移动应用，客观上需要更多的尝试和探索，甚至是“试错”，而这种动态化的程度和产品迭代演进的速度有着强烈的正相关；第三，我们不必要为这些动态性在多个端投入重复的精力，更不应该因此而频繁的触发新版本。所以动态性问题在今天的移动端显得尤其重要。

动态性问题的历史

动态性问题不只是移动端特有的，在互联网技术发展的历史长河中，桌面端也存在并经历着类似的事情。今天桌面端的结论似乎已经形成，那就是W3C长期倡导的WebPlatform (或被称为 Web App 或 HTML5 或浏览器)，然而这也经历了去平台差异化、native插件支持 (flash player)、设备性能提升、渲染引擎优化等过程。

而在移动端，阿里巴巴的无线事业部、兄弟团队、以及整个行业都在做着各种积极的尝试和实践：

Hybrid方案：以WebView为容器，以HTML5为基石，通过定义native特性的扩展来支持的动态化产品研发，比如手机淘宝内部的名为WindVane的容器，这类方案通常具有非常高的动态性，但存在的问题和动态性本身一样明显，那就是性能和展现效果上的不足，而且想把其优势在工程中充分发挥出来，对开发者在前端知识和经验上的积累也有较高的要求，篇幅有限不做过多的展开。

结构化native view方案：以native view为容器进行 native 级别的渲染，并定义一套描述视图结构的数据格式 (如 XML 或 JSON 等) ，然后通过动态改变或请求新的这样的数据信息达到动态化的界面效果，比如阿里巴巴集团内出现 (过) 的 WeApp、鸟巢、Dynative、PageKit 等，这类方案依赖一个结构化的界面描述，并重点保障纯展现输出维度的动态性，各有千秋，但有一些共性的不足之处，比如对其它维度的动态性处理，比如逻辑的动态性，加载策略的动态性等。

React Native方案：大家习惯简称其为RN，以native为渲染引擎，通过脚本引擎支持界面Virtual DOM的转换和逻辑控制，来实现界面的动态性。RN 前半年在阿里很多团队都得到了实践，包括我所在的无线事业部，但效果并不令人满意，首先是RN量级非常重，在请求、加载、渲染、交互、稳定性等层面都不够理想，而整个技术方案在社区的迭代和演进过程也一直充满着不确定性，这给团队产品级别的运用和后期跟进带来了很大的困惑。

实际上，我们觉得 RN 更像是一个全新的移动开发框架，而不是为了增强现有移动应用的动态性而生。大家希望通过 RN 解决动态性问题，是因为它在客户端引入了 JavaScript 引擎而已。 

关于移动端动态化方案的再思考：Weex

综上所述，我们能够看到很多中动态性问题的解法，但也都各有所限。团队经过不断的观察和讨论，决定拿出一套更好的更针对移动端动态性问题的技术方案——这就是今天的 Weex！

Weex的设计理念和思考过程

Weex 在我们看来已经具有非常多的特点，比如：

致力于移动端，充分调度 native 的能力

充分解决或回避性能瓶颈

灵活扩展，多端统一，优雅“降级”到 HTML5

保持较低的开发成本和学习成本

快速迭代，轻量实时发布

融入现有的 native 技术体系

工程化管理和监控等

……

但是 Weex 其实最核心的诉求就是解决移动端动态性问题，它有自己非常鲜明的三大特点：

轻量：体积小巧，语法简单，方便接入和上手

可扩展：业务方可去中心化横向定制组件和功能模块

高性能：高速加载、高速渲染、体验流畅

Weex 为移动端动态性问题而生，这些优势都是天然的，追求极致的。团队基于这三方面设计并实现了整套技术方案。

团队在 Weex 的设计和实践中，还有一个很深刻的感悟，就是：找到性能与动态性之间的平衡点。

放眼这么多动态性技术方案，有这么几个必经之路：

动态内容的开发/配置

动态内容的云端部署

客户端请求动态内容

客户端把动态内容现成最终的效果

如果我们不只是处理纯展现性质的动态性内容，那么要再加上一个必经环节

动态内容的开发/配置

动态内容的云端部署

客户端请求动态内容

客户端把动态内容和逻辑解析成视图

客户端把视图展现成最终的效果并处理用户交互

这里面哪些环节值得扩展、哪些环节需要更多的动态性、哪些环节是性能的瓶颈，是整个解法的关键。通过思考和讨论，我们不难发现：

动态内容的开发/配置需要快速实现

云端部署需要尽量去中心化，横向可扩展

客户端请求需要尽量小的传输数据，需要尽量快的加载过程

客户端内容解析需要动态性

客户端交互响应需要动态性，需要尽量去中心化，横向可扩展

客户端界面渲染需要高性能，需要尽量去中心化，横向可扩展

所以我们的解决方案中有几个关键决策：

在内容开发/配置和云端部署之间需要有 transformer 的转换和处理能力，平衡开发体验和客户端请求的数据量

客户端需要有 JavaScript 引擎，处理动态逻辑，提供动态加载策略，同时需要将复杂的端上的解析工作尽量提前

动态内容的描述需要有结构、样式、数据、行为的分离，保障复杂的内容可分解

客户端界面渲染需要 native 的渲染能力，保障性能

Native 渲染和 JavaScript 引擎之间的边界放在了 Virtual DOM，两者通过约定 Virtual DOM 来进行通信，而不是 template + data 或是别的边界，确保渲染性能和灵活度的平衡

动态内容发布、客户端接入、组件、JS API 全部需要横向扩展性，保障 Weex 的核心足够轻，足够专注，同时竟可以支持更多的业务场景

Weex的核心工作链细节

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!