In-depth understanding of the core principles of React Native (Bridge of React Native)

In this article we assume you already know the basics of React Native, and we will focus on the inner workings when native and JavaScript communicate.

Main Thread

Before we get started, we need to know that there are three main threads in React Native:

• Shadow queue: responsible for layout work
• main thread: UIKit works in this thread (Translator's note: UI Manager thread can be regarded as the main thread, which is mainly responsible for the logic of page interaction and control drawing)
• JavaScript thread: thread that runs JS code

In addition, in general, each native module has its own GCD queue, unless otherwise specified (explained later)

*The shadow queue is actually more like a GCD queue than a thread

Native Module

If you don't know how to create a Native module, I recommend you read the documentation.

This is an example of a native module Person that is both called by JavaScript and can call JavaScript.

@interface Person : NSObject <RCTBridgeModule> 
@end 
@implementation Logger 
RCT_EXPORT_MODULE() 
RCT_EXPORT_METHOD(greet:(NSString *)name) 
{ 
 NSLog(@"Hi, %@!", name); 
 [_bridge.eventDispatcher sendAppEventWithName:@"greeted" body:@{ @"name": name }];     
} 
@end

We will focus on the two macros RCT_EXPORT_MODULE and RCT_EXPORT_METHOD, what they expand to, what their roles are, and how they work.

RCT_EXPORT_MODULE([js_name])

As the name of this method suggests, it exports your module, but what does export mean in this specific context? It means that the bridge knows about your module.

Its definition is actually very simple:

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

It does the following:

• First, declare RCTRegisterModule as an external function, which means that the implementation of this function is not visible to the compiler, but is available at the link stage.
• Declare a method moduleName that returns an optional macro parameter js_name so that the module has a different class name in JS than in Objective-C
• Declare a load method (when the app is loaded into memory, the load method of each class will be called), the load method calls RCTRegisterModule, and then the bridge knows about the exposed module

RCT_EXPORT_METHOD(method)

This macro is more interesting, it does not add anything to your method, in addition to declaring the specified method, it also creates a new method. The new method looks like this:

+ (NSArray *)__rct_export__120 
{ 
 return @[ @"", @"log:(NSString *)message" ];
}

It is constructed by combining a prefix (__rct_export__) and an optional js_name (empty in this case) with the line number of the declaration and the __COUNTER__ macro.

The purpose of this method is to return an array containing an optional js_name and method signature. The role of this js_name is to avoid method naming conflicts.

Runtime

This whole setup is just to provide information for the bridge so that it can find everything exported, modules and methods, but this all happens at load time, now let's look at how it is used at runtime.

Here is the dependency graph when the bridge is initialized:

Initialization module

All RCTRegisterModule does is push the class into the array so it can be found when instantiating a new bridge. The bridge iterates over all the modules in the array, creates an instance for each module, stores a reference to the instance on the bridge side, gives the module instance a reference to the bridge (so we can call each other on both sides), then checks if the module instance has a queue specified to run on, otherwise gives it a new queue, separate from the other modules:

NSMutableDictionary *modulesByName; // = ... 
for (Class moduleClass in RCTGetModuleClasses()) { 
// ... 
 module = [moduleClass new]; 
 if ([module respondsToSelector:@selector(setBridge:)]) {
 module.bridge = self;
 modulesByName[moduleName] = module; 
 // ... 
}

Configuration Module

Once we have these modules, in a background thread, we list all the methods of each module, and then calling the method that starts with __rct__export__, we get a string of the method signature. This is important because we now know the actual type of the parameter. At runtime we only knew that one of the parameters was an id, but this way we can know that the id is actually an NSString *

unsigned int methodCount; 
Method *methods = class_copyMethodList(moduleClass, &methodCount);
for (unsigned int i = 0; i < methodCount; i++) {
 Method method = methods[i];
 SEL selector = method_getName(method);
 if ([NSStringFromSelector(selector) hasPrefix:@"__rct_export__"]) {
 IMP imp = method_getImplementation(method);
 NSArray *entries = ((NSArray *(*)(id, SEL))imp)(_moduleClass, selector);
 //...
 [moduleMethods addObject:/* Object representing the method */];
 }
}

Setting up the JavaScript executor

The JS executor has a -setUp method that allows it to do more complex work, such as initializing JS code in a background thread. This also saves some work because only the active executor will receive the setUp method call, not all executors:

JSGlobalContextRef ctx = JSGlobalContextCreate(NULL);
_context = [[RCTJavaScriptContext alloc] initWithJSContext:ctx];

Injecting JSON configuration

The JSON configuration contains only our module, for example:

This configuration information is stored as a global variable in the JavaScript virtual machine, so when the JS side bridge is initialized it can use this information to create modules

Loading JavaScript code

This is pretty straight forward and just requires loading the source code from whatever provider you specify, typically from the packager during development and from disk in production.

Executing JavaScript code

Once everything is ready, we can load the application source code in the JS virtual machine, copy the code, parse it and execute it. All CommonJS modules need to be registered during the first execution and the entry file is required.

JSValueRef jsError = NULL; 
JSStringRef execJSString = JSStringCreateWithCFString((__bridge CFStringRef)script); 
JSStringRef jsURL = JSStringCreateWithCFString((__bridge CFStringRef)sourceURL.absoluteString); 
JSValueRef result = JSEvaluateScript(strongSelf->_context.ctx, execJSString, NULL, jsURL, 0, &jsError); 
JSStringRelease(jsURL); 
JSStringRelease(execJSString);

Modules in JavaScript

On the JS side, we can now get the module consisting of the previous JSON configuration information through react-native's NativeModules:

The way it works is that when you call a method it is put into a queue, including the name of the module, the name of the method and all the parameters, and at the end of the JavsScript execution this queue will be given to the native module for execution.

Call cycle

Now if we call the module with the above code, it will look like this:

The call must start from native, and native calls JS (this picture only captures a certain moment when JS is running). During the execution process, because JS calls the method of NativeModules, it queues this call because this call must be executed on the native side. When JS is done executing, the native module iterates over all the calls that were enqueued, and then when it’s done executing them, it calls back through the bridge (a native module can call enqueueJSCall:args: through the _bridge instance) to call back into JS again.

(If you've been following the project, there used to be a call queue from native->JS as well which would dispatch on every vSYNC, but that was removed to improve startup time)

Parameter Type

Native to JS calls are easy, the parameters are passed as NSArray, which we encode as JSON data, but for JS to native calls, we need the native type, for this we check the basic types (ints, floats, chars...) but as mentioned above, for any object (structure), at runtime we don't get enough information from NSMthodSignature, so we save the type as a string.

We use regular expressions to extract the type from the method signature and use the RCTConvert class to actually convert the object. By default it provides methods for each type and tries to convert the JSON input to the required type.

Unless it is a struct, we use objc_msgSend to dynamically call the method, because there is no version of objc_msgSend_stret on arm64, so we use NSInvocation.

After converting all the parameters, we will use another NSInvocation to call the target module and method.

example:

// If you had the following method in a given module, e.g. `MyModule`
RCT_EXPORT_METHOD(methodWithArray:(NSArray *) size:(CGRect)size) {}
// And called it from JS, like: 
require('NativeModules').MyModule.method(['a', 1], {
 x: 0, 
 y: 0, 
 width: 200, 
 height: 100 
});
// The JS queue sent to native would then look like the following:
// ** Remember that it's a queue of calls, so all the fields are arrays ** 
@[ 
 @[ @0 ], // module IDs 
 @[ @1 ], // method IDs 
 @[ // arguments 
 @[ 
 @[@"a", @1], 
 @{ @"x": @0, @"y": @0, @"width": @200, @"height": @100 } 
 ] 
 ]
];
// This would convert into the following calls (pseudo code) 
NSInvocation call 
call[args][0] = GetModuleForId(@0) 
call[args][1] = GetMethodForId(@1) 
call[args][2] = obj_msgSend(RCTConvert, NSArray, @[@"a", @1]) 
call[args][3] = NSInvocation(RCTConvert, CGRect, @{ @"x": @0, ... })
call()

Threads

As mentioned above, each module has a single GCD queue by default, unless it specifies which queue to run on by implementing the -methodQueue method or merging the methodQueue property with a valid queue. The exception is ViewManagers* (which extend RCTViewManager) which will use Shadow Queue by default, and the special target RCTJSThread is just a placeholder since it is a thread and not a queue.

(In fact, View Managers are not really an exception, because the base class explicitly specifies the Shadow Queue as the target queue)

The current thread rules are as follows:

• -init and -setBridge: ensure execution in the main thread
• All exported methods are guaranteed to be executed in the target queue
• If you implement the RCTInvalidating protocol, you can also ensure that invalidate is called on the target queue.
• There is no guarantee on which thread -dealloc is called

When a batch of JS calls are received, these calls are grouped by target queue and called in parallel:

// group `calls` by `queue` in `buckets` 
for (id queue in buckets) { 
 dispatch_block_t block = ^{ 
 NSOrderedSet *calls = [buckets objectForKey:queue]; 
 for (NSNumber *indexObj in calls) { 
 // Actually call 
 } 
 }; 
 if (queue == RCTJSThread) { 
 [_javaScriptExecutor executeBlockOnJavaScriptQueue:block]; 
 } else if (queue) { 
 dispatch_async(queue, block); 
 } 
}

Conclusion

That’s it for a more in-depth overview of how React Native bridging works. I hope this helps people who want to build more complex modules or want to contribute to the core framework.

This is the end of this article about in-depth understanding of React Native core principles (React Native Bridge). For more content related to React Native principles, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!