深入理解React Native核心原理(React Native的橋接(Bridge)

在這篇文章之前我們假設你已經瞭解瞭React Native的基礎知識,我們會重點關註當native和JavaScript進行信息交流時的內部運行原理。

主線程

在開始之前,我們需要知道在React Native中有三個主要的線程:

  • shadow queue:負責佈局工作
  • main thread:UIKit 在這個線程工作(譯者註:UI Manager線程,可以看成主線程,主要負責頁面交互和控件繪制的邏輯)
  • JavaScript thread:運行JS代碼的線程

另外,一般情況下每個native模塊都有自己的GCD隊列,除非有特殊說明(後面會解釋)

*shadow queue其實更像一個GCD隊列而不是線程

Native模塊

如果你還不知道怎麼創建一個Native模塊,我推薦你去閱讀一下文檔

這是一個native模塊Person的例子,它既受JavaScript的調用,也可以調用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

我們重點關註RCT_EXPORT_MODULE和RCT_EXPORT_METHOD這兩個宏,它們擴展成什麼,它們的角色是什麼,它們是如何運行的。

RCT_EXPORT_MODULE([js_name])

正如這個方法的名字那樣,它export出你的module,但是在這個特定的上下文中export是什麼意思呢,它意味著橋接知道你的模塊。

它的定義實際上非常簡單:

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

它做瞭以下工作:

  • 首先聲明RCTRegisterModule為外部函數,意味著這個函數的實現對於編譯器不可見,但是在鏈接階段可用
  • 聲明一個方法moduleName,返回可選的宏參數js_name,這樣這個模塊在JS中具有和Objective-C中不一樣的類名
  • 聲明一個load方法(當app加載到內存中後,每個類的load方法都會被調用),load方法調用RCTRegisterModule,然後橋接才知道這個暴露出來的模塊

RCT_EXPORT_METHOD(method)

這個宏更有趣,它沒有在你的method中增加任何東西,除瞭聲明指定的方法外,它還創建瞭一個新方法。新方法如下所示:

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

它是通過將前綴(__rct_export__)和可選的js_name(本例子為空)和聲明的行號以及__COUNTER__宏構成。

這個方法的目的是返回一個包含可選js_name和method簽名的數組,這個js_name的作用是避免方法命名沖突。

Runtime

這整個設置僅僅是為瞭給橋接提供信息,讓它可以找到export出來的所有東西,modules和methods,但是這些都是在加載的時候發生的,現在我們來看看運行的時候是怎麼使用的。

這是橋接初始化時的依賴關系圖:

初始化模塊

RCTRegisterModule所做的事就是把類推進數組,這樣在實例化一個新的橋接的時候就能找到這個類。橋接遍歷數組中的所有模塊,為每個模塊創建一個實例,在橋接那邊存儲一個實例的引用,同時給這個模塊實例一個橋接的引用(所以我們能兩邊都互相調用),然後檢查這個模塊實例是否有指定要在哪個隊列運行,否則給它一個新隊列,與其他模塊分開:

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

配置模塊

一旦我們有瞭這些modules,在後臺線程中,我們列出每個module的所有methods,然後調用以__rct__export__開頭的methods,我們得到一個method簽名的字符串。這很重要因為我們現在知道瞭參數的實際類型,在運行的時候我們隻知道其中一個參數是id,但是通過這個途徑我們可以知道這個id實際上是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 */];
 }
}

設置JavaScript執行器

JS執行器有一個 -setUp 方法允許它做更復雜的工作,例如在後臺線程初始化JS代碼,這同時節約瞭一些工作,因為隻有活躍的執行器會接受 setUp 方法的調用,而不是所有的執行器:

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

註入JSON配置

JSON配置僅包含我們的module,例如:

這個配置信息作為全局變量存儲在JavaScript虛擬機,所以當JS那邊的橋接初始化後它可以用這個信息來創建modules

加載JavaScript代碼 

這非常直觀,隻需要從指定的任何提供程序中加載源代碼,通常在開發過程中從打包程序中加載源代碼,在生產環境中從磁盤加載。

執行JavaScript代碼

一旦所有事情準備就緒,我們可以在JS虛擬機中加載應用的源代碼,復制代碼,解析並執行它。在第一次執行時需要註冊所有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側我們現在可以通過react-native的NativeModules拿到前面的JSON配置信息構成的module:

它運行的方式是當你調用一個方法的時候它被放到一個隊列,包括module的名稱,method的名稱以及所有的參數,在JavsScript執行的最後這個隊列會給原生模塊執行。

調用周期

現在如果我們用上面的代碼調用module,它將會是這個樣子的:

調用必須從native開始,native調用JS(這張圖隻是截取瞭JS運行的某個時刻),在執行過程中,因為JS調用NativeModules的方法,它把這個調用入隊,因為這個調用必須在原生那邊執行。當JS執行完後,原生模塊遍歷入隊的所有調用,然後當它執行這些調用後,通過橋接進行回調(一個原生模塊可以通過_bridge實例來調用enqueueJSCall:args:),來再次回調JS。

(如果您一直在關註該項目,過去也有來自native-> JS的調用隊列,該調用隊列會在每個vSYNC上分派,但為瞭縮短啟動時間已將其刪除)

參數類型

native到JS的調用很容易,參數被NSArray傳遞,我們將其編碼為JSON數據,但是對於JS對native的調用,我們需要native的類型,為此我們檢查基本類型(ints,floats,chars…)但是就像上邊提及那樣,對於任何對象(結構),運行時我們不會從NSMthodSignature獲得足夠的信息,所以我們把類型保存為字符串。

我們使用正則表達式從method簽名中提取類型,並使用RCTConvert類來實際轉換對象,默認情況下它為每種類型都提供瞭方法,並且嘗試將JSON輸入轉換為所需要的類型。

除非是一個struct,否則我們使用objc_msgSend動態調用該方法,因為arm64上沒有objc_msgSend_stret的版本,因此我們使用NSInvocation。

轉換完所有參數後,我們將使用另一個NSInvocation來調用目標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默認都有一個GCD隊列,除非它通過實現-methodQueue方法或將methodQueue屬性與有效隊列合並來指定要在哪個隊列運行。ViewManagers*是例外(擴展瞭RCTViewManager),將默認使用Shadow Queue,而特殊目標RCTJSThread僅是一個占位符,因為它是線程而不是隊列。

(其實View Managers不是真正的例外,因為基類顯式的將Shadow Queue指定為目標隊列瞭)

當前線程規則如下:

  • -init和-setBridge:保證在主線程執行
  • 所有export的方法保證在目標隊列執行
  • 如果你實現瞭RCTInvalidating協議,則還可以確保在目標隊列上調用瞭invalidate
  • 無法保證在哪個線程調用-dealloc

當接收到JS的一批調用時,這些調用會按目標隊列進行分組,並行調用:

// 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); 
 } 
}

結尾

這就是React Native橋接工作原理的更深入概述。我希望者對想要構建更復雜modules或者想對核心框架有貢獻的人有所幫助。

到此這篇關於深入理解React Native核心原理(React Native的橋接(Bridge)的文章就介紹到這瞭,更多相關React Native原理內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!