“weex详解 灵活的移动端高性能动态化方案”

本篇文章5768字，读完约14分钟

年4月的qcon上，阿里巴巴高级总监、淘宝移动平台和新业务事业部负责人阿里百川庄卓然(花名南天)表示，阿里移动终端跨平台开发框架weex将于6月开始内部测试和开源 qcon次日，阿里技术专家徐凯(简称桂岛)和阿里前端开发专家赵锦江(简称毕达哥拉斯)向与会者发表了“weex柔性移动端高性能动态化计划”的演讲，详细分解了该技术方案。

昨天南天宣布weex将开始开源内部测试。 截至今天中午，据我们统计，申请内部测试的顾客人数超过1400人，大家的热情远远超出了我们的预期。 非常感谢大家的支持

在考虑移动开发最佳实践时，我们认为移动开发的未来是一个更平衡的过程，需要性能和动态性。 第二，必须开放互联，pc端一直如此，状态非常好。 我们相信，未来的移动网络将建立在平台之间没有障碍、简单、直接、易于使用、更加普及的技术系统之上。 基于这些假设，我们有了weex方案。

weex是自去年双十一销售节以来首次被用于我们的官方产品，双十一销售节承载着双十一销售节主会场的员工。 weex比主会场难吗？ 从去年的双11艺术节到现在，我们自己贡献了很多文案，包括使用阿里内网尝试开源和内部测试活动。 包括昨天演示的僵尸视频、扫雷和计算机在内，各种丰富的场景在weex上制作，不仅仅是比较主会场的技术处理方案。

首先谈谈对weex团队移动开发模式的理解。

目前，大多数移动应用程序都是这样的最佳实践。 首先，所有的移动接口被分成页面，中间有路由控制逻辑。 此外，还需要移动端的丰富功能，并作为api提供给开发者。 在我们看来，这是理想的快速发展模式。

关于开发模式，我们倾向于用html、css、js等稍微标准化的东西作为开发体验提供给开发者。 这些东西在前端非常快，非常简单。 这里需要强调的是，语法设计尊重互联网标准，包括来自非常好的mvvm前端框架的核心源代码。 我们的开源内部测试在海外展开，得到了非常热烈的回答。 短短一天，外国人的关心和热情出乎我们的意料。 有些人很兴奋，想知道什么时候能看到源代码，就联系了我们。 我们觉得这也是幸福的事情。

weex的页面自然支持组件化。 首先，我们的接口可以组成，一个很多复杂的接口可以分成各个组成部分。 刚才演示的组件都是简单的组件，每个组件都被视为一个组件放入模型中，对应于接口的结构、格式细节、行为的定义。 视图倾向于将数据绑定到视图中需要显示和动态更改的部分。 如果希望在绑定后更改接口，可以通过更改数据来实现。 它从视图上看是一种非常流畅的控制逻辑和代码模式，也是weex上层语法设计的基础。 如果你的界面多而复杂，可能会有更多的细节和更多的分解。 必须将整个接口分解为模块，并定义每个模块。 如果接口足够多且复杂，可以将其分解为组件，然后定义每个组件的具体副本。 定义方法从结构、风格、行为的角度进行定义，将这些组件有机结合完成页面开发。

重要语法概要。 首先有几个要素。 首先由virtualdomtree演示。 这包括事件绑定、组件和子元素的嵌套。 这是整个模板结构。 下面是风格。 虽然可以采样一般的格式，但是也可以更明确模板结构而不陷入整个特定的格式描述中。 在这里收敛一点。 我们只支持一个类的选择器创建。 首先，从表演的立场出发。 以前传递的css可以理解为n对n的数据库。 匹配过程多而复杂，性能得不到很好的保证。 为了保证性能，在一个班里约定了选择器。 性能可以保证。

另外，我们的样式缺省情况下具有范围，因此可以安全地定义各种类名，而不必担心与其他组件发生冲突。 全球冲突是css的七宗罪之一，我们非常重视，所以我们在实践中明确了其范围。

此外，如先前演示中所述，还可以控制if和repeat等的显示。 刚才没有演示很特别，我要加一个。 在安卓上，性能并不是很好的地方，客户可以看到接口的加载过程，并不是一瞬间就能完成的。 可以通过添加此值来细化显示界面的粒度。 如果上层把append等于树，里面的一系列东西就会被加载一次，从性能优化的角度来看是特殊的设计。 然后是id。 我们可以通过向其中写入id得到这个值，作为参数传播到api上来解决。

除了前面展示的p空白色容器、照片和副本之外，还支持提高了性能的slider组件和list。 这样可以提高性能，自动执行内存管理和资源管理组件，从而提高性能和帧速率。 另外，输入框，我们最近刚做，刚支持，实验阶段可能有小东西。 在这个范围之外，业务可以在高层横向扩展，稍后我会详细说明。 这是模板和格式部分的介绍。

