ReactNative源码解析——通讯机制详解(callback、线程)

时间 2019-11-30

标签 reactnative 源码解析通讯机制详解 callback 线程繁體版

原文原文链接

本文经过分析 RN 源码，简要介绍了 JS to Native 的 callback 实现原理以及 RN 中的三个重要线程。react

本文同时发表于个人我的博客git

callback

前两篇文章ReactNative源码解析——通讯机制详解(1/2) 、ReactNative源码解析——通讯机制详解(2/2)分别介绍了 RN 通讯机制中的 JS to Native、Native to JS 的执行流程。为了集中注意力抓住主要流程，当时没有分析调用过程当中的 callback 问题，下面简要分析一下 JS to Native callback 的实现原理。github

文中所列代码均作了简化处理。json

首先，来看一个具体的例子：数组

RCT_EXPORT_METHOD(showShareActionSheetWithOptions:(NSDictionary *)options
                  failureCallback:(RCTResponseErrorBlock)failureCallback
                  successCallback:(RCTResponseSenderBlock)successCallback)
{
    UIActivityViewController *shareController =
    [[UIActivityViewController alloc] initWithActivityItems:items applicationActivities:nil];

    shareController.completionWithItemsHandler = 
    ^(NSString *activityType, 
       BOOL completed, 
       __unused NSArray *returnedItems, 
       NSError *activityError) {
           if (activityError) {
               failureCallback(activityError);
           } 
           else {
               successCallback(@[@(completed), RCTNullIfNil(activityType)]);
           }
       };
}
复制代码

showShareActionSheetWithOptions:failureCallback:successCallback:是RCTActionSheetManager曝露给 JS 的方法之一，其包含两个 callback：failureCallback、successCallback。其中，RCTResponseErrorBlock、RCTResponseSenderBlock的定义以下：app

/** * The type of a block that is capable of sending a response to a bridged * operation. Use this for returning callback methods to JS. */
typedef void (^RCTResponseSenderBlock)(NSArray *response);

/** * The type of a block that is capable of sending an error response to a * bridged operation. Use this for returning error information to JS. */
typedef void (^RCTResponseErrorBlock)(NSError *error);
复制代码

JS 中的调用：ide

ActionSheetIOS.showShareActionSheetWithOptions({
        url: uri,
        excludedActivityTypes: [
          'com.apple.UIKit.activity.PostToTwitter'
        ]
      },
      (error) => alert(error),
      (completed, method) => {
        var text;
        if (completed) {
          text = `Shared via ${method}`;
        } else {
          text = 'You didn\'t share';
        }
        this.setState({text});
      });
复制代码

上述代码的第7行、8~16行，分别设置了两个 fail、success callback。 oop

上图所示是 JS to Native 中最终在 Native 侧调用相应方法的调用栈，在 ReactNative源码解析——通讯机制详解(1/2)中提到过，但限于篇幅没有展开讨论。

今天的分析就从RCTModuleMethod#invokeWithBridge:module:arguments:开始。ui

RCTModuleMethod#invokeWithBridge:

- (id)invokeWithBridge:(RCTBridge *)bridge
                module:(id)module
             arguments:(NSArray *)arguments
{
    if (_argumentBlocks == nil) {
        [self processMethodSignature];
    }

    // Set arguments
    //
    NSUInteger index = 0;
    for (id json in arguments) {
        RCTArgumentBlock block = _argumentBlocks[index];
        if (!block(bridge, index, RCTNilIfNull(json))) {
            return nil;
        }
        index++;
    }

    // Invoke method
    //
    [_invocation invokeWithTarget:module];
    return nil;
}
复制代码

在invokeWithBridge:module:arguments:内部(第6行)调用了processMethodSignature方法，从名称可知该方法是处理『方法签名』的(被处理的方法固然是被 JS 调用的 Native method 了)：this

