Weex和Web开发体验的异同

在2017年1月12日 Weex Conf 2017下午的技术实践论坛上， Weex团队的勾股详细讲解了Weex和Web开发体验的异同。他主要从Weex 中的 Web 标准、Weex 中的 Web 研发模式以及其它注意事项展开了此次分享。

本文根据现场分享和幻灯片整理而成。

Weex 中的 Web 标准

Weex中的Web标准主要包括HTML/CSS/JavaScript三个维度。

HTML

目前Weex支持的Components约为15个，具体组件如下图所示。

相比于完成的HTML语法标准，Weex所缺失的内容可以总结为三部分：

•  块级语义化标签，如Section、 Article等；
  
•  内联文本标签，如Strong、em等；
  
•  表单类标签，如button、select等。
  

对于缺失的内容，Weex提供了特定的的解决方式。对于缺失的块级语义化标签，可以通过自定义标签的方式去定制，如<section>标签可以通过<div>的方式代替（两者行为类似），并且降低了成本。具体代码如下：

<template>
<section>
<text>Hello World</text>
</section>
</template>

采用div替换后：

<template>
<div>
<text>Hello World</text>
</div>
</template>

对于内联语义化标签，如<strong>标签，也可以<text style="font-weight: bold;">方式替换，效果完全相同。

对于表单类标签，如<input>/<textarea>等文本输入相关的标签现已支持；radio可以利用<image>+<text>拼接实现；checkbox可以利用<switch>代替；<select>标签可以通过picker或自定义定制得到。

值得注意的是：上述的内容全部可以通过Vue <template>实现。此外，富文本组件目前也在开发过程中，期待未来能够在Weex中提供（Github上富文本组件讨论区：https://github.com/alibaba/weex/issues/835）。

CSS

对于CSS，从命题维度角度考虑：首先，CSS选择器种类繁多；其次，CSS有很多属性，相同或不同的属性有着各种属性值和单位。Weex在支持CSS方面具有以下特点：

•  从上层语法角度来看，Weex目前支持单个Class选择器，这也是CSS在JS中的最佳实践；
  
•  支持伪类wip，如传统的hover（更多细节点击此处阅读）；
  
•  属性支持情况，width、overflow等使用频次较高的属性都已支持(更多细节点击此处查看)；
  

由于目前的Vue 2.0前端框架、上层建筑以及周边组件足够丰富，目前Weex现已支持PostCSS/CSS Next。

JavaScript

JavaScript的标准可以分为语法层面和浏览器或Web端API设计两个层面。目前可以使用ES6、ES7或更高更好的版本开发JavaScript，同时一些关键的Polyfill，Weex都做了官方的支持；此外，Weex 在 JS 引擎中为每个页面都提供了一套 Native DOM APIs，这套接口和 HTML DOM APIs 非常接近，利用这套接口可以通过JavaScript控制 Native 的渲染逻辑，而且 Weex上层的 Vue 2.0 也是基于这套接口进行适配的（更多细节点击此处查看）；Weex还提供了Device API，使得JavaScript尽可能具有驱动整个设备的能力。

在Weex运行时，只有一个JavaScript引擎实例。在Weex中，尽管可以同时打开多个页面，但这些页面是共享一份JavaScript（这和传统的网页有区别）。之所以这么做是为了让设备在端上的资源能够得到充分利用，但这同时带来了长效的JavaScript内存泄露的问题。

目前，除了通过封装的方式控制内存泄露之外，还可以强制“use strict”，因为在该模式下无法随意创建全局变量；此外，还可以强制Object.freeze全局变量，在此之后对全局变量或对象只能进行读操作。

JS Service

未来，我们希望在JavaScript引擎中建立JS Service层，该层可以横跨多种JS框架统一管理；同时可以横跨所有实例，实现多实例统一管理，使得能力、数据和内存得到有效管理和增强；甚至可以将Polyfill、AMD 实现、第三方库引入、native 回调函数管理、全局数据共享、全局路由管理、Worker...等功能都在JS Service调度实现。

Vue 2.x 在Weex和Web中的差异

Vue 2.x 在 Weex 和 Web 中的差异主要体现在平台、功能、样式、编译环境上，下面来一一解读。

平台差异，Vue.js最初是为 Web 平台设计的，虽然可以基于 Weex 开发原生应用，但是 Web 开发和原生开发毕竟不同，由于运行平台存在差异，Weex 不支持 Vue 中与 DOM 相关的功能：

•  不支持事件冒泡和捕获机制，.prevent 、.capture 、.stop 、.self 等事件修饰符在原生环境中无意义；
  
