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的核心工做链细节

Weex 核心设计理念是三端一体化的动态化解决方案，云端同窗实现实时发布和动态部署、模版预解析处理，前端同窗在 JS Framework 实现动态内容解析并处理成 Virtual DOM，客户端同窗提供渲染实现和 native 特性的支持，接下来业务同窗根据 DSL 实现动态内容的开发或配置便可。

Weex 在 DSL 设计上大量借鉴了 Web 标准的规范，而且经过主流且成熟的 MVVM 模式书写 template、style、script，咱们在学习成本、开发习惯方面为业务同窗考虑了不少，这样的话业务同窗能够很快的学习和上手，而且保证代码的规范性和可读性 (这里要特别鸣谢一下 Vue.js 及其做者尤雨溪，咱们在上层 DSL 的设计和 JS Framework 的实现上都作了深度的使用和借鉴，也在和做者的交流过程当中受益不浅)。

其次为了提高性能，减小客户端的性能损耗，Weex 在服务器端实现了 DSL Transformer 的工做，能够在模版发布的同时，将 XML + CSS + JavaScript 代码转换为能够小数据量执行效率高的 JS Bundle，并同步存储至云端：如 Web Server、CDN 等。

再次为了保证业务逻辑的动态性，Weex 在客户端的 JavaScript 引擎中预运行起了一套 JS Framework，来负责解析整个 JS Bundle，而 native 端则只负责 Virtual DOM 的解析和布局、UI 渲染的实现、以及基础网络通信、文件读写以及手势处理等基础 API 的实现。

还有为了有效的提高工做效率，Weex 的 JS Bundle 能够实现三端跨平台渲染展现，业务同窗能够经过开发一份 Weex JS Bundle，来实现 iOS/Android/HTML5 三端的正常展现。

全部的 native 组件和 JS API 所有都是模块化的，业务同窗能够经过注册新的模块和方法达到去中心化的能力扩展。

关于 Weex 的性能优化还有如下几个细节：

一、JS Framework 经过对数据的依赖收集，实现响应式的视图层，再加上一层 diff 算法的优化，能够有效的过滤冗余的操做和复杂的计算。

二、Native 端对通讯，Virtual DOM 解析以及布局实现等进行异步线程的处理，防止 UI 线程的阻塞。

三、对 UI 组件节点实现了复用处理，并对图片资源进行监控和回收，有效的减小内存的占用。

四、对于实时性要求较高的处理，Weex 容许第三方实现 native 的定制需求来保证体验的流畅性。

图：Weex 关键性能测试和同类方案对比

注：数据取自实验室测试结果，测试界面为 60 个左右“坑位”的商品列表，测试机型为：

• iOS：iPhone5 - iOS 9.1

• Android：三星SM-N9006 - Android 5.0

Weex在天猫双十一的项目实践

Weex 在双十一项目中，参与并支撑了的移动端主会场界面展现和动态处理。在云端实现了天猫前端运营发布系统“斑马”的对接，在前端开发实现了主会场的界面模块和业务逻辑处理，同时在客户端上对接了手机天猫、手机淘宝。

去年双十一主会场的挑战

在每次双十一中，主会场都是很是关键的一个环节。大量的流量把用户、店铺、商品从各路而来汇聚在这里做为着陆的起点。在内容的复杂度、灵活性、体验等方面都有着极高的要求。根据咱们往年的经验，会场的分流能力强化、分会场的层级扁平化、运营工做量合理化、体验和性能的优化，是很是重要的几个细节，同时也推演出了今年主会场的三大改进目标：

• 体验 app 化

• 层级扁平化

• 内容个性化

体验 app 化意味着咱们须要有超越传统 HTML5 的性能和体验；层级扁平化意味着每一层的内容会更加丰富和复杂，主会场固然也不例外；内容个性化则须要咱们在前期内容的产生、算法、投放、客户端内容加载和界面呈现等每一个环节进行全面升级。

Weex在主会场中发挥的做用

想作到这些，光凭一个好的创意和想法、或凭借员工超强的执行力、或靠砸钱砸机器，都是没有办法作到的，这个问题须要技术驱动力来解决！须要精密的设计和实现。Weex 团队在整个双十一的筹备过程当中和需求方就上述问题进行了深刻的沟通和交流，并拿出了切实有效的技术方案，很好的解决了其中的不少关键环节问题，而且 Weex 做为一个新的技术方案很好的经受住了如此重要的“考验”！

首先，咱们经过 Weex 实现了在双十一主会场的 iOS/Android/HTML5 的一次开发，多端同步展现能力，而且展示效果和各方面的体验都是 native 级别的。

第二，咱们配合算法团队实现了今年的双十一主会场的个性化需求，即所谓的“千人千面”，并实现了双十一主会场商家的运营配置的静态数据和个性化推荐算法的动态数据在端侧的拼合展现。而且优化了整个客户端内容加载、界面初始化、交互时的性能

第三，Weex 保有了接近 HTML5 的灵活调整发布机制，实现了在客户端侧的渲染动态性，运营人员能够经过配置实时调整主会场楼层位置，以及“坑位”的排布，以及界面的布局展现和样式调整。

第四，基于优异的性能表现，在内容呈现的数量上，咱们也突破了传统的 120 “坑位”的性能极限，本次双十一最后实际的最大“坑位”数接近了 180 个，依然表现很是完美——要知道团队在前期都是拿 300 个“坑位”进行“暴力极限测试”的。为会场的扁平化进一步提供了保障。

更多的Weex项目实践分享与总结

目前 Weex 已经在阿里巴巴集团内和更多的业务方展开合做，包括淘宝双十二等项目 (笔者撰稿时恰逢双十二当天，Weex 正在接受新一轮的业务洗礼！)，咱们但愿后续会有更多的实践经验和心得持续分享出来。

Weex 团队会紧抓移动端动态性这个关键命题，围绕 Weex 的三大特色：轻量、高性能、易扩展，进行周期性的迭代和完善。咱们会在更简单直接的实践方式、更高的加载/启动/渲染/交互性能、更强的去中心化定制性和横向扩展性方面不断突破和创新。并按期在集团内开放最新的版本和文档、配套工具、周边生态等。

关于开源：团队始终认同一个观点——开源并不是一个简单的行为，而是一个过程和最终的结果构成的总体。团队但愿 Weex 可以逐步解决更广泛的业务问题，尽量的保障工程质量和代码质量，并发展成为可以被社区接受、参与和信赖的技术方案。体现更大的价值，同时获得更多的支持和更快的发展。这是咱们但愿的，也但愿是你们但愿的：）

“手机淘宝技术团队赵锦江（勾股）、黄金涌（伊耆）等专家参与本文创做”。 本文于InfoQ刊登。

关于阿里百川
阿里百川（baichuan.taobao.com)是阿里巴巴集团“云”+“端”的核心战略是阿里巴巴集团无线开放平台，基于世界级的后端服务和成熟的商业组件，经过“技术、商业及大数据”的开放，为移动创业者提供可快速搭建App、商业化APP并提高用户体验的解决方案；同时提供多元化的创业服务-物理空间、孵化运营、创业投资等，为移动创业者提供全面保障。