Bridge sa React Native — ano ito, prinsipyo ng paggana at interaksyon

Ano ang Bridge sa React Native?

Bridge (Tulay) — ay isang pangunahing elemento ng arkitektura ng React Native na nagbibigay ng dalawang-daanan asynchronous na komunikasyon sa pagitan ng JavaScript thread, kung saan isinasagawa ang business logic ng aplikasyon, at ng mga native thread ng iOS at Android. Mula nang ilabas ang React Native noong 2015, ang Bridge ay nanatiling tanging paraan ng interaksyon ng JS code sa mga platform API — camera, geolokasyon, file system, notipikasyon, at iba pang native na kakayahan.

Ang arkitektura ng Bridge ay batay sa prinsipyo ng message queue. Kapag ang JavaScript code ay tumawag ng native method, ang kahilingan ay serialized sa isang JSON string, inilalagay sa queue, at asynchronous na ipinapadala sa native side. Pinoproseso ng native code ang kahilingan, isinasagawa ang kaukulang operasyon, at ibinabalik ang resulta sa pamamagitan ng parehong queue sa JS thread. Ayon sa ulat ng Meta sa React Conf 2021, hanggang 10,000 mensahe bawat segundo ang dumadaan sa Bridge sa isang karaniwang aplikasyon.

Ang mga pangunahing thread na kasangkot sa paggana ng Bridge: JavaScript Thread (pagpapatupad ng JS code), Native Thread (pagpapatupad ng native na operasyon), at Shadow Thread (pagkalkula ng layout gamit ang Yoga). Bawat thread ay gumagana nang independyente, na tinitiyak ang pagiging responsive ng interface — ang mga native na animation ay hindi nabablock ng JS computations.

Paano gumagana ang arkitektura ng Bridge

Ang Bridge ay gumagamit ng tatlong pangunahing mekanismo para sa komunikasyon: MessageQueue, JSON serialisasyon, at pagpapangkat ng mga mensahe. Ang MessageQueue ay isang panloob na bahagi ng React Native na namamahala sa queue ng mga tawag sa pagitan ng JS at native side. Bawat tawag ng native method ay inilalagay sa queue, sineserialisa, at ipinapadala sa mga batch para sa pag-optimize ng pagganap.

MessageQueue at serialisasyon

Ang MessageQueue ay gumagana sa prinsipyo ng pagpapangkat: ang mga tawag ng native method ay naipon at ipinapadala bilang isang grupo (batch) bawat 5–15 millisecond. Binabawasan nito ang overhead ng serialisasyon dahil maraming tawag ang nakabalot sa isang JSON package. Sa native side, ang mga mensahe ay deserialized at ipinamamahagi sa mga kaukulang module.

Pagrehistro ng mga module

Ang mga native module ay awtomatikong nirerehistro sa pamamagitan ng macros o annotations. Sa iOS, ginagamit ang macro na RCT_EXPORT_MODULE, sa Android — ang annotation na @ReactMethod. Sini-scan ng React Native ang mga nirehistrong module sa pagsisimula ng aplikasyon at gumagawa ng configuration JSON map ng lahat ng available na method. Ang map na ito ay ipinapadala sa JS environment, at nalalaman ng JavaScript kung anong mga method ang maaaring tawagin.

Daloy ng data

Ang data ay dumadaan sa sumusunod na landas: Tumatawag ang JavaScript ng NativeModules.CalendarModule.createCalendarEvent(). Ang method ay sineserialisa sa isang JSON message na may module identifier, method name, at arguments. Ang mensahe ay pumapasok sa MessageQueue. Sa native thread, ang mensahe ay deserialized at ipinapasa sa kaukulang module. Ang resulta ng pagpapatupad ay sineserialisa pabalik at ipinapadala sa JS thread bilang Promise o callback.

            // Pagtawag ng native module mula sa JavaScript sa pamamagitan ng Bridge
import { NativeModules } from 'react-native';

const CalendarModule = NativeModules.CalendarModule;

CalendarModule.createCalendarEvent('Test Event', 'Office')
  .then(eventId => {
    console.log('Ginawa ang kaganapan na may id:', eventId);
  })
  .catch(error => {
    console.error('Nabigo:', error);
  });

Sa native side ng iOS, ang module ay mukhang isang Objective-C class na may macro na RCT_EXPORT_MODULE. Ang method ay ini-export gamit ang macro na RCT_EXPORT_METHOD, at awtomatiko itong nirerehistro ng React Native sa Bridge. Ang mga argument ay ipinapasa ayon sa posisyon at dapat tumugma sa mga suportadong JSON type: NSString, NSNumber, NSArray, NSDictionary, BOOL.

            // Pagrehistro ng iOS Native Module sa Bridge
@interface CalendarModule () RCT_EXPORT_MODULE()
@end

@implementation CalendarModule

