在前端越来越火的年代，逐渐衍生出类似React Native、Weex等开发套件。所达到的目的挺简单的，达到在多个平台下共用一份代码，节省开发成本，提高开发效率。其次，由于JavaScript语言的特殊性，能动态更新页面而不需要发版。基于这两点，越来越多的个人开发者&公司开始尝试它们。

本文将从个人开发实践项目出发，发表一些对于Weex的看法和在项目中的实战经历。不涉及具体原理和概念性的东西，读者可以自行去Weex官网查阅。

Weex原理

大体上和React Native一致，都是一个“放大版”的JSBrdige。其核心无非就是自定义了一套DSL(.we)，配合vue实现数据绑定、vdom等等功能。再通过native端与JS端的数据、API交互使得最终体现为native的调用过程。

而在这过程中，iOS用了自带的引擎JavaScriptCore & Android则是Google V8。在这过程中有个坑，iOS版本Weex有内存泄漏的情况（Android没有），原因是JS Framework（Weex JS端的主程）并没有像V8一样hidden class的行为，GC回收不是很及时。Weex开发团队的同事发现了此bug，并在后续的版本中修复。

OK，我认为对于“应用框架者”来说，不用去care具体实现的原理。只需要了解怎么使用即可，毕竟这只是一个工具。如果是为了学习，可以去阅读，而对于“使用者”来说，快速地入门则是王道。

而Weex的使用，对于native来说，无非就是针对具体的业务场景实现Handler、Module、Component。

Handler

我们可以把Weex看做是一个提供了基础套件的UI渲染库。核心功能还是需要开发者自己来实现，比如：图片下载逻辑、网络请求、导航跳转等等。

所以开发者首先要关注的就是需要静态分析自己当前工程所需的功能，看看Weex需要你实现的handler中有哪些你要用到的，并实现它们。比如在我的项目中，就需要实现图片下载逻辑，于是实现并注册。

[WXSDKEngine registerHandler:[CNCWeexImageLoaderImplement new] withProtocol:@protocol(WXImgLoaderProtocol)];

Module

Module可以理解为JS端需要调用native才能处理的逻辑，并且在JSnative进行交互。这么说有点抽象，举个具体的例子：比如在JS端想访问native端的数据库（coredata、realm等），就需要实现一个module来满足JS调用native写好的module以实现native的逻辑。

在我的实战项目中，选择用module的方式实现网络请求与导航跳转。

[WXSDKEngine registerModule:@"urlRoute" withClass:[CNCWeexURLRouteModule class]];

[WXSDKEngine registerModule:@"networkRequest" withClass:[CNCWeexURLRouteModule class]];

Component

Component很好理解，要实现一个跑马灯UI的效果，在native端实现，并且注册到JS。JS端调用，即可展示出跑马灯。这就是Component，在JS满足不了或者实现成本很高的时候，则可以在native端实现Component供JS调用。

由于第一次试水Weex，并没有采取很复杂的UI，就没有用Component。

踩过的坑

JS中this关键字的用法与Objc不同，this的作用域仅在当前对象。而在JS中函数也算一个对象。如果在函数中套一个函数，此时用this，只能代表外层函数。而非Objc一样代表整个最外层对象，需要注意！

业务中碰到一个场景，需要在某个场景，native端主动调用JS。而Weex提供给外部的API并没有提供这样的能力，仅仅是在JS主动调native方法时传一个callback，并且在native方法执行完成时，callback销毁。而业务场景却需要在将来执行回传下来的callback。翻看源码，只能自己实现了。这里给个思路：

其实在Weex的实现中（不贴源码了），会判断native实现的方法（即给JS调用的方法，比如module实现的方法）的入参类型。如果是声明成WXModuleCallback，则Weex内部会进行处理，并转成block给iOS（Android同理）。而如果不是WXModuleCallback，则会透传一个String（weex标记的方法ID）下来，这很关键。于是我们可以投机取巧地把入参改成String，记录下这个String。在后期想调这个JS方法时，写如下代码即可

[[WXSDKManager bridgeMgr] callBack:weexInstance.instanceId funcId:aliveCallBackID params:params keepAlive:YES];

看法

Weex相比React Native，坑还是比较多的。但是从“使用者”角度来说，Weex方便很多。但是对于存在很多复杂业务场景的开发者来说，必然会去学习其原理，而此时Weex相比RN就没那么友善了。

因为在阿里，我更加支持Weex，也希望它变得越来越好。

无论采用哪种方式，两者都能实现客户端的动态化。而这对于一些多变的页面来说，是一种新的选择方式。

这是客户端动态化系列的第二篇文章，读者可以看前篇客户端动态化系列之——URLRoute，相信你对动态化有更深的理解。