[深入ReactNative] 通讯及消息循环代码剖析

96
肥皂V
0.5 2016.01.03 22:27* 字数 4407

肥皂V 2016 1.3
http://www.jianshu.com/p/269b21958030

React Native 已经推出近一年时间了,近期也在研究iOS下用js写app的框架,从徘徊和犹豫中,最终还是选定React Native,她就像若隐若现的女神一样,想要下决心追到,可是不容易。要想把她应用的已存在的有一定体量的app中,更是不易,让我先把她里外都了解清楚,在分享一下合理应用到现有app的方案,这是深入React Native系列的第一篇,后续会继续分享使用过程中的一些认识。

本篇详细分析下React Native 中 Native和JS的互相调用的原理解析。之前bang的文章已经介绍过,本文从代码层面更深入的来讲解,
分析基于 React Native 0.17.0 版本, RN在快速进化,其中的内容已和之前的旧版本有些不同

作为初篇,先创建一个示例工程,以后的分享都以这个工程为基础。目前这个工程还很简单,main.js的讲解可以下载这里的代码

GitHub MGReactNativeTest
工程里有直接改动main.jsbundle

示例工程的代码

  render: function() {
    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          Welcome to React Native!
        </Text>
        <Text style={styles.instructions}>
          {this.state.changeText}
        </Text>
        <Text style={styles.welcome} onPress={this._onPress}>
          Change
        </Text>
      </View>
    );
  },
11.png

)

Native 与 JS的互相调用

0.17版本的React Native JS引擎已经全部使用的是iOS自带的JavaScriptCore,在JSContext提供的Native与js互相调用的基础上,封装出了自己的互调方法。下面是一张结构图

架构图.png

App启动过程中 Native和JS互相调用的日志

