在這篇文章之前我們假設(shè)你已經(jīng)了解了React Native的基礎(chǔ)知識，我們會重點(diǎn)關(guān)注當(dāng)native和JavaScript進(jìn)行信息交流時的內(nèi)部運(yùn)行原理。
主線程
在開始之前，我們需要知道在React Native中有三個主要的線程：
shadow queue：負(fù)責(zé)布局工作 main thread：UIKit 在這個線程工作（譯者注：UI Manager線程，可以看成主線程，主要負(fù)責(zé)頁面交互和控件繪制的邏輯） JavaScript thread：運(yùn)行JS代碼的線程
另外，一般情況下每個native模塊都有自己的GCD隊(duì)列，除非有特殊說明（后面會解釋）
*shadow queue其實(shí)更像一個GCD隊(duì)列而不是線程
Native模塊
如果你還不知道怎么創(chuàng)建一個Native模塊，我推薦你去閱讀一下文檔
這是一個native模塊Person的例子，它既受JavaScript的調(diào)用，也可以調(diào)用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
我們重點(diǎn)關(guān)注RCT_EXPORT_MODULE和RCT_EXPORT_METHOD這兩個宏，它們擴(kuò)展成什么，它們的角色是什么，它們是如何運(yùn)行的。
RCT_EXPORT_MODULE([js_name])
正如這個方法的名字那樣，它export出你的module，但是在這個特定的上下文中export是什么意思呢，它意味著橋接知道你的模塊。
它的定義實(shí)際上非常簡單：
#define RCT_EXPORT_MODULE(js_name)
RCT_EXTERN void RCTRegisterModule(Class);
+ (NSString *)moduleName { return @#js_name; }
+ (void)load { RCTRegisterModule(self); }
它做了以下工作：
首先聲明RCTRegisterModule為外部函數(shù)，意味著這個函數(shù)的實(shí)現(xiàn)對于編譯器不可見，但是在鏈接階段可用 聲明一個方法moduleName，返回可選的宏參數(shù)js_name，這樣這個模塊在JS中具有和Objective-C中不一樣的類名 聲明一個load方法（當(dāng)app加載到內(nèi)存中后，每個類的load方法都會被調(diào)用），load方法調(diào)用RCTRegisterModule，然后橋接才知道這個暴露出來的模塊
RCT_EXPORT_METHOD(method)
這個宏更有趣，它沒有在你的method中增加任何東西，除了聲明指定的方法外，它還創(chuàng)建了一個新方法。新方法如下所示：
+ (NSArray *)__rct_export__120
{
return @[ @"", @"log:(NSString *)message" ];
}
它是通過將前綴（__rct_export__）和可選的js_name（本例子為空）和聲明的行號以及__COUNTER__宏構(gòu)成。
這個方法的目的是返回一個包含可選js_name和method簽名的數(shù)組，這個js_name的作用是避免方法命名沖突。
Runtime
這整個設(shè)置僅僅是為了給橋接提供信息，讓它可以找到export出來的所有東西，modules和methods，但是這些都是在加載的時候發(fā)生的，現(xiàn)在我們來看看運(yùn)行的時候是怎么使用的。
這是橋接初始化時的依賴關(guān)系圖：
初始化模塊
RCTRegisterModule所做的事就是把類推進(jìn)數(shù)組，這樣在實(shí)例化一個新的橋接的時候就能找到這個類。橋接遍歷數(shù)組中的所有模塊，為每個模塊創(chuàng)建一個實(shí)例，在橋接那邊存儲一個實(shí)例的引用，同時給這個模塊實(shí)例一個橋接的引用（所以我們能兩邊都互相調(diào)用），然后檢查這個模塊實(shí)例是否有指定要在哪個隊(duì)列運(yùn)行，否則給它一個新隊(duì)列，與其他模塊分開：
NSMutableDictionary *modulesByName; // = ...
for (Class moduleClass in RCTGetModuleClasses()) {
// ...
module = [moduleClass new];
if ([module respondsToSelector:@selector(setBridge:)]){
module.bridge = self;
modulesByName[moduleName] = module;
// ...
}
配置模塊
一旦我們有了這些modules，在后臺線程中，我們列出每個module的所有methods，然后調(diào)用以__rct__export__開頭的methods，我們得到一個method簽名的字符串。這很重要因?yàn)槲覀儸F(xiàn)在知道了參數(shù)的實(shí)際類型，在運(yùn)行的時候我們只知道其中一個參數(shù)是id，但是通過這個途徑我們可以知道這個id實(shí)際上是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 */];
}
}
設(shè)置JavaScript執(zhí)行器
JS執(zhí)行器有一個 -setUp 方法允許它做更復(fù)雜的工作，例如在后臺線程初始化JS代碼，這同時節(jié)約了一些工作，因?yàn)橹挥谢钴S的執(zhí)行器會接受 setUp 方法的調(diào)用，而不是所有的執(zhí)行器：
JSGlobalContextRef ctx = JSGlobalContextCreate(NULL); _context = [[RCTJavaScriptContext alloc] initWithJSContext:ctx];
注入JSON配置
JSON配置僅包含我們的module，例如：
這個配置信息作為全局變量存儲在JavaScript虛擬機(jī)，所以當(dāng)JS那邊的橋接初始化后它可以用這個信息來創(chuàng)建modules
加載JavaScript代碼
這非常直觀，只需要從指定的任何提供程序中加載源代碼，通常在開發(fā)過程中從打包程序中加載源代碼，在生產(chǎn)環(huán)境中從磁盤加載。
執(zhí)行JavaScript代碼
一旦所有事情準(zhǔn)備就緒，我們可以在JS虛擬機(jī)中加載應(yīng)用的源代碼，復(fù)制代碼，解析并執(zhí)行它。在第一次執(zhí)行時需要注冊所有CommonJS模塊并且需要入口文件。
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);
JavaScript中的Modules
在JS側(cè)我們現(xiàn)在可以通過react-native的NativeModules拿到前面的JSON配置信息構(gòu)成的module：
它運(yùn)行的方式是當(dāng)你調(diào)用一個方法的時候它被放到一個隊(duì)列，包括module的名稱，method的名稱以及所有的參數(shù)，在JavsScript執(zhí)行的最后這個隊(duì)列會給原生模塊執(zhí)行。
調(diào)用周期
現(xiàn)在如果我們用上面的代碼調(diào)用module，它將會是這個樣子的：
調(diào)用必須從native開始，native調(diào)用JS（這張圖只是截取了JS運(yùn)行的某個時刻），在執(zhí)行過程中，因?yàn)镴S調(diào)用NativeModules的方法，它把這個調(diào)用入隊(duì)，因?yàn)檫@個調(diào)用必須在原生那邊執(zhí)行。當(dāng)JS執(zhí)行完后，原生模塊遍歷入隊(duì)的所有調(diào)用，然后當(dāng)它執(zhí)行這些調(diào)用后，通過橋接進(jìn)行回調(diào)（一個原生模塊可以通過_bridge實(shí)例來調(diào)用enqueueJSCall:args:），來再次回調(diào)JS。
（如果您一直在關(guān)注該項(xiàng)目，過去也有來自native-> JS的調(diào)用隊(duì)列，該調(diào)用隊(duì)列會在每個vSYNC上分派，但為了縮短啟動時間已將其刪除）
參數(shù)類型
native到JS的調(diào)用很容易，參數(shù)被NSArray傳遞，我們將其編碼為JSON數(shù)據(jù)，但是對于JS對native的調(diào)用，我們需要native的類型，為此我們檢查基本類型（ints，floats，chars...）但是就像上邊提及那樣，對于任何對象（結(jié)構(gòu)），運(yùn)行時我們不會從NSMthodSignature獲得足夠的信息，所以我們把類型保存為字符串。
我們使用正則表達(dá)式從method簽名中提取類型，并使用RCTConvert類來實(shí)際轉(zhuǎn)換對象，默認(rèn)情況下它為每種類型都提供了方法，并且嘗試將JSON輸入轉(zhuǎn)換為所需要的類型。
除非是一個struct，否則我們使用objc_msgSend動態(tài)調(diào)用該方法，因?yàn)閍rm64上沒有objc_msgSend_stret的版本，因此我們使用NSInvocation。
轉(zhuǎn)換完所有參數(shù)后，我們將使用另一個NSInvocation來調(diào)用目標(biāo)module和method。
例子：
// 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()
線程
正如以上提及那樣，每個module默認(rèn)都有一個GCD隊(duì)列，除非它通過實(shí)現(xiàn)-methodQueue方法或?qū)ethodQueue屬性與有效隊(duì)列合并來指定要在哪個隊(duì)列運(yùn)行。ViewManagers*是例外（擴(kuò)展了RCTViewManager），將默認(rèn)使用Shadow Queue，而特殊目標(biāo)RCTJSThread僅是一個占位符，因?yàn)樗蔷€程而不是隊(duì)列。
（其實(shí)View Managers不是真正的例外，因?yàn)榛愶@式的將Shadow Queue指定為目標(biāo)隊(duì)列了）
當(dāng)前線程規(guī)則如下：
-init和-setBridge：保證在主線程執(zhí)行 所有export的方法保證在目標(biāo)隊(duì)列執(zhí)行 如果你實(shí)現(xiàn)了RCTInvalidating協(xié)議，則還可以確保在目標(biāo)隊(duì)列上調(diào)用了invalidate 無法保證在哪個線程調(diào)用-dealloc
當(dāng)接收到JS的一批調(diào)用時，這些調(diào)用會按目標(biāo)隊(duì)列進(jìn)行分組，并行調(diào)用：
// 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);
}
}
結(jié)尾
這就是React Native橋接工作原理的更深入概述。我希望者對想要構(gòu)建更復(fù)雜modules或者想對核心框架有貢獻(xiàn)的人有所幫助。
到此這篇關(guān)于深入理解React Native核心原理(React Native的橋接（Bridge)的文章就介紹到這了,更多相關(guān)React Native原理內(nèi)容請搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！
原文鏈接：https://blog.csdn.net/qq_41056833/article/details/115441357