- (void)processMethodSignature
{
    NSArray<RCTMethodArgument *> *arguments;
    _selector = RCTParseMethodSignature(_methodInfo->objcName, &arguments);

    // Create method invocation
    NSMethodSignature *methodSignature =  [_moduleClass instanceMethodSignatureForSelector:_selector];
    NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSignature];
    invocation.selector = _selector;
    _invocation = invocation;

    // Process arguments
    //
    NSUInteger numberOfArguments = methodSignature.numberOfArguments;
    NSMutableArray<RCTArgumentBlock> *argumentBlocks =
    [[NSMutableArray alloc] initWithCapacity:numberOfArguments - 2];

    for (NSUInteger i = 2; i < numberOfArguments; i++) {
        const char *objcType = [methodSignature getArgumentTypeAtIndex:i];
        RCTMethodArgument *argument = arguments[i - 2];
        NSString *typeName = argument.type;
        SEL selector = RCTConvertSelectorForType(typeName);
        if ([RCTConvert respondsToSelector:selector]) {
            switch (objcType[0]) {
                case _C_CHR: {
                    char (*convert)(id, SEL, id) = (typeof(convert))objc_msgSend;
                    [argumentBlocks addObject:^(__unused RCTBridge *bridge, NSUInteger index, id json) {
                        char value = convert([RCTConvert class], selector, json);
                        [invocation setArgument:&value atIndex:(index) + 2];
                        return YES;}];
                        break;
                }
            }
        }
        else if ([typeName isEqualToString:@"RCTResponseSenderBlock"]) {
            [argumentBlocks addObject:^(__unused RCTBridge *bridge, NSUInteger index, id json) {
                void (^block)(NSArray *) = ^(NSArray *args) {
                    [bridge enqueueCallback:json args:args];
                };
                id value = json ? [block copy] : (id)^(__unused NSArray *_){};
                CFBridgingRetain(value);

                [invocation setArgument:&value atIndex:(index) + 2];
                return YES;
            }];
        } 
        // ...
    }
    _argumentBlocks = argumentBlocks;
}
复制代码

processMethodSignature方法主要作的工做：

从被调方法的名称(字符串)中解析出 selector 以及RCTMethodArgument格式的参数(第4行)；
根据第一步中解析出的 selector 生成methodSignature、invocation(第7~10行)；
为每一个参数生成一个 block(argumentBlock)，并添加到argumentBlocks数组中： 1. 若参数的类型在 JS 与 Native 间能够转换(如：基础类型、字符串、数组等)(第23~34行)，在argumentBlock中完成 JS 类型参数 to Native 类型参数的转换(第28行)，并将获得的结果设置到invocation上(第29行)； 2. 若参数类型是 block(如：RCTResponseSenderBlock、RCTResponseErrorBlock等)(第35~46行)，则在argumentBlock中生成一个 bolck，用做调用方法时的实参(由于 block 类型没法从 JS 直接传给 Native)，在该 block 中调用了bridge的enqueueCallback:args:方法。

再回到RCTModuleMethod#invokeWithBridge:module:arguments:方法，第12~18行，执行了processMethodSignature方法为每一个参数生成的 block，最终的效果就是将 JS 侧传入的参数值转换成 Native 类型并设置到invocation上。

经过上述分析可知，对于 block 类型的参数(callback)最终会调用了RCTCxxBridge#enqueueCallback:args:方法。

void JSCExecutor::invokeCallback(const double callbackId, const folly::dynamic& arguments) {
    auto result = [&] {
        try {
            return m_invokeCallbackAndReturnFlushedQueueJS->callAsFunction({
                Value::makeNumber(m_context, callbackId),
                Value::fromDynamic(m_context, std::move(arguments))
            });
        } catch (...) {}
    }();
    callNativeModules(std::move(result));
}
复制代码

沿调用链最终来到JSCExecutor::invokeCallback，第4行经过 hook，实际调用的是 JS 侧的MessageQueue#invokeCallbackAndReturnFlushedQueue方法。下面咱们来看看 JS 侧如何处理 callback。