•  键盘事件的 .{keyCode | keyAlias} 修饰符在原生环境中无意义；
  
•  无法通过 vm.$el 获取界面元素，原生环境中没有 DOM Element；
  
•  无需自行调用 vm.$mount，默认会将入口组件挂载到原生应用的视图中；
  
•  不支持 v-html 和 v-text 指令。
  

功能差异，Weex 中仅引入 Vue Runtime 的功能，这样做除了可以减少代码体积以外，还能减少运行期编译模板的负担，提升性能。具体的差异有：

•  定义组件时不支持使用 template 属性；
  
•  不支持使用 x-templates；
  
•  不支持使用 Vue.compile。
  

样式差异，Weex 中的样式是由原生渲染器解析的，出于性能和功能复杂度的考虑，Weex 对 CSS 的特性做了一些取舍，使其更符合最佳实践：

•  Weex 中只支持单个类名选择器，不支持关系选择器，也不支持属性选择器；
  
•  在 Weex 中，写在组件 <style> 里的样式只能用在当前组件中，默认是 scoped 作用域。
  

编译环境的差异，在 Weex 中使用 Vue.js ，你所需要关注的运行平台除了 Web 之外还有 Android 和 iOS ，在开发和编译环境上还有一些不同点。针对 Web 和原生平台，将 Vue 项目源文件编译成目标文件，有两种不同的方式：

•  针对 Web 平台，和普通 Vue 2.X 项目一样，可以使用任意官方推荐的方式编译源文件，如 Webpack + vue-loader 或者 Browserify + vueify ；
  
•  针对 Android 和 iOS 平台，我们提供了 weex-loader 工具支持编译 .vue 格式的单文件组件；也就是说，目前只能使用 Webpack + weex-loader 来生成原生端可用的 js bundle。
  

两者更多差异，请阅读：《Vue 2.x 在 Weex 和 Web 中的差异》。

研发模式

较为合理的移动开发模式应该是单页研发、多页聚合，也就是先把一个移动应用拆成多个页面，每个页面可以独立设计和开发，中间通过路由方式或调度的方式串联起来。

这种方式和Web中的SPA方式产生一定的交集。SPA（single-page application）即单页化应用，它的优势在于避免了多个页面重复加载资源（所有资源第一次全部加载好，打成Bundle）；其次，可以方便地自定义专场效果；再者，它几乎没有页面之间的等待；此外，SPA与全局数据、全局状态共享可以做到天衣无缝地结合。

但在实际使用SPA的时，也遇到很多痛点，如页面首次打开的开销；内存管理问题，多个页面共享一个内存；原生路由的配合/开放规则的应对；所有页面必须基于相同的JS框架等问题。

那么Weex的研发模式又是如何实现的呢？

首先，Weex坚持每个页面一个JS Bundle；再者，支持原生的转场效果；同时，运行时优化、缓存和预加载也进行充分的实践；此外，还通过JS Service进行资源复用和全局数据/状态管理。

经过这些改进之后，即便非单页应用，Weex也可以实现页面秒开；同时，不同的团队/个人可以自由选择JS框架；还为内存管理提供了更好的引导，并支持原生&开放规则的路由。因此，是时候向SPA说再见了！

工程研发

从工程研发角度来看，Weex中Web开发过程必定需要如下几类上层建筑：

1. 初始化项目，因为前端越来越复杂，有很多环境需要配置，因此一个优秀的、极度简单的脚手架变得越来越重要，建议使用weex-toolkit或vue-cli；
   
2.  开发环境，前端主流编辑器均可应用在Weex中。
   
3.  调试，因为无法完全在浏览器内调试，建议在真机情况下调试，目前Weex提供了端上预览、Hot-reload以及Native调试工具。
   
4.  测试，目前与Macaca测试框架结合使用。
   
5.  打包，目前社区有多种打包方式供选择，如webpack/babel/postcss。
   
6.  发布，发布目前不是某个具体的工具，但每一家公司都会有自己搭建、发布、缓存推送的平台，也可以沿用Web研发的最佳实践。
   
7.  监控，可以采用曝光埋点、交互埋点等方式，也可以沿用Web研发中的监控最佳实践。

其它注意事项

在具体实践中，总结了一些具体事项：

•  长列表性能优化 ，可以<list> / <cell>对内存做进一步回收，有一点需要注意的是默认对图片进行回收（即图片在可视区外会自动回收）；
  
•  流式渲染，通过append=“tree|node”可以控制渲染的颗粒度，进一步优化首屏渲染效果；
  
•  View嵌套层级不宜过多，最好不要超过10层；
  
•  推荐 Devtool 真机调试。