格式部分支持flexbox，非常灵活和方便。 如果使用flexbox，界面可以分割成豆腐块的话，

正如前面的例子中提到的，脚本的一部分是viewmodel设计，data和methods是最重要的，如果值发生变化，对应的数据绑定的值也会发生变化。 除此之外，我们提供了生命周期的做法。 创建时、数据拦截完成时、渲染完成时，请在data和methods下写入这三种方法。 还有原生api，刚才演示的时候也出来了。 这里不多做介绍。

组件化通过构建许多复杂的东西，定义子组件(如在我上面有foo组件)，可以通过foo标签将foo嵌入到另一个组件中，如果数据被传播，则在foo组件中写入a和b 它既是组件之间的通信，也是事件机制。 每个组件都可以关闭，可以拦截自定义事件，也可以解除绑定。 想触发事件也有三种方法。 只有我自己，dispatch会向上移动到所有父组件，$broadcast会传播到所有子组件，并且这些设计和vue非常接近，组件之间进行通信。

除了刚才介绍的这些特征之外，我们相信未来会更丰富，开发者需要的，会提供平时开发中遇到的场景、更丰富的形式、更好的动画展示(包括很多复杂的手势场景)。 在这方面，性能、开发体验和最终效果都很好。 这是团队为了将来提供给大家而努力的事情。 并且希望收集和共享越来越多的相关素材，制作更多的工具，提供更好的开发者体验。

包括刚才演示的playgroundapp在内的很多副本都可以在我们的官网上找到。 现在处于开源内部测量阶段。 大家可以提交申请，稍后访问仓库，了解更具体的复印件。

这张图谁也不知道，但正如前面提到的，钩子说的是一层叫dsl的。 再下到virtualdom和render阶层h5，我有意用不同的颜色表示它，从我们设计一开始就想用三个边缘来表示，所以这个地方有点亮。

我们把刚才的图再展开一点。 最上面是我们的dsl。 我们通常称为weex文件，通过transformer这一层部署到服务器上，服务器端就完成了。 不用担心我们的转换是否有性能问题。 因为这在服务端已经完成了。 到了客户端，第一层是我们的JS -框架，最后去renderrengine，往下看，左边是我们的dsl文件，右边是转换后的jsbundle，dsl的template是我们的类型和次诺特。 最后是脚本。 脚本基本上是直译。 输入为virtualdom输出为native或h5view，恢复为内存中的树形数据结构，创建view，将事情绑定到view，设定view基本属性。 虚线相当于native经过一个过程，h5将此事件传递给webkitlayoutengine，以重新调整所有元素的大小和位置。 这张图整体基本上明确了weexrender流程，我们分为三个线程，不同的线程负责不同的事件，js线程优先保障我们的流动性，未来我们会有越来越多的技术文档，比较详细的解释。

以下是当前最受关注的weex体系结构的关键点，包括性能、可扩展性和可用性。

首先是性能。 我们内部有这样的压力测量网页。 我们同学把benchmark放在playground上，大家下载就可以看了。 在我们内部做压力测量的时候调到000个节点，大概10个画面，一个画面有3个卡，一个卡有100个节点左右。 让我们看看数据。 第一次表演是我们的加载时间。 同一页1300、1600也不太大。 20%左右，帧频差异很大。 scroller差不多一样。 内存有点好，因为这边用的是recycleview。 其次是cpu、静默cpu的消耗，以及运行中的cpu的峰值。 由于静默cpu接近0点，所以不进行16毫秒的回合。 如果进行16毫秒的回合，cpu会更高。

这是实际的商业数据。 3月页面上线后，我们看到这一页是活动，是3月新风尚的活动。 这个事件页面不使用list，特别是不使用内存。 这两个设备被定义为低端，帧率差异比较明显，无论是数据还是实际体验，流动性大致都有这样的差异。 性能经常提及帧率、加载时间，但经常忽略一个事件。 在本机ui开发中，js资源一般不加载到服务器端。 weex等动态化方案有副作用。 必须从服务器端下载js。 将js内置于客户端，避免下载问题。 这里包含了一系列的战略。 我们内部有一系列的机制，然后将这个机制作为独立的技术产品开放。

