技术 | 一行经脉让你看懂 Weex Runtime 的任督二脉

整个研究主要分为三个部分，第一个部分研究weex初始化的脉络，探寻一下需要注意的细节。第二个部分研究一下业务bundle初始化的过程，真实的计算是在哪里发生的。第三个部分研究一下JS Framework的脉络走向，以及Native到底是如何桥接到JS Framework上的。

研究Service方案，是否符合预期。

分析视角为iOS + JavaScript

先从两端的脉络开始，梳理清楚之后，再做下一步的研究分析

weex runtime 初始化脉络研究

SDK初始化时比业务先注入js framework，如下是framework.js注入的顺序：

Native初始化（js framework）initSDKEnvironment，也提供了initSDKEnvironment:(NSString *)script来注入自己的framework不过一般基本用不上。
WXBridgeManager executeJsFramework
WXBridgeContext executeJsFramework
WXBridgeProtocol __jsBridge = [[WXJSCoreBridge alloc] init]
JSContext 扩展了很多属性，比如name，WXEnvironment等
WXBridgeContext registerGlobalFunctions 注册Native module，component等，给JSContext扩展callback，全部转换成数字id，每一个module，component等都有其对应的id。
JSContext evaluateScript 执行js framework.js代码

这说明一个问题：weex-framework.js 是全局共享的，只初始化一次，业务bundle打开的WXVC就算销毁了 (weex instance销毁)，JSContext内的JS Framework也不会销毁。

业务bundle 初始化脉络研究

WXSDKInstance来负责注入业务bundle

WXSDKInstance renderWithURL 注入业务bundle url
WXSDKInstance _renderWithRequest
WXSDKInstance _renderWithMainBundleString
WXBridgeManager createInstance
WXBridgeContext createInstance
WXBridgeContext callJSMethod 传入@"createInstance"，以及组织参数args @[instance, temp, options ?: @{}, data]，data就是业务bundle JavaScript字符串
判断frameworkLoadFinished是否准备就绪，准备就绪调用WXJSCoreBridge 的callJSMethod 传入@"createInstance"，args，如果没有准备就绪，添加进_methodQueue。
JSContext globalObject invokeMethod 方法，获取之前初始化时JSContext的“全局对象”引用，类似浏览器的“window”对象，也就是执行weex-framework.js中的createInstance方法，接收的参数是@[instance, temp, options ?: @{}];
从weex-framework.js中的createInstance又调入到Vue platforms/weex/framework.js 中的createInstance，
最后 const result = new Function(...globalKeys)执行JS Script字符串，在业务中可以使用的weex，Vue也是从这里注入的

WXSDKInstance来负责销毁注入的业务bundle

WXSDKInstance destroyInstance 根据instanceId销毁当前的WX实例
WXBridgeManager destroyInstance
WXBridgeContext destroyInstance
WXBridgeContext callJSMethod 传入@"destroyInstance"和instance id
JSContext globalObject invokeMethod

这说明一个问题：创建UI界面的计算是在JavaScript这边的，创建和销毁阶段都是由Native主动调起JavaScript的方法，传入必要的参数，看来重点还是得研究weex-framework.js里，怎么实现计算又CallNative去渲染界面，代理其他事件等等。

JS Framework 脉络研究

运行在JSCore中的环境，究竟从哪里开始，globalObject对象中究竟有什么对象？

入口从html5/render/native/index.js开始

JS Framework 初始化

weex 仓库 render/native/index.js 调用 runtime/init.js 里的 init函数
weex 仓库 runtime/task-center.js initTaskHandler
vue 仓库 platforms/weex/framework.js init，传入config

运行时从Native端调用createInstance开始。

weex 仓库 runtime/init.js createInstance
weex 仓库 runtime/service.js createServices
vue 仓库 src/platforms/weex/framework.js createInstance
vue 仓库 createInstance最后sendTasks实际上是调用 weex仓库 runtime/config.js 的sendTasks，而这个方法传递给callNative

这个callNative方法是什么？是Native注册的block，这是JS Framework 与 Native 连接脉络的最后一步。

JSValue* (^callNativeBlock)(JSValue *, JSValue *, JSValue *) = ^JSValue*(JSValue *instance, JSValue *tasks, JSValue *callback){
    NSString *instanceId = [instance toString];        
    NSArray *tasksArray = [tasks toArray];        
    NSString *callbackId = [callback toString];        
    WXLogDebug(@"Calling native... instance:%@, tasks:%@, callback:%@", instanceId, tasksArray, callbackId);        
    return [JSValue valueWithInt32:(int32_t)callNative(instanceId, tasksArray, callbackId) inContext:[JSContext currentContext]];
};
_jsContext[@"callNative"] = callNativeBlock;

再来看看运行时的参数和返回值，转成了对应的Native上的数值。

这说明在“全局”环境中存在比如createInstance方法的，也有callNative。

业务bundle中的组件是如何执行的，脉络研究

 import Hello from './Hello.vue';    
 Hello.el = '#app';    
 new Vue(Hello);

（在createInstance中通过new Function执行字符串的方式）new Vue(Hello); 组件new Vue，开始进入vue-runtime.js的流程
Vue类在Vue仓库 platforms/weex/framework.js createVueModuleInstance被扩展，增加了$document，$instanceId等
Vue进行组合计算，从_init开始

