欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识！
您现在的位置是： 首页

Weex和Web开发体验的异同

程序员文章站 2024-03-16 10:32:04
...

点击打开链接

Weex和Web开发体验的异同

场景研读 2017-01-20 10:25:02 浏览976 评论0

内存管理 web开发 Weex WeexConf 研发模式

摘要： 在2017年1月12日 Weex Conf 2017下午的技术实践论坛上， Weex团队的勾股详细讲解了Weex和Web开发体验的异同。他主要从Weex 中的 Web 标准、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个，具体组件如下图所示。

Weex和Web开发体验的异同

相比于完成的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和Web开发体验的异同



在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 中的差异主要体现在平台、功能、样式、编译环境上，下面来一一解读。



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 中的差异》。



研发模式



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



Weex和Web开发体验的异同



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



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



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



Weex和Web开发体验的异同



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



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



工程研发



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






    

  1. 
初始化项目，因为前端越来越复杂，有很多环境需要配置，因此一个优秀的、极度简单的脚手架变得越来越重要，建议使用weex-toolkit或vue-cli；
    

    2. 

  2. 
 开发环境，前端主流编辑器均可应用在Weex中。
    

    3. 

  3. 
 调试，因为无法完全在浏览器内调试，建议在真机情况下调试，目前Weex提供了端上预览、Hot-reload以及Native调试工具。
    

    4. 

  4. 
 测试，目前与Macaca测试框架结合使用。
    

    5. 

  5. 
 打包，目前社区有多种打包方式供选择，如webpack/babel/postcss。
    

    6. 

  6. 
 发布，发布目前不是某个具体的工具，但每一家公司都会有自己搭建、发布、缓存推送的平台，也可以沿用Web研发的最佳实践。
    

    7. 

  7. 
 监控，可以采用曝光埋点、交互埋点等方式，也可以沿用Web研发中的监控最佳实践。

    8. 




其它注意事项



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






    

  • 
 长列表性能优化 ，可以<list> / <cell>对内存做进一步回收，有一点需要注意的是默认对图片进行回收（即图片在可视区外会自动回收）；
    

    • 

  • 
 流式渲染，通过append=“tree|node”可以控制渲染的颗粒度，进一步优化首屏渲染效果；
    

    • 

  • 
 View嵌套层级不宜过多，最好不要超过10层；
    

    • 

  • 
 推荐 Devtool 真机调试。

    • 








 





Weex和Web开发体验的异同

用云栖社区APP，舒服~





【云栖快讯】2017云栖大会·成都峰会 5月23日开幕！十余场技术论坛，百余名分享嘉宾，更有重磅发布。现场坐席有限，报名倒计时中！  详情请点击





					

															

						相关标签：												
							web开发						
												
							Weex						
											

															

						

							上一篇：							
								自定义Weex组件——Weex的学习之路（八）							
						

						

							下一篇：							
															
						

					

															

						

							推荐阅读