Weex详解：灵活的移动端高性能动态化方案

从事件角度，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个节点左右。我们看一下数据，第一个性能对比是我们的加载时间，同样一个页面1300、1600，也不算特别大，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，包括其他的布局类的，其实我们完全可以通过一个元素，最终它的宽高，左上角的点，通过基本的信息，让它完成测试的过程。所以我们经过这两块工作，一旦成熟，我们会尽快放到上面。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!