基于React和Vue，移动端开源项目Weex如何定义未来

【.com原稿】今年在不同的场合，很多人都在说这句话：互联网的发展已经进入拐点，而移动互联网已经进入下半场。在互联网已经到达新交互形式和新计算方式拐点的今天，不断面临着如何产生更好的内容和交互方式的挑战。互联网的每一次进步和发展，都代表着通过更加开放、统一、标准的架构连接未来变化的可能。如果说React的出现是要在整个移动客户端领域建立一个并行研发的新秩序，那么我想Weex或许可以在2017年以及未来的日子里建立起组件生态的新技术。对于HTML5前端的所有应用范围，在过去的Web时代，我们面对的能力大多是由浏览器提供的，作为程序运行的容器，将不同浏览器提供的API作为标签来实现称呼。在如今的智能时代，硬件不断升级，浏览器作为主要的API提供者已经不能满足应用场景的需求，硬件能力已经远远超出了浏览器的范畴。因此，随着未来移动领域硬件能力的提升，意味着具备专业能力的组件。2016年12月15日，阿里巴巴Weex团队的一位同学向笔者分享了Apache接受阿里巴巴开源产品Weex捐赠的消息，有望成为中国移动最大的Apache项目。相信Apache严谨开放的技术氛围会给Weex项目更多的研发思路，当然也代表着Weex开源、社区化、国际化的决心。那么，开源的Weex是一个怎样的移动前端跨平台项目呢？借助Weex最近公测的v0.9.5版本，我们来谈谈Weex对移动开发者的核心创新能力。Weex连接Web->Native。可以说，近几年移动端的发展趋势是依赖于Web端。以ReactNative为代表的JS-Native在很大程度上模糊了Web和Native应用的界限。Weex的出现，真正将Web工程系统与Native连接起来，提供了更多的能力扩展，将这一进程向前推进了一大步。为了能够对上层业务调用更加规范透明，Weex继续实现HTML5、JS、CSS方式实现移动端跨平台解决方案，是未来开发者应该关注的。通过上面简单的Weex页面，里面包含了Weex的描述，一张图片有两条文字。其实整个页面分为好几层，***：最上面是DSL，包括JS，CSS，JS，让画面更具交互性。第二层是VirtualDOM，可以让IOSAndroidH5保持三端的一致性，所以在架构层面必须要保证，同时在特殊的架构层面把H5当成一个独立的渲染端.这也是Weex跨平台构建UI的一套框架。它需要具备四个特点：1）轻量级：学习成本轻，整个SDK的量级相对来说比较轻。2）扩展性：支持将Native组件接入Weex，同时2具有URL拦截工作，在系统中注册模块扩展，完全自定义模块扩展，并提供一些Modules，以及最新的dom，Steam都支持，一个JSService，类似JSService***的依赖管理机制。业务方可以对组件和功能模块进行分散和横向定制。3）性能：对于移动端渲染更加直观，因此可以在帧率和内存上实现高速加载、高速渲染和体验过程。4）CPU：直接关系到功耗和运行效率，在不降低帧率的情况下减少内容的消耗。因此，首屏的渲染速度必然决定着用户体验的好坏。笔者记得在双11的主会场页面中，整个页面分为两部分。第一个分会场的框架完全用WeexJS编写。在加载过程中，肉眼是无法分辨的。据笔者统计，本地性能大约在100毫秒以内，肉眼无法分辨是Weex、H5还是Native。Weex自定义组件在整个Weex项目中分为5层：第一层是业务层，主要用于访问服务，以客户端的形式承载。第二层是中间件层，上面放了整个发布平台，预加载，组件，一些API。后面是toolkit层、DSL、Engine。接下来我们看一下整体架构的变化：Weex增加了Market层，包含了组件库，即DysAPI，同时也覆盖了一些业务相关的API和Cookie机制，Shema拦截机制，front-端店、API支持、工具支持等全站支持。研发支撑层在业务快速扩张的情况下，为发布、灰度、在线监控提供封装。下面笔者着重分析Market层能够解决的核心问题。市场具有快速发布组件、更新和维护它们的能力。可以简单理解为开发者自己制作组件，然后通过Market实现组件秒级增删改查，更符合大家的技术思维。根据下图所示的工具大图，可以帮助开发者围绕SDK、Devtools、Playground的能力快速调试试错。通过WeexPack创建一个完整的Weex应用，添加开发者自己编写的组件，并从Market下载。找到更多好用的组件后，***就可以通过WeexCLi完成所有Weex相关的操作了。与Vue的结合说到Vue，笔者不得不重点说一下。去年以来发展迅速，越来越多的重点项目已经投入使用。这些项目包括饿了么、稀土掘金、苏宁易购、神马搜索、长听科技、荔枝FM、手机淘宝、方多等优秀项目。根据笔者个人的理解，有桌面端、移动端、面向用户和后端等。整个vue开发体验非常愉快，每个页面都有对应的vue文件。另外，它更适合组件化开发。遇到比较复杂，需要父子组件频繁通信的场景可以用vuex来完成。总的来说是一个非常好的项目。Vuejs是一个渐进式框架。用作者游雨溪的话说，“让高大上的东西平易近人”，它语法简单，同时解决复杂的问题，解决的非常好。回过头来说说Weex，选择和Vue.js这样优秀的项目合作，擦出了很多火花。第一个是流式渲染。Weex可以控制第一次渲染后加载的粒度。这个特性让Weex达到了Vuejs的水平；二是Vuejs中一个非常经典的双向数据，开发者非常喜欢。绑定，从Vuejs到Weex。三是Weex的管理内容，避免内存泄露，保证应用的长期稳定。在整个合作过程中，Weex基本融合了Vuejs的优点，基本解决了目前开发中的所有问题。基于Vue2.0，建立了更快更好的HTML5渲染引擎，支持Transition过渡动画的编写，这也是Weex和Vue合作带来的五个特性。下面，笔者简单梳理一下Weex中Vue2.0的特性增强列表：流式渲染逻辑控制，优化首屏渲染时间双向数据绑定，方便表单空间逻辑编写，安全管理多实例内存，避免内存泄漏，并保证长期应用稳定直接基于Vue2.0构建更快更好的HTML5渲染引擎支持过渡动画编写同时，Weex在周边工具上也全面适配Vue2.0，包括Loader，Cli，开发者熟悉的router等等，对于HackerNews，Weex暂时不能做服务端渲染，但是其他功能涵盖了HackerNews的所有版本。下图：Weex生态演进对于Weex这样一个开源项目，我们如何理解它以及后续的生态演进过程？笔者在与淘宝FED负责人元鑫交流时，其实也是这么想的。今天的Weex可以这样理解，大致分为两层。一层是引擎层，另一层是框架层。用前端的话来说就是浏览器的渲染引擎，比如V8，或者WebKit，一个是上层框架。其实Weex不应该只是一个框架，而应该是两者的结合体。对于引擎来说，它是不断进化的，不会随着时间的推移而消失。对于一个框架来说，可以是React，也可以是Vue，但是以后用什么还是未知数，所以整个前端框架层的发展更新非常快，基本上是两三年一次。在圈子的中心，Weex应该是一个包括了引擎层和今天的框架层的解决方案。事实上，今天的React已经把它当作一个标准，就像W3C一样，但是API的实现是由各个浏览器厂商决定的。如果我们把React当成一个标准，然后和Weex引擎做曲线对接，笔者认为所有的API都可以在React语言上开发。就像与Vue一起工作一样，将优势融合在一起，充分满足开发者的需求。那么基于React标准渲染引擎，我们来看一下整个实现图：在这个实现图中，我们可以看到分为3层，第一层是上面的原始React，然后是虚拟DOM，以及然后是driverLayer（可以理解为适配层），可以适配不同的容器，包括Natvie容器，HTML5容器，以及整个PC的Web容器，这样整个引擎的一切都可以产生后端。我们来看看RAX融合后的三大特点：第一个是跨容器，通过中间的驱动层实现Native和Web；二是轻量级，可以看作是一个标准层，可以自我实现，在实现过程中，本身弥补冗余时间的过程只有原来体积的四分之一；三是标准，基于W3C标准，维护所有开发者的习惯和开发经验。所以合作的碰撞才能塑造Weex的生态，慢慢赋予它生命力。在这个过程中，团队可以积累DSL标准，让无数的前端框架和解决方案得以整合、渗透到系统中，开放给开源社区更多的开发者。【原创稿件，合作网站转载请注明原作者和出处为.com】