2016年qcon大会首日，阿里巴巴资深总监、淘宝移动平台、阿里百川负责人庄卓然宣布移动端高性能动态化方案weex即时内测，并将于6月开源。此消息一出，群情汹涌，在座的程序猿、攻城狮们纷纷拿起手机扫码，以期第一时间感受weex的神奇之力。
在第二天的主题分享会上，阿里巴巴前端开发专家赵锦江和技术专家徐凯对weex进行了深入的解析。以下为演讲速记整理后的成文。
阿里怎么看待移动开发？
目前的移动开发者面临的最大痛点就是面对极其复杂的环境，对此，庄卓然给出一个公式，移动开发的复杂度=应用数量×平台数量×要适配的各种各样的机型。
如何解决这个问题呢？在解决问题之前，首先要对移动开发的未来有着精准的研判。
阿里认为，移动开发的未来必定更加平衡，也就是说必须是性能与动态兼得，如此，才能够满足未来用户的需求。另外，移动开发在未来也必定是开放互联的状态，移动互联网将来肯定是基于更加大众化的技术体系，没有平台之间的隔阂，而且简单易用。
所以，阿里结合移动开发的现状并围绕其愿景推出了weex解决方案。
事实上，在去年的双11活动中，weex就得到了实战的验证，且表现不俗。时至今日，weex已经被阿里技术团队多次运用，并“创造”出各种丰富的场景，整体的表现非常优异。
把移动端所有界面拆分成各个page，然后中间设置有路由的控制逻辑，同时，将移动端各种各样的能力通过各种api提供给开发者。这是阿里对移动开发模型的理解。
weex通过标准化的东西，包括html、css和js这些前端非常快速易用好学的语法作为开发体验，提供给开发者。另外，weex的语法设计尊重还web的标准。
weex的工作原理
weex设计之初就考虑到在三端（ios、安卓和h5）上能够得到展现。在最上面的dsl，阿里一般称之为weex文件（.we），通过transformer转换成js-bundle，再部署到服务器，这样服务端就完成了。在客户端，第一层是js-framework，最后到renderrengine。
输入是virtual dom输出是native或者h5 view，还原成内存中的树型数据结构，再创建view，把事件绑定在view上，把view基本属性设上去。weex render会分三个线程，不同的线程负责不同的事情，让js线程优先保障流畅性。
weex的性能、扩展性以及可用性究竟怎样呢？
性能方面，阿里对weex做了多次压测。在加载时间、帧率、内存消耗、cpu占用（包括静默和峰值）等多个方面，weex都表现得非常出色。
在谈及性能之时，帧率和加载时间几乎都会被提及，但是往往忽略了一个事实，那就是native ui开发中通常没有js资源在服务器端加载。weex会把js内置到客户端里，以免除下载的问题，从而更为有效地提升性能。
兼容性是weex非常重视的问题，对此，阿里是这样来解决的。
首先是单测保证，包括js和h5的单测，保证最基础的ut（unit test）本身所带来的含义。
其次是ui的自动化，分为两个部分，一是截图对比，将最终产生的结果和意料中的结果进行图形对比；二是layout results，包括model以及其他的布局类的，通过基本的信息完成测试的过程。
在扩展性方面，weex可以写很多页面，而且通过路由机制帮助开发者将页面进行串联。
weex已开放内测，可用性方面正在逐步完善。包括playground、调试工具、脚手架、apphub、编辑器等多个方面，一些工作已经完成就绪，绝大部分工作将在5、6月份完成。
最后，是weex的三种工作模式。
1. 全页模式
目前支持单页使用或整个app使用weex开发（还不完善，需要开发router和生命周期管理），这是主推的模式，可以类比rn。
2. native component模式
把weex当作一个ios/android组件来使用，类比imageview。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，这类native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是weex的重点。
3. h5 component模式
在h5种使用weex，类比wvc。一些较复杂或特殊的h5页面短期内无法完全转为weex全页模式（或rn），比如互动类页面、一些复杂频道页等。这个痛点的解决办法是：在现有的h5页面上做微调，引入native解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。
另外，wvc将会融入到weex中，成为weex的h5 components模式。