NativeModules#genMethod

还记得genMethod方法吗？

function genMethod(moduleID: number, methodID: number, type: MethodType) {
    let fn = null;
    fn = function(...args: Array<any>) {
        const lastArg = args.length > 0 ? args[args.length - 1] : null;
        const secondLastArg = args.length > 1 ? args[args.length - 2] : null;
        const hasSuccessCallback = typeof lastArg === 'function';
        const hasErrorCallback = typeof secondLastArg === 'function';
        const onSuccess = hasSuccessCallback ? lastArg : null;
        const onFail = hasErrorCallback ? secondLastArg : null;
        const callbackCount = hasSuccessCallback + hasErrorCallback;
        args = args.slice(0, args.length - callbackCount);
        BatchedBridge.enqueueNativeCall(moduleID, methodID, args, onFail, onSuccess);
    };
    fn.type = type;
    return fn;
}
复制代码

在ReactNative源码解析——通讯机制详解(1/2) 一文中介绍过，JS 在调用 Native 方法时，会在 JS 侧动态生成一个对应的 JS 方法。在genMethod方法的第4~9行，处理了调用参数的最后2个，判断是不是 callback 类型(function 类型)。从上述处理代码中能够得出：

对于 callback 类型的参数，做了特殊处理，将其从参数列表中剥离出来；
一个方法最多只能有两个 callback 类型的参数；
callback 类型的参数只能位于参数列表的最后。

下面再来看看MessageQueue.enqueueNativeCall：

enqueueNativeCall(
    moduleID: number,
    methodID: number,
    params: any[],
    onFail: ?Function,
    onSucc: ?Function,
  ) {
    if (onFail || onSucc) {
        // Encode callIDs into pairs of callback identifiers by shifting left and using the rightmost bit
        // to indicate fail (0) or success (1)
        // eslint-disable-next-line no-bitwise
        onFail && params.push(this._callID << 1);
        // eslint-disable-next-line no-bitwise
        onSucc && params.push((this._callID << 1) | 1);
        this._successCallbacks[this._callID] = onSucc;
        this._failureCallbacks[this._callID] = onFail;
    }
    this._callID++;
}
复制代码

能够看到：

对于 callback 类型的参数，在 JS 与 Native 间传递的是 callbackID(_successCallbacks、_failureCallbacks中的下标)；
JS 侧的 callback function 存储在_successCallbacks、_failureCallbacks中。

咱们再回到调用流程中的MessageQueue#invokeCallbackAndReturnFlushedQueue方法，在该方法中调用了__invokeCallback方法：

__invokeCallback(cbID: number, args: any[]) {
    // The rightmost bit of cbID indicates fail (0) or success (1), the other bits are the callID shifted left.
    // eslint-disable-next-line no-bitwise
    const callID = cbID >>> 1;
    // eslint-disable-next-line no-bitwise
    const isSuccess = cbID & 1;
    const callback = isSuccess
      ? this._successCallbacks[callID]
      : this._failureCallbacks[callID];

    if (!callback) {
      return;
    }

    this._successCallbacks[callID] = this._failureCallbacks[callID] = null;
    callback(...args);
}
复制代码

在__invokeCallback方法中，经过 cbID 在_successCallbacks、_failureCallbacks中找到相应的 callback function，并执行。至此，callback 的流程所有结束。

RN 经过 callbackID 的最后一位是0仍是1，肯定callback 是 success 仍是 fail。

小结

JS 与 Native 间传递的是 callbackID；
callback 参数只能位于方法参数列表的最后面而且最多只能有2个；
RN 经过 callbackID 二进制的最后一位是0仍是1，肯定是 success 仍是 fail；
因为 JS callback function 没法直接传递给 Native，Native 侧会生成一个 block。

线程模型

在 RN 中，有3类线程须要关注：

JS Thread；
Native Module Thread；
UI Manager Thread(Shadow Thread)。

JS Thread

