weex 是一款轻量级的移动端跨平台动态性技术解决方案！
体积小巧，语法简单，方便上手
业务方可自行横向定制 native 组件和 api
快速加载，快速渲染，体验流畅
拥抱标准：基于 web 标准设计语法
响应式界面： 通过简单的模板和数据绑定轻松解决数据和视图的同步关联问题
多端统一：ios、android、html5 多端效果一致，撰写一次就可以轻松达到跨平台的一致性，无需针对多套平台单独开发，省时省力
复杂逻辑描述：动态性不只体现在展示效果的动态性上，更体现在可以实时调整复杂的数据处理方式和逻辑控制方式
组件化：组件之间通过 webcomponents 的设计完美的隔离，并可以通过特定的方式进行数据和事件的传递
生态&链路：我们为 weex 的开发者和使用者在不同维度上提供了各式各样的工具和平台，包括代码打包工具、开发者调试工具、部署平台、playground、经典案例、入门指南和详尽的文档等。你不是从零开始，你也不是一个人在战斗！
首先，我们像开发 webcomponents 一样，把一个组件分成 <code><template></code>、<code><style></code>、<code><script></code> 三部分，刚好对应一个组件的界面结构、界面样式、数据&逻辑。
细节1：顺便说一句，这也是我们认为描述界面的最佳实践。
代码示例：
显然这些代码是不会被 native app 识别的，我们要想办法让这些代码可运行。所以我们同时做了三件事：
在本地用一个叫做 transformer 的工具把这套代码转成纯 javascript 代码
在客户端运行一个 javascript 引擎，随时接收 javascript 代码
在客户端设计一套 js bridge，让 native 代码可以和 javascript 引擎相互通信
所以紧接着第二步，就是用 transformer 对代码进行转换，变成客户端可运行的 javascript 代码
其实本地开发还有一点很重要，就是把复杂的界面通过组件化的方式进行分解，并合理的建立组件之间的组合和调用关系。
最终，我们把简单组件组合成复杂的界面，并通过 transformer 打包成一个完整的程序包 (主体是一段 javascript 代码)
细节2：由于 weex 组件的开发和 web 组件的开发非常接近，但是对标准的支持范围和一些细节是有不同之处的，我们会贴心的在 transformer 里加入了一些友情提醒，帮助大家回避常犯的书写错误。
上一节已经提到了，我们在客户端会运行一个 javascript 引擎并且有 js bridge 通信机制。这里再介绍具体一些：
native 渲染和 javascript 引擎之间，主要进行三类通信：
界面渲染，单向 (js -> native)：这毫无疑问，javascript 引擎需要把界面的结构和样式告诉 native 端，这样我们才能得到 native 级别的终极界面效果
事件绑定与触发，双向：在我们的客户端技术方案中，native 端只负责界面渲染和非常薄的事件触发层，事件的逻辑处理都会放在 javascript，这样我们就具备了复杂数据处理和逻辑控制的动态性可能。js 告诉 native 需要监听的交互行为，而当用户产生对应的交互行为时，native 端会把交互信息回传给 js
对外的数据/信息请求与响应，双向：js 引擎在处理特殊逻辑时，难免需要向服务器请求数据、或请求本地的系统信息和用户信息、或调用 native 的某个功能，这个时候也会通过 js bridge 进行请求，native 收到这些请求之后，也会在必要的情况下通过 js bridge 把信息回传给 js 引擎
再加上外层对 weex 实例的管理，整套机制就可以顺畅的工作起来了
细节3：native 端渲染的时候，我们以图片和文字的形态为主，并大量依赖了标准的 css 样式进行细节的渲染
细节4：我们把框架层面的 js 代码全部提前放在了客户端本地，并提前运行做好准备。这样本地生产的 javascript 是非常小的，网络传输的代价也非常低，而在客户端运行的初始化成本也非常低。整条链路都和界面打开速度息息相关
细节5：我们在 js 处理界面逻辑的过程中采取了数据监听+依赖收集的策略，既没有通过脏检查，也没有通过全量 diff virtual dom 树的方式，因为通常在移动端，数据变更都是非常小量的，经过我们的实践，这套方案完全可以应付移动端日常的动态性界面需求
细节6：我们对业务上通用常用的组件进行了封装，并且暴露规范化的类型 (标签名)、特性、样式、事件、上下级约束等维度的定义。这样所有的业务界面都可以用这些基础的组件搭建而成
细节7：我们对业务上通用常用的 api 进行了封装，并且暴露规范化的 js api
我们在服务端提供了基础的程序包发布，给每个程序包一个特定的 page id，然后为客户端提供通用的服务，通过 page id 获取程序包，这样本地开发、动态实时部署、客户端动态化渲染和逻辑处理就完美的串联在一起了
细节8：实际上，除了界面本身可以动态化之外，客户端的 js 引擎的代码、还有部分 native 的实现，我们也准备了相应的动态化机制，也就是说客户端的动态能力本身也是具有动态性的
我们还会面对这样的场景，就是一个客户端的业务，会通过微博之类的渠道进行转播和推广，当用户手机里刚好安装了手机淘宝客户端，那么会直接“拉起”客户端进行相应的界面展示，如果没有装手机淘宝，则需要在浏览器里展示一个相同或接近的界面。自然 weex 技术方案支持的业务也有这样的需求。所以我们同时提供了 html5 版本的技术方案，同一份 javascript 程序包，可以同时通过客户端的 js bridge 渲染成为 native 界面，也可以通过浏览器渲染成为 web 界面。我们的做法也非常简单，就是把 js bridge 背后的 native 处理逻辑同构成了 html5 版本。然后发布这样的一个页面。
细节9：我们能够同构 html5 版本和 native 版本，主要归功于我们在 js bridge、组件定义、api 定义方面的高度抽象——当然 html5 的版本在性能和体验上确实有一定的劣势，并不是最理想化的效果，所以核心的主战场还是客户端，这也和目前的移动互联网的形态相吻合
综上所述，整个 weex 的工作原理大致可以用一张图来表述：
我们致力于把开发体验、网络传输的大小、运行时的开销控制做到极致，并且尽可能的降低多端适配和优雅降级的成本
我们对组件的定义和业务功能预留了很好的横向可扩展能力，这也业务方可以自由定制属于自己的 native 组件和 api，从而在后期可以通过实时发布不同的程序包来进行动态化控制。同时也因为它的横向可扩展性，weex 的核心可以非常小，非常易于融入现有的无线技术体系
我们在网络传输、实例初始化、js 运算、native 渲染能力等方面做了非常针对性且深入的优化，尤其是针对中低端安卓机，不论是加载时间还是运行时的流畅度，都比之前的方案有质的飞跃。我们对 cpu、内存、帧率、首屏渲染时间等核心性能指标也一直保持高度的关注，也建立了相应的线上监控和数据统计机制。而更多可优化的空间和方案我们还在不断的进行优化尝试。
下图是今天凌晨旧金山 qcon 上 weex 技术方案的首次公开分享中的一页性能表现对比图，大家可以感受一下：
这就是 weex，如上一篇文章所介绍的：
致力于移动端
能够充分调度 native 的能力
能够充分解决和回避性能瓶颈
能够灵活扩展
能够多端统一
能够优雅“降级”到 html5
能够保持较低的开发成本
能够快速迭代
能够轻量实时发布
能够融入现有的 native 技术体系
能够工程化管理和监控
目前 weex 还在努力达到更高的性能、更高的扩展性、更低的开发成本、更完整的生态和工具链，也同时尝试接入更多的业务，体现出它的更大的价值。已经有很多业务方迫不及待的在和我们主动取得联系了，未来我们希望 weex 能够逐步在集团内开放试用，并最终走向开源。
另外整个技术方案还有很多值得分享的东西，比如 transformer 的实现、组件和 api 的设计思路等，我们会再做针对性的分享和介绍