客户端动态化系列之——Weex

在前端愈来愈火的年代，逐渐衍生出相似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才能处理的逻辑，而且在JS<->native进行交互。这么说有点抽象，举个具体的例子：好比在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，相信你对动态化有更深的理解。