RCT_EXPORT_METHOD(createCalendarEvent:(NSString *)name
                  location:(NSString *)location
                  resolver:(RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject)
{
  NSNumber *eventId = createEvent(name, location);
  resolve(eventId);
}

@end

Mga limitasyon at problema ng Bridge

Ang Bridge ay may ilang pangunahing limitasyon sa pagganap. Ang pangunahin dito ay ang sapilitang asynchronisidad at serialisasyon. Bawat tawag ng native method ay ginagawang JSON string ang data, na nagdaragdag ng latency at kumukonsumo ng memorya. Para sa mga operasyon na may malaking volume ng data, tulad ng pagproseso ng imahe o pagtatrabaho sa video, ito ay nagiging bottleneck.

Mga gastos sa serialisasyon

Ang JSON serialisasyon at deserialisasyon ay gumagamit ng oras ng processor at memorya. Bawat mensahe ay dapat gawing string sa JS side, ipadala sa pamamagitan ng tulay, at i-parse sa native side. Ayon sa mga pagsubok ng Callstack (2022), ang serialisasyon ng array na may 10,000 numero sa pamamagitan ng Bridge ay tumatagal ng mga 30–50 millisecond, na hindi katanggap-tanggap para sa high-frequency na mga tawag.

Limitasyon sa laki ng mensahe

Ang Bridge ay hindi naka-optimize para sa pagpapadala ng malalaking binary data. Ang mga larawan, audio file, at video stream ay nangangailangan ng alternatibong approach — halimbawa, pagsulat ng file sa disk at pagpapadala ng path bilang string. Lumilikha ito ng karagdagang overhead para sa pagbasa at pagsulat ng file system.

• Asynchronisidad — hindi sinusuportahan ng Bridge ang synchronous na mga tawag, na nagpapahirap sa mga sitwasyong nangangailangan ng agarang tugon.
• Memorya — bawat mensahe ay iniimbak sa queue hanggang sa maproseso, na maaaring humantong sa pagtaas ng konsumo ng memorya.
• Debugging — mahirap ang pagsubaybay ng mga mensahe sa Bridge dahil napuputol ang chain ng tawag sa pagitan ng mga thread.

Ang pagkakaroon ng kamalayan sa mga limitasyong ito ay nagdulot sa Meta team na bumuo ng bagong arkitektura ng React Native, kung saan ang Bridge ay pinapalitan ng JSI (JavaScript Interface) at Turbo Module. Pinapayagan ng JSI ang direktang pagtawag ng native method nang walang serialisasyon, na tinatanggal ang pangunahing kakulangan ng Bridge.

Bridge vs Turbo Module: paghahambing

Ang paghahambing ng Bridge at Turbo Module ay nagpapakita ng mga pangunahing pagkakaiba sa mga arkitektural na approach. Gumagamit ang Bridge ng asynchronous na message queue na may JSON serialisasyon, habang ang Turbo Module ay gumagana sa pamamagitan ng JSI — isang direktang interface sa pagitan ng JavaScript at C++ na nagpapahintulot ng synchronous na pagtawag ng native method nang walang conversion ng data.

Ang pagpili sa pagitan ng Bridge at Turbo Module ay depende sa bersyon ng React Native. Para sa mga proyekto sa React Native 0.72 at mas luma, ang Bridge ay nananatiling pangunahing mekanismo. Simula sa React Native 0.73, ang Metro at bagong arkitektura ay sinusuportahan nang paralelo, na nagpapahintulot ng gradual na migrasyon. Ang buong paglipat sa Turbo Module ay nangangailangan ng pag-update sa React Native 0.76+ at pag-activate ng bagong arkitektura sa configuration.

Halimbawa ng pag-setup ng Native Module sa pamamagitan ng Bridge

Tingnan natin ang buong cycle ng paggawa at paggamit ng Native Module sa pamamagitan ng Bridge gamit ang halimbawa ng module para sa pagtatrabaho sa kalendaryo. Ang module ay gagawa ng kaganapan at magbabalik ng identifier nito. Ang halimbawang ito ay sumasaklaw sa setup para sa parehong platform — iOS at Android.

Android module

Sa Android, ang Native Module ay ginagawa bilang isang Java class na nagmana mula sa ReactContextBaseJavaModule. Ang annotation na @ReactMethod ay nag-eexport ng method sa Bridge. Para sa Promise, ginagamit ang Promise interface mula sa com.facebook.react.bridge.

public class CalendarModule extends ReactContextBaseJavaModule {

    @Override
    public String getName() {
        return "CalendarModule";
    }

    @ReactMethod
    public void createCalendarEvent(
            String name,
            String location,
            Promise promise) {
        try {
            Integer eventId = createCalendarEventNative(name, location);
            promise.resolve(eventId);
        } catch (Exception e) {
            promise.reject("EVENT_ERROR", e.getMessage());
        }
    }
}

Pagrehistro at paggamit

Ang module ay nirerehistro sa pamamagitan ng @ReactModule o mano-mano sa package ng aplikasyon. Awtomatiko itong nadedetect ng React Native at idinadagdag sa Bridge. Pagkatapos ng pagrehistro, ang module ay accessible mula sa JavaScript sa pamamagitan ng NativeModules.

public class CalendarPackage implements ReactPackage {

    @Override
    public List<NativeModule> createNativeModules(
            ReactApplicationContext reactContext) {
        return Arrays.asList(
            new CalendarModule(reactContext)
        );
    }

    @Override
    public List<ViewManager> createViewManagers(
            ReactApplicationContext reactContext) {
        return Collections.emptyList();
    }
}

Mahalagang tandaan na ang Bridge ay nangangailangan ng pag-restart ng aplikasyon kapag nagdadagdag ng mga bagong module, dahil ang configuration map ay binuo nang isang beses sa panahon ng inisyalisasyon. Ito ang nagpapahiwalay dito mula sa Turbo Module, na naglo-load nang tamad at sumusuporta sa hot-reload ng mga module nang walang restart.