Weex详解：灵活的移动端高性能动态化方案
稿源：阿里百川专区的网站
在2016年4月份的QCon上，阿里巴巴资深总监，淘宝移动平台及新业务事业部、阿里百川负责人庄卓然（花名南天）宣布阿里移动端跨平台开发框架Weex开始内测，并将于6月份开源。在QCon的第二天，阿里技术专家徐凯（花名鬼道）和阿里前端开发专家赵锦江（花名勾股）向参会者做了《Weex&&灵活的移动端高性能动态化方案》的演讲，对这一技术方案进行了详细的剖析。
以下为演讲内容的整理：
昨天南天宣布Weex启动开源内测，截至到今天中午，我们统计申请内测用户突破1400人，大家的热烈程度远远超过我们的设想，非常感谢大家支持。
在我们对移动开发最佳实践的思考中，我们认为移动开发的未来是更平衡的方案，一定是性能和动态性兼得。第二个，它一定是开放互联的，PC端一直也是这样的，也是非常好的状态。我们觉得移动互联网将来肯定也是基于更大众化的技术体系，没有平台之间的隔阂，简单直接易用，这是我们最希望看到的。基于这些设想，我们有了Weex方案。
Weex是从去年双十一的时候第一次在我们正式产品中使用，承载了双十一主会场的工作。有人会问，Weex是不是除了做主会场别的地方就比较吃力呢？从去年双十一到现在，包括我们自己的尝试和阿里内网做开源内测活动，大家也贡献了很多内容，包括昨天Keynote演示的僵尸动画，扫雷、计算器都有，各种丰富场景的东西都可以通过Weex做出来，不仅仅是做主会场的技术方案。
对移动端开发模型的理解
我们谈谈Weex团队对移动端开发模型的理解。
今天绝大多数移动端APP是这样一个最佳实践，首先把移动端所有界面拆分成各个page，中间有一个路由的控制逻辑。同时我们需要移动端各种各样丰富的能力，通过API的形式提供给开发者。这是我们认为一个比较理想的开发模型。
从开发模型来讲，我们比较倾向于通过标准化的一些东西，包括HTML、CSS、JS这些前端非常快速易用好学的语法作为一个开发体验，提供给开发者。这里强调一下，我们语法设计尊重了Web标准，包括核心源代码都是从Vue.js&&一个非常优秀的MVVM前端框架来的。我们的开源内测同步在海外通过Vue.js的Twitter等途径进行宣传，得到了非常热烈的反响，短短一天时间内，老外们的关注度和热情也是出乎我们的意料。有些人非常兴奋和激动，想知道什么时候看到源代码，和我们联系，我们觉得也是值得高兴的一件事情。
Weex的组件化与DSL语法
Weex编写的页面天然的支持组件化，首先，我们的界面可以是一个组件化的，把一个复杂界面分成每个组件，刚才演示的都是简单的组件，每个组件都可以看成是一段template，style，script，放到模型里，对应到界面的结构，样式细节，行为定义。在view里面我们倾向于把数据和视图当中需要展示和需要有动态变化的部分做一个数据绑定，绑定之后我如果想更改界面的话，通过改变数据就可以做到。这是从model到view非常顺畅的控制逻辑和代码方式，这也算是Weex上层语法设计的基础。如果大家做的界面比较复杂，可能有更多细节，或者做更多分解，我们需要从整体上对整个界面以模块为单位作为拆解，对每个模块做定义，如果界面足够复杂，可以先拆成组件，再把每个组件具体内容进行定义。定义方式就是通过结构、样式和行为角度对它进行定义，通过有机方式把这些组件结合起来，完成页面开发。
关键语法简述。首先看看template，大概有几个元素。它首先是virtual DOM tree展示，包括事件绑定，组件跟组件之间还可以嵌套，还可以有子元素，这是整体template结构。再往下是style，一方面可以把共用样式抽样出来，另一方面可以让template结构更加清晰，不至于陷入到整个具体样式描述当中去。我们在这边会做一些收敛，我们只支持了单个class的selector写法，主要从性能角度考虑。传统的css可以理解为是一个N对N的数据库，匹配过程非常复杂，性能也得不到非常好的保证，我们为了保证性能，我们把selector约定在单个class，性能可以保证。
另外，我们的样式天然默认的就是scoped，大家可以放心定义各种各样的classname，不担心和其他组件相冲突，全局冲突是CSS&七宗罪&中的一个，其实这也是我们非常重视的，所以在实践上我们把它做到了scoped。
其他的，可以做一些展示的控制，比如if、repeat刚才演示中也提到了。刚才没有演示到的这个很特殊，append，在性能不是那么好的Android下，界面加载过程用户是可感知的，不是一瞬间做到的。我们加这个值可以让你精细化展示界面的颗粒度，如果上层做了append等于tree的话，里面一系列东西会做一次性的加载，这是从性能优化角度做的特殊设计。再是id，我们可以通过在这里面写id拿到这个值，把它当作参数传给API做处理。
我们现在已经支持的组件，除了刚才演示的div空白容器、图片、文本之外，我们还支持slider：一个性能比较好的滑块组件，还有list，性能上自动做内存管理和资源管理的组件，把性能和帧率各方面都做的比较好。还有input，输入框我们是最近才做的，也是刚支持的，可能还有试验性阶段的小东西。在这个范围之外，业务方可在上层横向扩展，稍后会有具体介绍。这是template和style部分的介绍。
样式部分我们支持flexbox，非常灵活通用便捷的布局方式，有了flexbox，只要你的界面可以拆分成豆腐块的，都可以用flexbox来做，同时我们还做了fixed和sticky这两个特殊的布局，sticky意思是如果有一个列表分类，比如联系人ABC字母滚到屏幕外，会停在最上面，那个效果就是sticky，当你划走它就会跟着走，在各种手机应用当中是一个比较常见的东西。同样，更多的样式每个组件也可以自己定制，非常灵活。
从事件角度，click是基础事件，change在表单的值改变和滑快的第几帧改变时都会有，同时我们加入了appear和disappear，当我通过任意操作进入屏幕区域内，会触发appear事件，出来以后会触发disappear事件，非常适合用在一些lazyload之类的逻辑场景。这些事件也可以在各自组件中做横向扩展。
Script部分刚才例子也提到了，主要是viewmodel设计，最主要的是data和methods，值修改之后相应数据绑定的值也会发生改变。除此之外我们提供了生命周期的方法，创建的时候，数据监听完成的时候，渲染完成的时候，你只要把这三个方法同样写在data和methods下面。还有原生 API，刚才演示的时候也出现了，这里不多介绍。
组件化搭建很复杂，通过定义子组件，比如我上面有一个foo组件，通过foo标签就可以把foo嵌入到别的组件中来，数据传递的话就可以在foo组件中写a和b，foo元素就可以通过这种方式传递给子元素，然后进行处理。再是组件中间的通信，也是事件机制，每个组件可以通过和off，对自定义事件进行监听和解绑定，想触发事件也有三个方法：只传给自己、dispatch向上冒泡给所有父组件、$broadcast广播给所有子组件，这些设计和Vue非常相近的，做到组件之间的通信。
除了刚才介绍的这些特性，我们未来还会提供更丰富的、相信也是开发者需要的、平时开发中会碰到的场景，更丰富的表单，还有更好的动画展示，包括复杂手势场景。在这方面，无论是性能还是开发体验、最终效果都能够非常好，这是团队正在努力在未来提供给大家的。同时我们希望收集和分享更多相关素材，做出更多工具，提供更好的开发者体验给大家。
更多的内容，包括刚才演示的Playground App都可以通过我们的官网找到，现在处在开源内测阶段，大家提交申请，通过以后可以访问仓库，了解更具体的内容。
Weex的工作原理
这张图大家都不陌生，前面也提到了，勾股说的主要是DSL这层。再往下到了Virtual DOM和Render层；H5，我刻意把它用不一样的颜色标出来，想让大家知道我们设计之初就考虑到希望在三端上能够展现，所以这个地方稍微加亮一些。
我们把刚才这张图再稍微展开一下，最上面是我们的DSL，我们一般叫Weex文件，通过transformer这层，部署到Server，服务端就完成了。大家不用担心我们的转换是不是有性能问题，因为这在服务端就已经完成。到了客户端，第一层是我们的JS-Framework，最后到RenderRengine，再往下看，左边是我们的DSL文件，右边是转换出来的jsbundle，在DSL中的template会将我们的类型和子节点都表示出来，将classList转化成基本语法约定，包括自变量的转换。最后是脚本，脚本基本上是直译过来。输入是Virtual DOM输出是native或者H5 view，还原成内存中的树型数据结构，再创建view，把事件绑定在view上，把view基本属性设上去。虚线是在native上经历一个过程，在H5上相当于把这个事情交给webkit LayoutEngine去做，把所有元素尺寸和位置重新调整。整个这张图基本上讲清楚了Weex Render流程，我们会分三个线程，不同的线程负责不同的事情，让JS线程优先保障我们的流畅性，未来我们会有更多的技术文档，比较细节的放出来。
Weex的性能、扩展以及可用性
下面是在整个Weex架构上比较关键的点，这些可能是我们目前关注度最高的，包括性能、扩展以及可用性。
首先是性能，我们内部有这样一个压测页面，我们同学把benchmark放在Playground，大家如果下载是能够看到的。在我们内部做压测的时候调到三千个节点，大概10屏，一屏有三个卡片，一个卡片有100个节点左右。我们看一下数据，第一个性能对比是我们的加载时间，同样一个页面，也不算特别大，20%左右，帧率大概差开一帧，scroller差不多，内存这块会好一点，因为我们这边用了recycle view，会好一些。再往下是CPU，静默CPU消耗，还有运行过程中CPU的峰值。静默CPU接近0点几，我们不做16毫秒的轮循，如果做16毫秒轮循CPU会更高一些。
这是一个真实业务数据，3月份页面上线之后我们看了一下，这张页面是一个活动，3月份新风尚的活动，这个活动页面没有用List，没有特别做内存对比，这两个设备定义为低端机，帧率差压比较明显，无论是数据还是实际中的体验，流畅性大概是这样的差距。我们说性能往往都会提到帧率、加载时间，但往往会忽略一个事情，Native UI开发中通常没有JS资源在服务端加载，Weex以及类似动态化方案有一个副作用，我们有一个JS必须从服务端下载，我们把JS内置到客户端里，免除下载的问题，这里涉及到一整套的策略。我们内部有一套机制，之后会把这套机制作为独立的技术产品开放出来。
下一个是我们的兼容性。兼容性不只是对Weex，对偏内核型项目都会有这个问题，举一个Weex例子，第一排是我们的业务代码，再往下看，上面两次变迁，一直到客户端，整个场景会变成N的立方。举一个具体数字，我的业务代码改了三个版本，（英文）三个版本，最后会有三的立方27个场景。兼容性是我们一直重视的问题。我们做了几件事情，首先单测保证，包括JS和H5的单测，保证最最基础的UT本身带来的含义。第二个是JS单测环境，我们一般会将（英文）跑在（英文环境下，但和JS安全还是有差异。再往下是自动化工作，这块工作细分也可以分成两块：一块是我们针对截图比对，比如我们同学会说我们设置了很多各种各样细节属性，怎么说你渲染出来的就是你实际想要的，通过API级别的效果不是很好。所以这种我们会通过截图，将最终产生的结果和我们意料中的结果进行图形比对，比较老的成熟的内核上面做的比较成熟，也会有一些借鉴。另外是layout results，相当一部分，包括model，包括其他的布局类的，其实我们完全可以通过一个元素，最终它的宽高，左上角的点，通过基本的信息，让它完成测试的过程。所以我们经过这两块工作，一旦成熟，我们会尽快放到上面。
再就是扩展性，我们先回顾一下这张图，前面也有提到，目前Weex给大家直观的感觉是可以用Weex写很多页面，有一个路由机制，内部叫导航，帮助你将页面进行串连，我们提供很多features，由这样的形式构成Weex大家所看到的一个结构。细分来看，如果你扩展一个component，特定的一些方法，使用anotation标识输入输出参数。这是一个module，在DSL上看到的是API，底层就是module。如果扩展module也是一样的，这是很简单的跳转，基本信息带上去，实现业务功能，一个module就完成了，很简单。
这是路由，整个路由在APP Framework中只是一个环节，所以接下来的规划还是有许多东西需要做的，单独看components这块，包括前面两个，再往下是lifecycle考虑，再是动画跟手势，这块我们觉得都是最基础的东西。再往下是全局的多个Weex容器之间通信机制，数据存储、网络，包括下面涉及到的一堆传感器，包括基础的FS，还有偏业务类的东西，整个东西都有同步在做，但现在的工作集中是在这块。回到刚才的老问题，如果我们开放一个module，上层提供API，中间提供adapter，如果提供自由实现就将默认的覆盖掉，比如手淘里面（TBxxx），把默认页面覆盖掉（WXxxx），对大家来说在已有能力增强，或者是增加新的组件，或者是新的module上，目前已经达到这个状态。
最后是我们的可用性，前面说的比较多，这块秀几张图就好了。这是我们的工具链，红色代表完成的，黄色是五月份、六月份就会完成，在六月正式开源之前。剩下一些东西是我们内部正在讨论以及会安排时间逐步完成的东西，这些都是工具。我们首先给大家提供一个playground，可以扫码，也有自带的examples。第二个是调试工具，chrome dev tools常见的功能里面都有。再是脚手架，大家如果只是玩玩的话用playground就可以了，如果自己做一个独立的APP，你要用Weex做的话我们也会给你提供脚手架。我们的规划中独立项目，不是最终的名字，最终会有一个类似APPHub的工具。包括信息察看，在界面上展示结构。这是刚才提到的例子，这个是playground里面的，虽然截图是iphone效果和android是完全一样的，已经用Weex现有功能做出比较好玩的组件库。然后是我们的文档，包括项目guide、reference、toolchain，细节我不多说了，大家可以去看看。
Weex的集成方式
目前Weex有三种集成方式：
o 目前支持单页使用或整个app使用weex开发（还不完善，需要开发router和生命周期管理）这是主推的模式，可以类比RN。
Native Component模式&
o 把weex当作一个iOS/Android组件来使用，类比ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，和业务同学沟通下来这类Native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是Weex的重点。&
o 这也涉及到如何让Native同学快速上手&准Web&开发，有意思的话题，大家多给些建议。
H5 Component模式&
o 在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短期内无法完全转为Weex全页模式（或RN），比如猫超、互动类页面、一些复杂频道页等。针对这个痛点我发起过WVC项目，并在实际业务中验证了这样的想法：在现有的H5页面上做微调，引入Native解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。&
o WVC将会融入到Weex中，成为Weex的H5 Components模式。&
这3种模式几乎涵盖了淘系业务上的动态化需求（针对Native）或体验提升需求（针对H5）。更有趣的是这3种模式的技术基础是一致的，这非常重要，意味着：业务方可以使用Native或H5 Component模式 解决实际的业务痛点，同时平滑过渡到Weex全页模式。期待Weex成长壮大到AppFramework的那天。
最后是我们过去双十一到现在大概五个多月时间做的一些事情。首先我们做了原型版本，再将原型版本独立出独立客户端可使用的SDK，扩展样式和布局，将基础的component做了扩展，这两个月集中在工具，还有open source上的工作，最后是六月底就会开放出来。
阿里百川（)是阿里巴巴集团&云&+&端&的核心战略是阿里巴巴集团无线开放平台，基于世界级的后端服务和成熟的商业组件，通过&技术、商业及大数据&的开放，为移动创业者提供可快速搭建App、商业化APP并提升用户体验的解决方案；同时提供多元化的创业服务-物理空间、孵化运营、创业投资等，为移动创业者提供全面保障。
文章：39篇人气：12774
阿里百川（)是阿里巴巴集团的无线开放平台，通过“技术、商业及大数据”的开放，为移动创业者提供可快速搭建App、商业化App并提升用户体验的解决方案。
本网页浏览已超过3分钟，点击关闭或灰色背景，即可回到网页　　12月15日，阿里巴巴宣布将移动开源项目Weex捐赠给基金会开始孵化，Weex有望成为中国移动领域的首个Apache顶级项目，这意味着中国移动技术开始反哺世界。据悉，这也是继JStorm、RocketMQ之后，阿里向Apache捐赠的第三个项目。　　日，阿里巴巴宣布将移动开源项目Weex捐赠给Apache基金会开始孵化　　Weex是阿里自研的高性能跨平台移动开发框架，最大的特点是解决了频繁发版和多端研发两大痛点，一套Web代码完美适配iOS、Android、H5、Web等多端，极大地解放开发者的同时又保证了用户体验。　　去年双11的秘密武器Weex，今年6月底正式开源，与全球开发者共享中国的移动互联网技术成果。除了轻量、高性能、可扩展、一次撰写多端运行等诸多优势，Weex还提供了强大的调试工具协助开发者排查问题。　　阿里巴巴资深技术专家，Weex负责人吴志华表示：“我们希望将Weex做成移动开发交付的统一技术标准，正如PC时代从过渡到Web一样，Weex希望通过自己的努力为移动时代的技术进步做出贡献。”　　Apache基金会是和互联网行业最知名的开源组织之一，旗下的Apache&HTTP服务器、Tomcat&Servlet容器、Hadoop分布式计算框架等众多开源产品轮番引领了上世纪九十年代到今天的多次技术浪潮，可惜来自中国的项目一直寥寥无几，尤其在移动领域全面缺席。Weex将是Apache旗下首个由中国团队主导的移动项目。　　“加入Apache基金会表明了阿里巴巴在推进Weex开源、社区化以及国际化的决心。”阿里巴巴开源委员会负责人刘昕表示，“Apache严谨、开放的技术氛围会带给Weex项目更多的研发思路，阿里也欢迎更多的Apache社区专家参与进来，一起把Weex建设成开发者最信赖的移动跨平台解决方案。”　　Weex目前已经在、天猫等多个阿里APP中投入使用，并在大规模复杂应用场景下经历了全面的锤炼打磨。在刚刚过去的2016双11中，近2000个页面采用Weex渲染，会场覆盖率高达99.6%，主会场秒开率高达97%，性能和稳定性均表现优异。　　取代HTML5成为双11阿里移动业务交付方案，标志着Weex进入工程大规模应用成熟期。　　2016年4月，阿里宣布Weex开源内测，短短两周就有超过5000名开发者申请。6月30日正式开源首日就登上Github趋势榜首位，截止11月底在Github上已经获得了超过9000个star和1000次fork数，成为中国今年在Github上最热门的开源项目。　　日，阿里无线技术团队宣布Weex正式开源后兴奋地合影留念　　除阿里移动技术力量外，社区贡献者也踊跃参与，包括著名前端框架Vue.js创始人在内的多位技术大牛已经开始参与Weex的改进;众安保险、苏宁、优酷、饿了么等企业用户也在积极的接入之中。　　“Weex不仅应用灵活、性能强大，而且能让前端开发者最大程度复用现有技术积累，帮助我们用最少成本设计全新的跨平台架构体系，并尽快进入实施阶段。”众安保险技术总监陈天予反馈到：“Weex积极拥抱Web标准，专注于Native渲染层优化的细致工作，也清晰地展示了这个项目的自身定位和发展方向。”　　据悉，Weex目前正在迁移整个开发环境到Apache研发基础设施,&阿里将会和Apache社区专家一起加快Weex的开发进度，并将采用更加严谨的版本发布策略。可以预见，未来会有更多来自全球的移动开发者从中受益。阿里移动开发框架Weex大会1月12日召开：揭秘天猫如何完成双11大考
阿里移动开发框架Weex大会1月12日召开：揭秘天猫如何完成双11大考
Weex作为阿里开源的跨平台移动开发框架，开源至今倍受业界关注。日，阿里巴巴宣布将移动开源项目Weex捐赠给Apache基金会开始孵化，Weex有望成为中国移动领域的首个Apache顶级项目。Weex大会将于日召开，并通过云栖社区全程独家在线直播。该活动就是为了让更多人了解和交流关于Weex技术的最新发展动态，本次Weex大会也将是Weex团队首次集体亮相。Weex大会直播地址：点此参加本次Weex大会的主要嘉宾有：阿里资深总监庄卓然（南天）、阿里资深无线技术专家吴志华（天施）、阿里高级前端开发专家徐凯（鬼道）、阿里高级前端开发专家程劭非(寒泉)、Vue.js作者尤雨溪等。大会由上下午组成，上半场是关于Weex的Keynote演讲，下半场包含技术实践和业务实践两个分论坛。在下午业务实践分论坛，有两场关于Weex在双11中的技术实践，分别是阿里无线技术专家凝砺带来的《Weex的性能优化与双十一实践》分享，以及天猫前端开发专家伯禹带来的《基于Weex的双十一会场搭建之路》，介绍Weex如何经得住双11大考的实战。同时，本次大会也会分享Weex最新的技术特性、技术工具、技术能力。Weex Conf活动正在预报名阶段，报名地址：/m/9003/
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
百家号 最近更新：
简介: IT之家，爱科技，爱这里。
作者最新文章阿里移动开发框架Weex大会1月12日召开：揭秘天猫如何完成双11大考 - 阿里巴巴,Weex - 业界 - 科技讯
阿里移动开发框架Weex大会1月12日召开：揭秘天猫如何完成双11大考 - 阿里巴巴,Weex
Weex作为阿里开源的跨平台移动开发框架，开源至今倍受业界关注。日，宣布将移动开源项目Weex捐赠给Apache基金会开始孵化，Weex有望成为中国移动领域的首个Apache顶级项目。Weex大会将于日召开，并通过云栖社区全程独家在线直播。该活动就是为了让更多人了解和交流关于Weex技术的最新发展动态，本次Weex大会也将是Weex团队首次集体亮相。Weex大会直播地址：点此参加本次Weex大会的主要嘉宾有：阿里资深总监庄卓然（南天）、阿里资深无线技术专家吴志华（天施）、阿里高级前端开发专家徐凯（鬼道）、阿里高级前端开发专家程劭非(寒泉)、Vue.js作者尤雨溪等。大会由上下午组成，上半场是关于Weex的Keynote演讲，下半场包含技术实践和业务实践两个分论坛。在下午业务实践分论坛，有两场关于Weex在双11中的技术实践，分别是阿里无线技术专家凝砺带来的《Weex的性能优化与双十一实践》分享，以及天猫前端开发专家伯禹带来的《基于Weex的双十一会场搭建之路》，介绍Weex如何经得住双11大考的实战。同时，本次大会也会分享Weex最新的技术特性、技术工具、技术能力。Weex Conf活动正在预报名阶段，报名地址：/m/9003/
换一换
& 科技讯版权所有下次自动登录
现在的位置:
导 读：今天在移动端，尤其是像手机淘宝这样的 app 中，动态性问题逐渐成为一个比较棘手的问题。所谓动态性，就是把移动应用本身的灵活性、迭代更新的周期和成本优化到极致。比如手机淘宝的店铺首页，它允许 商家实时装修自己的店铺，更新自家的商品、活动等信息；再比如淘宝、天猫每次大促的会场页面，要求我们非常灵活的及时调整界面信息和状态，确保在瞬息万变 的活动当天紧跟促销节奏，应对各种突发情况。
为什么要解决动态化的问题
动 态性需求的出现有很多必然的因素：我们的移动应用背后是一个平台级甚至是生态级的电商系统，它需要有海纳百川的能力和高速流通的特点，市场上很多移动应用 也有类似的客观形态和诉求；同时整个行业迄今为止在移动端的积累都还不足以对产品形态、用户体验、交互方式等细节有完全的前期把握，一个移动应用，客观上 需要更多的尝试和探索，甚至是“试错”，而这种动态化的程度和产品迭代演进的速度有着强烈的正相关；第三，我们不必要为这些动态性在多个端投入重复的精 力，更不应该因此而频繁的触发新版本。所以动态性问题在今天的移动端显得尤其重要。
动态性问题的历史
动态性问题不只是移动端特有的，在互联网技术发展的历史长河中，桌面端也存在并经历着类似的事情。今天桌面端的结论似乎已经形成，那就是 W3C 长期倡导的
(或被称为 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，我们在学习成本、开发习惯方面为业务同学考虑了很多，这样的话业务同学可以很快的学习和上手，并且保证代码 的规范性和可读性 (这里要特别鸣谢一下
及其作者，我们在上层 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 的核心优势不断解决更多的问题，甚至不仅解决动态性这个历史难题，还可以进一步解决跨端重复开发、用户体验一致性、容器通用技术规范等问题；甚至不仅解决 手机淘宝、手机天猫的问题，还可以解决阿里巴巴兄弟团队、国内甚至行业内的普遍问题；体现出更大的价值！当然这一切看起来天马行空的梦想需要我们脚踏实地 的一步一步走出来，始终保持清醒的头脑，围绕 Weex 的核心价值，聚焦在核心的问题上，也非常希望可以借助整个大团队、整个集团乃至整个技术社区的力量。
Weex 团队会紧抓移动端动态性这个关键命题，围绕 Weex 的三大特点：轻量、高性能、易扩展，进行周期性的迭代和完善。我们会在更简单直接的实践方式、更高的加载/启动/渲染/交互性能、更强的去中心化定制性和 横向扩展性方面不断突破和创新。并定期在集团内开放最新的版本和文档、配套工具、周边生态等。
随 着 Weex 新版本的不断迭代，我们同时也会面向集团范围内的业务方，采取更开放的沟通和服务策略，深入到业务中，了解大家在实践中的真实诉求和痛点，同时提供 Weex 的技术支持。在保障 Weex 的实践效果和产出的同时也会汲取更多信息和灵感作为后续 Weex 努力和完善的重要参考。
团队在长期的迭代和业务支持上会逐步找到一个稳定的节奏，并且做好打持久战的准备。随着工作的进展和不断深入，我们相信 Weex 可以走出一个“扇形”，并一步步的实现大家期待种的宏伟蓝图和远大设想。
关 于开源：团队始终认同一个观点——开源并非一个简单的行为，而是一个过程和最终的结果构成的整体。团队希望 Weex 能够逐步解决更普遍的业务问题，尽可能的保障工程质量和代码质量，并发展成为能够被社区接受、参与和信赖的技术方案。体现更大的价值，同时得到更多的支持 和更快的发展。这是我们希望的，也希望是大家希望的：）
来源：InfoQ
【上篇】【下篇】
您可能还会对这些文章感兴趣！
百度站内搜索
同分类最新文章}