Vue.prototype._init = function (options) {
    /* istanbul ignore if */
    if (process.env.NODE_ENV !== 'production' && config.performance && perf) {              
        perf.mark('init');
    }        
    var vm = this;            // a uid
    vm._uid = uid++;            // a flag to avoid this being observed
    vm._isVue = true;            // merge options
    if (options && options._isComponent) {              
        // optimize internal component instantiation
        // since dynamic options merging is pretty slow, and none of the
        // internal component options needs special treatment.
        initInternalComponent(vm, options);
    } else {              
        vm.$options = mergeOptions(                
           resolveConstructorOptions(vm.constructor),
           options || {},
           vm
        );
   }            /* istanbul ignore else */
   if (process.env.NODE_ENV !== 'production') {              
        initProxy(vm);
   } else {              
        vm._renderProxy = vm;
   }            // expose real self
   vm._self = vm;            
   initLifecycle(vm);            
   initEvents(vm);            
   initRender(vm);            
   callHook(vm, 'beforeCreate');            
   initState(vm);            
   initInjections(vm);            
   callHook(vm, 'created');        
   /* istanbul ignore if */
   if (process.env.NODE_ENV !== 'production' && config.performance && perf) {              
        vm._name = formatComponentName(vm, false);              
        perf.mark('init end');              
        perf.measure(((vm._name) + " init"), 'init', 'init end');
   }        
   if (vm.$options.el) {              
       vm.$mount(vm.$options.el);
   }
};

这段代码其实可以忽略，总之是从_init开始，走完Vue提供的生命周期，events，各种hook的流程，比如div组件在Native上会注册成一个Component，那么JS的Div如何与Native的Div Component对应上？

在完成：

 const result = new Function(...globalKeys)    
 return result(...globalValues)

执行完业务bundle.js（new Vue）之后，会调用callNative方法，将参数{ module: 'dom', method: 'createFinish', args: [] }发送到Native端

WXJSCallNative block
WXBridgeContext invokeNative

 for (NSDictionary *task in tasks) {            
    NSString *methodName = task[@"method"];            
    NSArray *arguments = task[@"args"];            
    if (task[@"component"]) {                
        NSString *ref = task[@"ref"];
        WXComponentMethod *method = [[WXComponentMethod alloc] initWithComponentRef:ref methodName:methodName arguments:arguments instance:instance];
        [method invoke];
    } else {                
        NSString *moduleName = task[@"module"];
        WXModuleMethod *method = [[WXModuleMethod alloc] initWithModuleName:moduleName methodName:methodName arguments:arguments instance:instance];
        [method invoke];
    }
 }
        
 [self performSelector:@selector(_sendQueueLoop) withObject:nil];

WXModuleMethod 传入JS定义的module dom
WXModuleMethod instance 调用 invoke

Service 方案脉络研究

梳理一下Service注册的方案，看看跟runtime平级的家伙到底是什么？

WXSDKEngine registerService 注册Service Name ，脚本，options
WXBridgeManager registerService
WXServiceFactory registerServiceScript
组织一个数据结构 { name: name, options: options, script: WXServiceFactory registerService }

最终成为的结构为@""：

    ;(function(service, options){
    \n;
    serviceScript （我们的脚本）
    \n
})({
    register: global.registerService,
    unregister: global.unregisterService}, {        
    "serviceName": name,        
    ...options
});

WXBridgeContext executeJsService
JSContext evaluateScript 执行这段脚本

这说明一个问题，service是注册到了weex-framework.js提供的registerService方法里了，我记得注册使用的脚本如下：

 service.register(options.serviceName,{        
    created: function(){
        
    },        
    refresh: function(){
        
    },        
    destroy: function(){
        
    }
 })

不过WXSDKEngine也提供了销毁的方法，这个是可以卸载的，不过怎么卸载，又到了weex-framework.js里了。既然service跟runtime是一个平行的级别，如果不卸载，那么将永远的存在于内存中与runtime一样，是一个可以共享的区域。

从JS Framework的脉络来看，入口实现在 html5/runtime/service.js中。

 export function register (name, options) {        
    if (has(name)) {            
        console.warn(`Service "${name}" has been registered already!`)
    } else {
        options = Object.assign({}, options)            
        services.push({ name, options })
    }
 }

name 就是service name，options是之前定义的一组对象：

{        
   created: function(){
  
   },        
   refresh: function(){
        
   },        
   destroy: function(){
        
   }
}

看起来这一步都只是将定义的service结构存储在数组里，那么weex是如何调用的？

createInstance，这个方法是由Native调用的
createServices

  services.forEach(({ name, options }) => {            
      if (process.env.NODE_ENV === 'development') {                
          console.debug(`[JS Runtime] create service ${name}.`)
       }            
       const create = options.create
       if (create) {                
         const result = create(id, env, config)                
         Object.assign(serviceMap.service, result)                
         Object.assign(serviceMap, result.instance)
       }
    })

createServices函数中可以获取到create创建阶段，在这个循环中调用实现，这也说明，在create中可以获取到env平台信息，这也意味着可以抹平iOS Android差异了，至于result，也就是return出来的。

接着往下看，在createInstance函数中：

env.services = createServices(id, env, runtimeConfig)
instanceMap[id] = env    
return frameworks[info.framework].createInstance(id, code, config, data, env)

既然知道了createInstance函数是由Native调用，那么frameworks[info.framework]这个framework决定了启用什么来渲染，也就是html5/framework/index.js 下指定的几种渲染框架。

（重要：目前v0.10.0版本Vue的作者没有包service给new Function，不用想着使用了，只可以注册。）

如果对weex有兴趣，点击阅读原文，进入国内最专业的 weex 论坛。^_^

你身边如果有朋友对混合领域（跨技术栈）或全栈感兴趣，可以转发给他们看哦，^_^先谢过啦。

更多精彩内容可关注我的个人微信公众号：搜索fed-talk或者扫描下列二维码，也欢迎您将它分享给自己的朋友。