浅谈一款移动端开发框架Weex

众所周知，在移动应用开发的过程中经常会出现多平台开发和频繁发布新版本的问题，而使用了诸如Weex，React Native等开发套件则可以轻松解决这些令人头疼的问题。本文就向大家介绍一下阿里在去年4月推出的一款移动端开发框架Weex。

上面提到了Weex可以解决多端研发和频繁发版这两个问题，它是怎么做到的呢？其实原理很简单，对于前者而言，Weex做到了尽量高的代码复用率，达到各平台使用同一份代码的目的；而对于后者，由于Weex是一个纯Js框架，通过js语言的特殊性，可以动态地刷新界面，避免频繁发版。

Weex的工作原理，简单地来说，是自定义了一套DSL语言(.we)，配合vue实现数据绑定、vdom等等功能。再通过native端与JS端的数据、API交互使得最终体现为native的调用过程，并在设计之初就考虑到在三端（iOS、安卓和H5）上能够得到展现。

再说一下服务端和客户端的组成。首先，服务端，在最初的DSL，即Weex文件（.we），通过Transformer转换成Js Bundle，继而部署到服务器，至此服务器已完成。同时由于转换在服务器就已经完成，因此也避免了对应的性能问题。其次，客户端，第一层是JS-Framework，最后到各平台对应的RenderRengine。

目前，Weex有3种集成方式：

全页模式：目前支持单页使用或整个App使用Weex开发（还不完善，需要开发Router和生命周期管理），这是主推的模式，可以类比RN。

Native Component模式：把Weex当作一个iOS或Android组件来使用，类比ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，这类Native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是Weex的重点。

H5 Component模式：在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短期内无法完全转为Weex全页模式（或RN），比如互动类页面、一些复杂频道页等。这个痛点的解决办法是：在现有的H5页面上做微调，引入Native解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。

最后，总结一下Weex的优缺点：

优点：

1. 轻量级。简单的DSL语言易于上手，整个框架轻便小巧。尤其是DSL语言避免了全局冲突，可自定义各种classname而不用担心冲突，个人认为是基于css的一个重要改进。

2. 扩展性和性能高。阿里在发布会上重点强调了这两个质量属性，相比于相对成熟的RN，均占有优势。

3. 组件化。Weex本身编写的界面就天然地支持组件化，同时支持大部分组件——除了div空白容器、图片、文本之外，还有比如Slider这种性能较好的滑块组件，前台开发的程序员经常会使用到的。

4. 开发成本相对较低。

缺点：

1. bug众多。由于Weex推出时日不长，其中还有很多bug待发现。

2. 社区、文档以中文为主，缺少英文版本，国际化程度较低，文档更新速度较慢。虽然通过Twitter获得较高的国外关注度。

3. 社区规模小，阿里员工占据了大部分，知名度较低。

ps：由于放图片要审核，所以工作原理的图暂时没放。