[Log] N->JS : RCTDeviceEventEmitter.emit(["appStateDidChange",{"app_state":"active"}]) (main.js, line 638)
[Log] N->JS : RCTDeviceEventEmitter.emit(["networkStatusDidChange",{"network_info":"wifi"}]) (main.js, line 638)
[Log] N->JS : AppRegistry.runApplication(["MGReactNative",{"rootTag":1,"initialProps":{}}]) (main.js, line 638)
[Log] Running application "MGReactNative" with appParams: {"rootTag":1,"initialProps":{}}. __DEV__ === true, development-level warning are ON, performance optimizations are OFF (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([2,"RCTView",1,{"flex":1}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([3,"RCTView",1,{"flex":1}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([4,"RCTView",1,{"flex":1,"justifyContent":"center","alignItems":"center","backgroundColor":4294311167}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([5,"RCTText",1,{"fontSize":20,"textAlign":"center","margin":10,"accessible":true,"allowFontScaling":true}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([6,"RCTRawText",1,{"text":"Welcome to React Native!"}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([5,null,null,[6],[0],null]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([7,"RCTText",1,{"textAlign":"center","color":4281545523,"marginBottom":5,"accessible":true,"allowFontScaling":true}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([8,"RCTRawText",1,{"text":"soap1"}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([7,null,null,[8],[0],null]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([9,"RCTText",1,{"fontSize":20,"textAlign":"center","margin":10,"accessible":true,"allowFontScaling":true,"isHighlighted":false}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([10,"RCTRawText",1,{"text":"Change"}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([9,null,null,[10],[0],null]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([4,null,null,[5,7,9],[0,1,2],null]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([3,null,null,[4],[0],null]) (main.js, line 638)
[Log] JS->N : RCTUIManager.createView([12,"RCTView",1,{"position":"absolute"}]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([2,null,null,[3,12],[0,1],null]) (main.js, line 638)
[Log] JS->N : RCTUIManager.manageChildren([1,null,null,[2],[0],null]) (main.js, line 638)

日志显示了启动React Native 界面 Native与JS的调用过程,我们从最简单的例子入手,慢慢脱下女神的面纱。

Native调用JS (Native->JS)

可以看到,启动开始之后,Native调用了JS的 RCTDeviceEventEmitter.emit 广播了两个事件 appStateDidChange,networkStatusDidChange
随后调用 AppRegistry.runApplication(["MGReactNative",{"rootTag":1,"initialProps":{}}]) 启动了React Native引擎。
下面我们一点点分析,是如果从Native调用到JS的函数AppRegistry.runApplication的

系统JavascriptCore 中Native如何调用JS

JSContext *context = [[JSContext alloc] init];
[context evaluateScript:@"function add(a, b) { return a + b; }"];
JSValue *add = context[@"add"];
NSLog(@"Func:  %@", add);
 
JSValue *sum = [add callWithArguments:@[@(7), @(21)]];
NSLog(@"Sum:  %d",[sum toInt32]);
//OutPut:
//  Func:  function add(a, b) { return a + b; }
//  Sum:  28

JSContext 是运行 JavaScript 代码的环境。一个 JSContext 是一个全局环境的实例,我们可以从 JSContext全局变量中用下标的方式取出JS代码中定义的函数 add,它用JSValue类型包装了一个 JS 函数, 如果你确定JSValue是一个JS函数类型,可以使用callWithArguments 来调用它。
更详细的介绍可以学习这篇文章 Java​Script​Core

AppRegistry.runApplication

聪明的你一定想到,React Native 的也是用同样方式调用到AppRegistry.runApplication,是的,不过是通过一个通用接口来调用的
RCTJavaScriptContext 封装了OC方法callFunction,

- (void)callFunctionOnModule:(NSString *)module
                      method:(NSString *)method
                   arguments:(NSArray *)args
                    callback:(RCTJavaScriptCallback)onComplete
{
  // TODO: Make this function handle first class instead of dynamically dispatching it. #9317773
  [self _executeJSCall:@"callFunctionReturnFlushedQueue" arguments:@[module, method, args] callback:onComplete];
}

_executeJSCall 执行的具体代码是

    method =  @“callFunctionReturnFlushedQueue”
    JSStringRef moduleNameJSStringRef = JSStringCreateWithUTF8CString("__fbBatchedBridge");
    JSValueRef moduleJSRef = JSObjectGetProperty(contextJSRef, globalObjectJSRef, moduleNameJSStringRef, &errorJSRef);
    JSStringRef methodNameJSStringRef = JSStringCreateWithCFString((__bridge CFStringRef)method);
    JSValueRef methodJSRef = JSObjectGetProperty(contextJSRef, (JSObjectRef)moduleJSRef, methodNameJSStringRef, 
    resultJSRef = JSObjectCallAsFunction(contextJSRef, (JSObjectRef)methodJSRef, (JSObjectRef)moduleJSRef, 0, NULL, 

可以看到Native 从JSContext中拿出JS全局对象 __fbBatchedBridge,然后调用了其callFunctionReturnFlushedQueue函数

是时候克服心中的恐惧,开始掀裙子了 ,来看看main.jsbundle中的JS代码

上文Natvie调用JS的路径到了 __fbBatchedBridge.callFunctionReturnFlushedQueue js代码这一步,demo工程中,我们自己写的index.ios.js 只有区区几行,去Node Server转一圈或React Native的预编译之后,竟然产生了1.3M,近5W行JS代码的main.jsbundle 文件,对于终端同学来说,简直是一座五指山。不要害怕,我们一起探寻其中的奥妙。

继续跟踪js代码中的 __fbBatchedBridge

//main.js
__d('BatchedBridge',function(global, require, module, exports) {  'use strict';
    var MessageQueue=require('MessageQueue');
    var BatchedBridge=new MessageQueue(
        __fbBatchedBridgeConfig.remoteModuleConfig,
        __fbBatchedBridgeConfig.localModulesConfig);

    Object.defineProperty(global,'__fbBatchedBridge',{value:BatchedBridge});

    module.exports=BatchedBridge;
});

我们发现这段JS代码中有这句 Object.defineProperty(global,'__fbBatchedBridge',{value:BatchedBridge});

准备知识,对JS很熟的同学可以略过或指正

这段JS代码怎么理解呢,这个是nodejs的模块代码,当打包成main.js之后,含义又有变化,我们简单可以这样理解,__d() 是一个定义module的JS函数,其就等于下面这段代码中的 define 函数,从代码上很容易可以理解,它定义一个module,名字Id为BatchedBridge,同时传递了一个工厂函数,另一个模块的代码可以通过调用require获取这个module,例如
var BatchedBridge=require('BatchedBridge');

这是一个懒加载机制,当有人调用require时,工厂函数才执行,在代码最后,把这个模块要导出的内容赋值给module.exports。

        function define(id,factory){
            modules[id]={
                factory:factory,
                module:{exports:{}},
                isInitialized:false,
                hasError:false};}
                
        function require(id){
            var mod=modules[id];
            if(mod&&mod.isInitialized){
                return mod.module.exports;}

好,我们抓紧回来,在上段代码中当BatchedBridge module创建时,通过这句 Object.defineProperty(global,'__fbBatchedBridge',{value:BatchedBridge}); 把自己定义到JSContext的全局变量上。所以在Native代码中可以通过 JSContext[@"__fbBatchedBridge"]获取到,

从代码中也可以看到BatchedBridge 是JS类MessageQueue的实例,并且它导出的时候并没有导出构造函数MessageQueue,而是导出的实例BatchedBridge,所以它是React Native JS引擎中全局唯一的。它也是Natvie和JS互通的关键桥梁。

 __fbBatchedBridge.callFunctionReturnFlushedQueue("AppRegistr","runApplication",["MGReactNative",{"rootTag":1,"initialProps":{}}])

我们继续看MessageQueue 类的callFunctionReturnFlushedQueue 函数,它最终调用到__callFunction(module, method, args)函数

__callFunction(module, method, args) {
    var moduleMethods = this._callableModules[module];
    if (!moduleMethods) {

      moduleMethods = require(module);
    }
    
    moduleMethods[method].apply(moduleMethods, args);
  }

看起来__callFunction就是最终的分发函数了,首先它从this._callableModules中找到模块对象,如果它还没有加载,就动态加载它(require),如果找到就执行最终的JS函数。

自己开发的JS模块如果暴露给Native调用

先看下AppRegistry是如何暴露给Natvie的


__d('AppRegistry',function(global, require, module, exports) {  'use strict';

    var BatchedBridge=require('BatchedBridge');
    var ReactNative=require('ReactNative');

    var AppRegistry={

        runApplication:function(appKey,appParameters){
            runnables[appKey].run(appParameters);
            },
        }

    BatchedBridge.registerCallableModule(
        'AppRegistry',
        AppRegistry);

    module.exports=AppRegistry;
});

有前面的讲解,现在看这个应该不态费劲了,可以看到AppRegistry模块工厂函数中,执行了 BatchedBridge.registerCallableModule('AppRegistry',AppRegistry);,把自己注册到BatchedBridge的CallableModule中,所以在上一节中,__callFunction才能在_callableModules找到AppRegistry实例,才能调用其runApplication函数。自己写的模块代码可以用React Native这种方式暴露给Natvie调用,和直接暴露的区别是,符合React Natvie的模块化原则,另外一个直观的好处是你的模块可以是懒加载的,并且不会污染全局空间。

目前终于把从N-JS的整个路径跑通了,我们梳理下整个流程看看。

1 [RCTBatchedBridge enqueueJSCall:@“AppRegistry.runApplication” args:["MGReactNative",{"rootTag":1,"initialProps":{}}]];

2 RCTJavaScriptContext callFunctionOnModule:@"AppRegistr"
                      method:@"runApplication"
                   arguments:["MGReactNative",{"rootTag":1,"initialProps":{}}]
                    callback:(RCTJavaScriptCallback)onComplete

//main.js
3  __fbBatchedBridge.callFunctionReturnFlushedQueue("AppRegistr","runApplication",["MGReactNative",{"rootTag":1,"initialProps":{}}])

//main.js
4  BatchedBridge.__callFunction("AppRegistr","runApplication",["MGReactNative",{"rootTag":1,"initialProps":{}}])

//main.js
5 var moduleMethods = BatchedBridge._callableModules[module];
    if (!moduleMethods) {
      moduleMethods = require(module);
    }
    moduleMethods[method].apply(moduleMethods, args);

JS调用Native (JS->Native)

接下来我们看看从JS如何调用Native,换句话说Native如何开放API给JS

我们以弹Alert框的接口为例,这是Native的OC代码,导出RCTAlertManager类的alertWithArgs:(NSDictionary *)args
callback:(RCTResponseSenderBlock)callback)方法

@interface RCTAlertManager() : NSObject <RCTBridgeModule, RCTInvalidating>
...
@end

@implementation RCTAlertManager
RCT_EXPORT_MODULE()

RCT_EXPORT_METHOD(alertWithArgs:(NSDictionary *)args
                  callback:(RCTResponseSenderBlock)callback)
{
...
}
#end

要把OC类或实例的函数导出给JS用,需实现以下三个步骤

  • OC类实现RCTBridgeModule协议
  • 在.m的类实现中加入RCT_EXPORT_MODULE(),帮助你实现RCTBridgeModule协议
  • 要导出的函数用RCT_EXPORT_METHOD()宏括起来,不用这个宏,不会导出任何函数

现在从JS里可以这样调用这个方法:

var RCTAlertManager=require('react-native').NativeModules.AlertManager;
RCTAlertManager.alertWithArgs({message:'JS->Native Call',buttons:[{k1:'button1'},{k2:'button1'}]},function(id,v) 
{console.log('RCTAlertManager.alertWithArgs() id:' + id +' v:' + v)});

执行之后的效果,弹出一个Alert

alert.png

对于详细的如何导出函数推荐阅读Native Modules

我们今天的目的不是和女神喝茶聊天,是深入女神内心,是内心咳咳。来看看今天的重点

动态导出Native API,延迟加载Native 模块

在JS中可以直接使用RCTAlertManager.alertWithArgs来调用,说明JS中已经定义了和OC对象相对应的JS对象,我们从导出一个Native类开始,完整跟踪下这个过程。

生成Native API 配置表

RCTAlertManager类实现了RCTBridgeModule协议,并且在类的实现里包含了RCT_EXPORT_MODULE() 宏

@protocol RCTBridgeModule <NSObject>

 #define RCT_EXPORT_MODULE(js_name) \
RCT_EXTERN void RCTRegisterModule(Class); \
+ (NSString *)moduleName { return @#js_name; } \
+ (void)load { RCTRegisterModule(self); }

// Implemented by RCT_EXPORT_MODULE
+ (NSString *)moduleName;

@optional

在OC里,一个类所在文件被引用时,系统会调用其+(void)load函数,当RCTAlertManager所在文件被引用时,系统调用load 函数,函数里简单的调用RCTRegisterModule(self) 把自己注册到一个全局数组RCTModuleClasses,这样系统中导出的类都会自动注册到这个全局变量数组里(so easy)。

在JS中有一个BatchedBridge用来和Native通讯,在Natvie中也有一个RCTBatchedBridge类,它封装了JSContext即JS引擎
在RCTBatchedBridge start 函数中,做了5件事

  1. jsbundle文件的下载或本地读取(异步)
  2. 初始化导出给JS用的Native模块
  3. 初始化JS引擎
  4. 生成配置表,并注入到JS引擎中,
  5. 执行jsbundle文件。
 //伪代码
 - (void)start
{
  //1  jsbundle文件的下载或本地读取(异步)
  NSData *sourceCode;
  [self loadSource:^(NSError *error, NSData *source) {sourceCode = source}];

  //2 初始化导出给JS用的Native模块
  [self initModules];

  //3 初始化JS引擎
  [self setUpExecutor];

  //4 生成Native模块配置表 把配置表注入到JS引擎中
  NSSting* config = [self moduleConfig];
  [self injectJSONConfiguration:config onComplete:^(NSError *error) {});
  
  //5 最后执行jsbundle
  [self executeSourceCode:sourceCode];

}

现在我们最关心第二步初始化Native模块 initModules 和moduleConfig 到底是什么

//伪代码
- (void)initModules
{
  //遍历上节讲到的RCTGetModuleClasses全局数组,用导出模块的类或者实例创建RCTModuleData
  for (Class moduleClass in RCTGetModuleClasses()) 
  {
    NSString *moduleName = RCTBridgeModuleNameForClass(moduleClass);
    
    //这里一个很有意思的地方,如果导出的类或其任何父类重写了init方法,或者类中有setBridge方法
    //则React Native假设开发者期望这个导出模块在Bridge第一次初始化时实例化,否则怎么样,大家想想
    if ([moduleClass instanceMethodForSelector:@selector(init)] != objectInitMethod ||
        [moduleClass instancesRespondToSelector:setBridgeSelector]) {
      module = [moduleClass new];
    }

    // 创建RCTModuleData
    RCTModuleData *moduleData;
    if (module) {
        moduleData = [[RCTModuleData alloc] initWithModuleInstance:module];
    } else {
       moduleData = [[RCTModuleData alloc] initWithModuleClass:moduleClass                                                   bridge:self];
    }

     //保存到数组中,数组index就是这个模块的索引
     [_moduleDataByID addObject:moduleData];
  }
}

initModules里根据是否重写init或添加了setBridge来决定是不是要马上实例化RCTGetModuleClasses里的导出类,然后用实例或类创建RCTModuleData,缓存到本地,以便JS调用时查询。

再来看第四步导出的 NSSting* config = [self moduleConfig] 是什么内容

    {"remoteModuleConfig":
    [["RCTStatusBarManager"],
    ["RCTSourceCode"],
    ["RCTAlertManager"],
    ["RCTExceptionsManager"],
    ["RCTDevMenu"],
    ["RCTKeyboardObserver"],
    ["RCTAsyncLocalStorage"],
    .
    .
    .
    ]}  

它仅仅是一个类名数组。

注入配置表到JS引擎,并创建对应的JS对象

生产配置表后,通过下面的方法把这个类名数组注入到JSContext,赋值给JS全局变量__fbBatchedBridgeConfig

    [_javaScriptExecutor injectJSONText:configJSON
                  asGlobalObjectNamed:@"__fbBatchedBridgeConfig"
                             callback:onComplete];

在JS端,当有人引用了BatchedBridge var BatchedBridge=require('BatchedBridge');,其工厂函数会通过 __fbBatchedBridgeConfig配置表创建MessageQueue的实例BatchedBridge

    var MessageQueue=require('MessageQueue');

    var BatchedBridge=new MessageQueue(
        __fbBatchedBridgeConfig.remoteModuleConfig,
        __fbBatchedBridgeConfig.localModulesConfig);

我们看看MessageQueue的构造函数,构造函数里为每个导出类创建了一个对应的module对象,因为此时config里只有一个导出类的名字,所以这里只为这个对象增加了一个成员变量 module.moduleID,并把module保存到this.RemoteModules数组里

  _genModule(config, moduleID) {
    let module = {};
    if (!constants && !methods && !asyncMethods) {
      module.moduleID = moduleID;
    }
    this.RemoteModules[moduleName] = module;
  }

接着我们顺藤摸瓜看看那里使用的BatchedBridge.RemoteModules

NativeModules模块

NativeModules在初始化时,用BatchedBridge.RemoteModules保存的类名列表,为每个JS对象增加了函数等属性

__d('NativeModules',function(global, require, module, exports) {  'use strict';
    var RemoteModules=require('BatchedBridge').RemoteModules;
    var NativeModules={};
    
     //遍历NativeModules中导出类名
    Object.keys(RemoteModules).forEach(function(moduleName){
    
       //把类名定义为NativeModules的一个属性,比如AlertManager类,定义只有就可以用NativeModules.AlertManager 访问
        Object.defineProperty(NativeModules,moduleName,{
        
            //这个属性(AlertManager)是可以遍历的,当然属性也是个对象里面有属性和函数
            enumerable:true,
            
            //属性都有get和set函数,当调用访问这个属性时,会调用get函数  NativeModules.AlertManager         
            get:function(){

                var module=RemoteModules[moduleName];
                if(module&&typeof module.moduleID==='number'&&global.nativeRequireModuleConfig){
                
                    //调用Native提供的全局函数nativeRequireModuleConfig查询AlertManager 导出的常量和函数
                    var json=global.nativeRequireModuleConfig(moduleName);                                   
                    module=config&&BatchedBridge.processModuleConfig(JSON.parse(json),module.moduleID);
                    RemoteModules[moduleName]=module;
                }
                return module;
            }
        });
    });
    module.exports=NativeModules;
});

React Native 把所有的Native导出类定义在一个NativeModules模块里,所以使用Natvie接口时也可以直接这样拿到对应的JS对象
var RCTAlertManager=require('NativeModules').AlertManager;

代码里我加了注释
思考一个问题,为什么React Natvie搞的那么麻烦,为什么不在上一个步骤里(MessageQueue的构造函数)里就创建出完整的JS对象。

没错,就是模块的懒加载,虽然Native导出了Alert接口,在JS引擎初始化后,JS里只存在一个名字为AlertManager的空对象

906C7A90-0A85-4FD6-B433-39CE041D4445.png

当调用了RCTAlertManager.alertWithArgs({message:'JS->Native Call',buttons:[{k1:'button1'}时,才会调用AlertManager 的get函数到Native里查询导出的常量和函数,并定义到AlertManager中。

7RGT1@Z}N19_9{KQ~P_SDFE.jpg

Native模块对应的JS对象中函数是如何调用到Native

RCTAlertManager.alertWithArgs 这个函数是如何调用到Native里的呢,在BatchedBridge.processModuleConfig函数中,用_genMethod创建了一个闭包fn为每个函数赋值,这个函数转调self.__nativeCall(module, method, args, onFail, onSucc); 我们调用RCTAlertManager.alertWithArgs函数,其实都是调用的这个fn闭包。

    _genMethod(module, method, type) {
      fn = function(...args) {
        return self.__nativeCall(module, method, args, onFail, onSucc);
      };
    return fn;
  }

__nativeCall,好熟悉的名字,

  __nativeCall(module, method, params, onFail, onSucc) {

    this._queue[MODULE_IDS].push(module);
    this._queue[METHOD_IDS].push(method);
    this._queue[PARAMS].push(params);

    global.nativeFlushQueueImmediate(this._queue);
    this._queue = [[],[],[]];
    this._lastFlush = now;

  }

global.nativeFlushQueueImmediate 是Native提供的接口,__nativeCall把需要调用的module,method,params都塞到队列里,然后传递到Native,

我们在回到Native 找到上文提到的两个关键接口,Native模块查询接口:global.nativeRequireModuleConfig和调用接口global.nativeFlushQueueImmediate,他们是在JS引擎(JSContext)初始化时,定义到全局变量的。

//RCTContextExecutor setUP
//简化过的代码
- (void)setUp
{
   ...
    self->_context.context[@"nativeRequireModuleConfig"] = ^NSString *(NSString *moduleName) {
      NSArray *config = [weakBridge configForModuleName:moduleName];
      return RCTJSONStringify(config, NULL);
    };

    self->_context.context[@"nativeFlushQueueImmediate"] = ^(NSArray<NSArray *> *calls){
      [weakBridge handleBuffer:calls batchEnded:NO];
    };
    ...
}

[weakBridge handleBuffer:calls batchEnded:NO]; 经过一系列传递,调用到_handleRequestNumber 中,用moduleID找到RCTModuleData,再用methodID 找到id<RCTBridgeMethod> method 然后在moduleData.instance实例中执行

- (BOOL)_handleRequestNumber:(NSUInteger)i
                    moduleID:(NSUInteger)moduleID
                    methodID:(NSUInteger)methodID
                      params:(NSArray *)params
{

  RCTModuleData *moduleData = _moduleDataByID[moduleID];
  id<RCTBridgeMethod> method = moduleData.methods[methodID];

  [method invokeWithBridge:self module:moduleData.instance arguments:params];
}

这里有必要再强调一次moduleData.instance 这个地方。

- (id<RCTBridgeModule>)instance
{
  if (!_instance) {
    _instance = [_moduleClass new];
    ...
  }
  return _instance;
}

还记的前面BatchedBridge 初始化时的initModules吗

    //这里一个很有意思的地方,如果导出的类或其任何父类重写了init方法,或者类中有setBridge方法
    //则React Native假设开发者期望这个导出模块在Bridge第一次初始化时实例化,否则怎么样,大家想想
    if ([moduleClass instanceMethodForSelector:@selector(init)] != objectInitMethod ||
        [moduleClass instancesRespondToSelector:setBridgeSelector]) {
      module = [moduleClass new];
    }

否则就是在用户真正调用时,在moduleData.instance里实例化,React Native已经懒到骨髓了。

RCTModuleData中每个函数的封装 RCTModuleMethod里还有一个优化点,JS传递到Native的参数需要进行响应的转换,RCTModuleMethod在调用函数只前,先预解析一下,创建每个参数转换的block,缓存起来,这样调用时,就直接使用对应函数指针进行参数转换了,大要详细了解可以看 - (void)processMethodSignature函数。

回调函数

前面我们为了直观,忽略了回调函数,alertWithArgs的第二个参数是一个JS回调函数,用来指示用户点击了哪个button,并打印出一行日志。

RCTAlertManager.alertWithArgs({message:'JS->Native Call',buttons:[{k1:'button1'},{k2:'button1'}]},function(id,v) 
{console.log('RCTAlertManager.alertWithArgs() id:' + id +' v:' + v)});

回调函数的调用和直接从Native调用JS是差不多的,再回头看看__nativeCall 函数我们忽略的部分

  __nativeCall(module, method, params, onFail, onSucc) {

    //Native接口最多支持两个回调
    if (onFail || onSucc) {
      onFail && params.push(this._callbackID);
      this._callbacks[this._callbackID++] = onFail;
      onSucc && params.push(this._callbackID);
      this._callbacks[this._callbackID++] = onSucc;
    }
    
    this._queue[MODULE_IDS].push(module);
    this._queue[METHOD_IDS].push(method);
    this._queue[PARAMS].push(params);

    global.nativeFlushQueueImmediate(this._queue);
    this._queue = [[],[],[]];
    this._lastFlush = now;

  }

可以看到把onFail,onSucc两个函数类型转化为两个数字ID插入到参数列表后面,并把函数函数缓存起来。
从Native调用过来也比较简单了,传递过callbackID到JS,就可以执行到回调函数。

JS传递的参数仅仅是个整形ID,Native如何知道这个ID就是个回调函数呢?

答案是和其他参数一样通过Native的函数签名,如果发现对应的参数是个block,则从JS传递过来的ID就是对应的回调ID,把其转化为RCTResponseSenderBlock的闭包。

RCT_EXPORT_METHOD(alertWithArgs:(NSDictionary *)args callback:(RCTResponseSenderBlock)callback)

到此为止,我们已经把整个JS->Natvie的流程都走通了,
梳理一下整个流程。

调用图.png

总结一下

  1. Native初始化时, Native生成要导出模块的名字列表(注意注意注意),仅仅是模块(类)名字列表, ModuleConfig
  1. 在React Native 的JS引擎初始化完成后,向JSContext注入ModuleConfig,赋值到JS全局变量 __fbBatchedBridgeConfig
  2. 还记得那个N->JS大使---JS对象BatchedBridge吗,BatchedBridge创建的时候会用__fbBatchedBridgeConfig变量里Native模块名字列表定义一个同名的JS对象,但是是一个没有任何方法的空对象,只增加了一个获取方法数组的get函数。此时初始化的操作已完成。
  3. 很久很久之后,有人用RCTAlertManager.alertWithArgs 调用了Native的代码,咳咳,这人是我,此时JS去获取RCTAlertManager方法列表时,发现是空的,就调用Native提供的查询函数nativeRequireModuleConfig 获取RCTAlertManager对象的详细的导出信息(方法列表),并定义成同名的JS函数,此函数转调到OC的实现
  4. 此时RCTAlertManager对应的JS对象才定义完整,JS找到了alertWithArgs函数,每个对应的JS函数都是一个封装了调用__nativeCall的闭包,JS通过此函数转发到Native

可以看出,Native导出的配置表并不是在一开始就完整的注入JS并定义对应的JS对象,而是仅仅注入了一个模块名字,当运行期间有人调用的时候,才再从Native查询调用模块的详细配置表,这种懒加载机制缓解了一个大型的app导出的Api很多,全部导入JS导致初始化时内存占用过大的问题。

消息循环

线程问题

React Native为JS引擎创建了一个独立的线程

//RCTJavaScriptContext
- (instancetype)init
{
  NSThread *javaScriptThread = [[NSThread alloc] initWithTarget:[self class]
                                                       selector:@selector(runRunLoopThread)
                                                         object:nil];
  javaScriptThread.name = @"com.facebook.React.JavaScript";
  [javaScriptThread start];
  return [self initWithJavaScriptThread:javaScriptThread context:nil];
}

所有的JS代码都运行在"com.facebook.React.JavaScript"后台线程中,所有的操作都是异步,不会卡死主线程UI。并且JS调用到Native中的接口中有强制的线程检查,如果不是在React线程中则抛出异常。
这样有一个问题,从JS调用Native中的代码是执行在这个后台线程中,我们上文的RCTAlertManager.alertWithArgs明显是个操作UI的接口,执行在后台线程会crash,在导出RCTAlertManager时,通过实现方法- (dispatch_queue_t)methodQueue,原生模块可以指定自己想在哪个队列中被执行

- (dispatch_queue_t)methodQueue
{
  return dispatch_get_main_queue();
}

类似的,如果一个操作需要花费很长时间,原生模块不应该阻塞住,而是应当声明一个用于执行操作的独立队列。举个例子,RCTAsyncLocalStorage模块创建了自己的一个queue,这样它在做一些较慢的磁盘操作的时候就不会阻塞住React本身的消息队列:

- (dispatch_queue_t)methodQueue
{
  return dispatch_queue_create("com.facebook.React.AsyncLocalStorageQueue", DISPATCH_QUEUE_SERIAL);
}

React的消息循环

这是典型的事件驱动机制和消息循环,当无任何事件时,runloop(消息循环)处于睡眠状态,当有事件时,比如用户操作,定时器到时,网络事件等等,触发一此消息循环,最总表现为UI的改变或数据的变化。

消息循环.png

这里要注意的是,以上我们讲到从 JS调用到Native是调用global.nativeFlushQueueImmediate 立即执行的。React消息循环这里做了一次缓存,比如用户点击一次,所有触发的JS->N的调用都缓存到MessageQueue里,当N->JS调用完成时,以返回值的形式返回MessageQueue, 减少了N->JS的交互次数。缓存时间是 MIN_TIME_BETWEEN_FLUSHES_MS = 5毫秒内的调用。

  __nativeCall(module, method, params, onFail, onSucc) {

    this._queue[MODULE_IDS].push(module);
    this._queue[METHOD_IDS].push(method);
    this._queue[PARAMS].push(params);

    var now = new Date().getTime();
    if (global.nativeFlushQueueImmediate &&
        now - this._lastFlush >= MIN_TIME_BETWEEN_FLUSHES_MS) {
      global.nativeFlushQueueImmediate(this._queue);
      this._queue = [[],[],[]];
      this._lastFlush = now;
    }

  }

MIN_TIME_BETWEEN_FLUSHES_MS时间内的调用都会缓存到this._queue,以返回值的形式返回给Native,形成一次消息循环

  callFunctionReturnFlushedQueue(module, method, args) {
    guard(() => {
      this.__callFunction(module, method, args);
      this.__callImmediates();
    });

    return this.flushedQueue();
  }


  flushedQueue() {
    this.__callImmediates();

    let queue = this._queue;
    this._queue = [[],[],[]];
    return queue[0].length ? queue : null;
  }

本篇的内容就是这些,想看懂容易,想尽量简洁明了的总结成文字真是一件很不容易的事情,特别是这里很多JS的代码。有问题大家留言指正。下一篇将介绍ReactNative的渲染原理。
http://www.jianshu.com/p/269b21958030

React Native
Web note ad 1