JS Thread 是 JS 执行以及 JS 与 Native 通讯线程。简单讲，Native 在此线程执行 JS 代码，JS 调用 Native 接口也发生在此线程上。 JS Thread 的初始化发生在RCTCxxBridge#start方法中：

_jsThread = [[NSThread alloc] initWithTarget:[self class]
                                                   selector:@selector(runRunLoop)
                                                     object:nil];
_jsThread.name = RCTJSThreadName;
_jsThread.qualityOfService = NSOperationQualityOfServiceUserInteractive;
[_jsThread start];
复制代码

在阅读 RN 源码时可能会发现RCTMessageThread类，它是对 JS Thread 的 C++封装。具体源码就不列了。还会发现RCTJSThread变量：

dispatch_queue_t RCTJSThread;
RCTJSThread = (id)kCFNull;
复制代码

NOTE: RCTJSThread is not a real libdispatch queue

RCTJSThread的做用只是用于标识，确保须要在 JSThread 上执行的操做能在该线程上执行：

Native module Thread

JS 在调用 Native 方法时，Native 方法在哪一个线程上执行？ Native Module 能够实现methodQueue方法，指定执行队列：- (dispatch_queue_t)methodQueue。那若是 Native Module 没有实现methodQueue方法，会如何？

- (void)setUpMethodQueue
{
    BOOL implementsMethodQueue = [_instance respondsToSelector:@selector(methodQueue)];
    if (implementsMethodQueue && _bridge.valid) {
        _methodQueue = _instance.methodQueue;
    }
    if (!_methodQueue && _bridge.valid) {
        // Create new queue (store queueName, as it isn't retained by dispatch_queue)
        _queueName = [NSString stringWithFormat:@"com.facebook.react.%@Queue", self.name];
        _methodQueue = dispatch_queue_create(_queueName.UTF8String, DISPATCH_QUEUE_SERIAL);
    }
}
复制代码

在RCTModuleData#setUpMethodQueue方法中能够看到：若Native Module 没有实现methodQueue方法，则为该 Native Module 生成一个串行队列。那么在实现 Native module#methodQueue 方法时须要注意什么？来了解一下 RN 自带的 module 实现状况：

main thread — 如 RCTActionSheetManager，在接口中有 UI 操做；
JSThread — 如 RCTTiming、RCTEventDispatcher，实时性要求较高的 (慎用，This can have serious implications for performance, so only use this if you're sure it's what you need)；
UI Manager thread — 如 RCTUIManager、RCTViewManager，UI 组件；
Custom thread — 如 RCTAsyncLocalStorage，耗时操做。

UI Manager Thread(Shadow Thread)

UI Manager Thread，UI 组件(UI module)接口执行线程。 UI 不该该在 main thread？ RN 为了提升效率(如: 帧率)，会先在UI Manager Thread作一些预处理操做(如计算 frame)，最终在渲染上屏时会切到 main thread。

dispatch_queue_t RCTGetUIManagerQueue(void)
{
    static dispatch_queue_t shadowQueue;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        if ([NSOperation instancesRespondToSelector:@selector(qualityOfService)]) {
            dispatch_queue_attr_t attr = dispatch_queue_attr_make_with_qos_class(DISPATCH_QUEUE_SERIAL, QOS_CLASS_USER_INTERACTIVE, 0);
            shadowQueue = dispatch_queue_create(RCTUIManagerQueueName, attr);
        }
        else {
            shadowQueue = dispatch_queue_create(RCTUIManagerQueueName, DISPATCH_QUEUE_SERIAL);
            dispatch_set_target_queue(shadowQueue, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0));
        }
    });
    return shadowQueue;
}
复制代码

能够看到，UI Manager Thread 是一个高优先级的串行队列。

小结

全部 JS 代码都会在独立线程 JSThread 上执行；
可经过 methodQueue 方法自定义 Native module 执行线程；
为了提升效率，全部 UI 组件都会在 UI Manager thread 上预处理，再在 main thread 上渲染上屏。