背景

weex目前在集团乃至全球发展的如火如荼，最近也正在了解相关的资料，目前只是一些初步的了解，在这里分享一下。weex是跨端渲染框架，就是说一套代码，可以在web、ios和android跑，而且在后两者中，是以native方式跑的，因此在渲染效率和交互流畅度上，均有上乘的表现。weex于2016年开始在淘系双11、双12大促大规模使用，稳定可靠，可以看鬼道的介绍：《Weex 在双十一会场的大规模应用：业务支撑、稳定性保障和秒开实战》

那么为什么要做weex，相信做过web移动端页面的开发非常清楚，主要原因就是web在渲染和操作体验上的表现，相对于native来说又慢又卡，但是native虽然好，但开发却远比h5麻烦，不但开发环境麻烦、部署麻烦，还需适配android和ios两大平台，甚至需要招不同的程序员，h5尽管也有平台浏览器内核的兼容性问题，但开发容易上手，相对于native的开发成本，这些处理兼容性问题的代价基本上算是可以忽略了。

react-native、react-web与weapp

如何即让学习成本低、代码写的少，部署简单，又尽可能地在三端都能跑流畅，是全球各大互联网公司都在较劲脑汁思考的问题，比如facebook的react-native，实现了“learn once，run anywhere”，但因为其还是不能实现h5的渲染降级，因此说的是learn once，即web端还是需要再写一遍，react-web做了一个能让react-native代码跑在web的事情，为什么react-native能实现一份代码跑两端，react-web又能扩展其web渲染呢？其实是因为无论是web、ios还是android，尽管其底层实现的api或控件不同，但都能实现相同功能的布局和界面，因此要实现一份代码跑三端，最关键的是把三端的布局细节封装并对上层屏蔽，上层UI描述使用一样的DSL，在native渲染的时候，再根据不同平台走不同的renderer。

再说集团，在3年前，集团的weapp也做了这个事情，它使用json或xml描述界面，包含界面的布局、样式、事件甚至联动，然后能实现三端渲染：

{
    "type":"label",
    "dataBinding":{"value":"$phone_number"},
    "styleBinding":{"align":4,"fontSize":28,"fontStyle":1,"gravity":4,"height":80,"lines":1,"marginLeft":86,"textColor":"#3d3f45","width":-1}
    "events":[
        {
            "type":"click",
            "actions":[
                {
                    "type":"userTrack",
                    "param":{"utName":"TelPhone","utParams":{"wp_app":"weapp","wp_m":"phone_7","wp_pk":"$wp_pk"},"utType":"Button"}}
                {
                    "type":"phoneCall",
                    "param":{"phoneNumber":"$phone_number"}
                }
            ]
        }]
}

weapp的想法是很好的，也有很多应用场景，1688早期的roc，就是使用weapp搭建native页面，在后期，很多无线团队也在研究weapp与react-native的融合，但weapp由于是基于json的，因此编写逻辑不灵活，也不方便编写和引用模块，还有很多私有的语法增加了学习成本，落地情况不是很理想，因此在后来react-native出来以后，看到这么耀眼的东西一个存在，基本上就在思考新的方式了。

weex与rax

这个新的思路就是weex，weex吸取了集团在跨端方面的很多沉淀，抛弃了一些缺陷，主要有这么一些优势：

1. 使用web的方式写代码，通过与vue的结合，深得社区人心，尤其是h5移动页面开发者，学习成本实在太低了，首先解决了一个使用难的问题
2. 实现了跨三端的高性能渲染，比native要慢，但比react-native要快
3. 成熟配套的工具支持，weex sdk、weex toolkit、weex playground等，比起react-native，更容易上手
4. 开放了native dom api，因此上层可以开发自己的js框架，后来的rax就是基于此实现的

我们来看下weex的架构：

在DSL层，使用vue的方式编写界面和交互，打包编译成js bundler自执行文件，js bundle通过url协议被客户端识别，这个过程可通过离线缓存，或者直接请求的方式实现，客户端要执行这个js，那么必须有一个js引擎，目前用的是google v8，js本身是不可能渲染native控件的，因此需要一个jsbridge，jsbridge去callnative实现native控件的生成，不同端的native渲染是不一样的，值得一提的是，如果是web端，那么就不需要jsbridge去callNative了，直接走dom渲染。

weex架构的有一个好处就是，开放了vdom这一层，即操作nativeDom的这一层，这意味着你可以自己手写代码渲染native界面，或者自行封装框架，比如这段代码，即没用vue，也没用jsx，直接手写，也一样能在native运行：

var m = __weex_require__('@weex-module/modal');
m.alert({
    message: "你好吗？"
});
document.open();
var body = document.createBody();

document.documentElement.appendChild(body);
var x = document.createElement("text");
x.attr.value = "hello faxin";
x.style = {
    color: "green",
    fontSize: 100
};
document.body.appendChild(x);
document.close();

//隐藏菊花
sendTasks(document.id, [{module: 'dom', method: 'createFinish', args: []}]);

把这个js放到本地http服务器，然后手机连上公司wifi，用weex的playground扫描即可渲染出结果：

如果没装，可以使用mds模拟，值得一提的是，mds还提供了weex js的断点调试能力，非常推荐：

可以看到，这些api和dom的太像了，事实上，无论是weex jsframework，还是rax，都是对vdom的上层封装而已，有点类似无论是angular、jquery，其实最终都是操作浏览器的dom api来驱动渲染html，在这点上看，我们可以把weex底层看成一个dom level提供者。

接下来再说一下rax，rax是跨容器渲染框架，写法与react基本兼容，rax的前身应该就是react-web，只是现在直接驱动weex容器作为native渲染了，rax的架构有许多值得学习的地方，他的界面写法使用jsx，接下来编译成js，有virtual dom的机制在里面，在最终的渲染端，是通过驱动的机制来实现，也就是说，它能在哪里渲染，取决于你写的驱动，目前在native的渲染，直接对接了weex的native dom api，在web的渲染，使用自己的封装，还有服务器的渲染，你如果后面要写在其他设备的渲染，理论上可以自己编写驱动来实现。

表面上看，rax是提供了另外一种阵营的选择，即vue体系意外的react体系，但它还做了很多事情：

1. rax ui库，封装了很多集团内的库和组件，如slider、tab、spm打点等等，大部分业务都可以稍微封装即可使用
2. 兼容的处理，比weex在h5渲染还原度更高
3. 支持返回一批元素，了解react的同学知道，react必须返回一个带根root的元素

结语

跨三端是多少移动开发人员的梦想，如今在weex体系下已经得到几乎完美的解决，尽管在h5降级上仍有细微的缺陷，目前weex已经捐到了apache基金会，预计未来会得到持续的发展，也欢迎更多的同学加入其研发或者接入。