接下来是我们的兼容性。 兼容性不仅是weex有问题，偏内核型项目也有问题。 举个weex的例子，第一排是我们的商业代码，从下面看，上面的两次变迁，到客户端，整个场景都是n的立方体。 列举具体的数字，我的商业代码变更为3个版本，(英语) 3个版本，最后有3个立方体27的场景。 兼容性是我们一直重视的问题。 我们进行了一些事件。 首先，进行包括js和h5单测在内的单测保证，保证最基础的ut本身带来的意义。 第二个是js单测环境，我们通常在跑(英语) (虽然是在英语环境下，但和js的安全不同。 接下来是自动化事业，这个事业的细分也可以分为两块。 一个是我们的比较截图对照。 例如，我们的同学会说我们设定了各种各样的详细属性。 你怎么渲染的是你实际想要的，在api水平上效果不太好。 所以，这样的我们可以通过截图，将最终生成的结果和我们意想不到的结果进行图形比对，在比较古老成熟的核心上比较成熟，有点参考价值。 另外，layoutresults在包括model在内的相当一部分中，包括其他布局类，但实际上我们完全可以通过元素，最终其宽度很高，左上角的点，通过基本新闻，通过测试的过程 所以我们经过这两个事业，成熟后，会尽快放在上面。

关于可扩展性，让我们先回顾一下这张图。 如上所述，现在的weex给人一种可以用weex写很多页面的直观感觉，为了构成weex大家看到的结构，提供了连接路由机制、内部导航和页面的帮助。 详细来看，component，如果要扩展特定的点，请使用anotation来识别输入输出参数。 这是一个模块，在dsl中看到的是api，它下面有一个模块。 如果扩展module也一样的话，这是一个简单的跳转，基本新闻上去了，实现了业务功能，一个module完成了，很简单。

这是路线。 因为整个路由是app框架的一部分，所以下一个计划还需要多个。 单独看组件，包括前面两个，下面的生命周期思考，有动画和手势。 我认为这都是最基础的东西。 其次，它包括全球多个weex容器之间的通信机制、数据存储、互联网、一大堆传感器，包括基础的fs、商务舱，整体上是同步进行的，但目前的业务集中在这一点上 回到刚才的老问题，如果我们打开module，给上层提供api，中间提供adapter，提供自由实现，就去掉默认的盖子。 例如，用手取出里面( tbxxx )、覆盖默认页面( wxxxx )，对大家来说是能力已经增强了、增加了新的组件还是新的模块？ 现在

最后是我们的可用性。 之前说的很多。 这场表演要是有几张图就好了。 这是我们的工具链，红色代表完成，黄色在5月、6月完成，在6月正式开源之前。 剩下的一个是我们内部正在讨论的东西，以及决定时间逐步完成的东西，这些都是工具。 我们先给大家提供播放组。 扫描代码，也有自己的examples。 第二个是调试工具，位于chromedevtools常见的功能中。 又是立足之地。 如果只是大家在玩的话，playground就可以了。 如果要自己制作独立的app，如果要用weex制作，我们也会为你提供立足之地。 我们计划中的独立项目不是最终的名字，而是最终有像apphub这样的工具。 包括新闻在内，在界面上展示结构。 这是前面提到的例子，这是playground中的东西。 虽然截图和iphone的效果和安卓完全一样，但是利用weex现有的功能建立了一个比较有趣的组件库。 然后是我们的文档，包括《项目指南》、《参考》、《工具链》。 详细情况我就不多说了，大家可以去看。

目前，weex有三种集成方法。

所有页面模式

o目前支持单页采用，或者整个app采用weex开发(还不完善，需要开发路由器和生命周期管理)，这是可以与rn媲美的主要模式。

采用weex作为IOs /安卓组件，并将其比喻为imageview。 首页、主搜索结果、交易组件化等，这些诉求虽然商业级信息表达这样的native页面主体稳定，但局部动态诉求旺盛且频繁出版，处理这类问题也是weex的重点。

关于让native先生快速上手准web开发的方法和有趣的话题，也提出了很多建议。

oh5种产品采用weex、模拟wvc。 猫超、互动页面、一点多、噪声通道页面等一点多、特殊的h5页面在短期内不可能完全进入weex全页面模式(或rn )。 对比这一痛点，启动wvc项目，在现有h5页面进行微调，通过实际业务验证了引入native处理长列表内存激增、滚动不顺畅、动画/手势体验差等问题的想法。

owvc将嵌入到weex中，并进入weex的H5组件模式。

这三种模式几乎涵盖了淘类业务中的动态诉求(与native比较)或体验提升诉求(与h5比较)。 更令人感兴趣的是，这三种模式的技术基础是一致的，这意味着商务端可以使用本机或h5component模式处理实际业务痛点，并顺利过渡到weex全页面模式。 期待着weex成长为app框架的一天。

最后，是我们从过去11次的销售节到现在5个多月间做的一点点事件。 首先创建原型版本，然后使原型版本独立于独立客户端可用的sdk，扩展格式和布局，扩展基础组件，在这两个月内专注于工具。