Fabric sa React Native — ano ito, arkitektura ng rendering at paano ito gumagana

Ano ang Fabric?

Fabric — ay isang bagong sistema ng rendering para sa React Native na pumalit sa lumang renderer na gumagana sa pamamagitan ng Shadow Thread at Bridge. Sa lumang arkitektura, ang proseso ng rendering ay may tatlong hakbang: Kinakalkula ng JavaScript ang Virtual DOM, kinakalkula ng Shadow Thread (Yoga) ang layout, at ni-re-render ng Native Thread ang UIView. Pinagsasama ng Fabric ang lahat ng hakbang na ito sa iisang C++ pipeline na gumagana nang sabay-sabay.

Ang pag-unlad ng Fabric ay nagsimula noong 2019 bilang bahagi ng inisyatibong Lean Core at proyektong “Bagong Arkitektura”. Ang pangunahing layunin ay lutasin ang mga problema sa pagganap na may kaugnayan sa asynchronous na tatlong-phase na rendering. Sa lumang arkitektura, ang bawat pagbabago ng estado ay nangangailangan ng tatlong pagdaan sa iba't ibang mga thread, na nagdulot ng pagkaantala sa pagitan ng pagbabago ng data at rendering ng UI.

Ang Fabric ay batay sa konsepto ng hindi nababagong puno ng anino (Immutable Shadow Tree). Ang bawat node ng puno ay kumakatawan sa isang React component kasama ang mga props at estado nito. Kapag nagbago ang estado, isang bagong puno ang nilikha, at kinakalkula ng Fabric ang pagkakaiba sa pagitan ng luma at bagong puno at inilalapat lamang ang mga kinakailangang pagbabago sa native na UI. Pinapaliit nito ang bilang ng mga operasyon sa UIView/ViewGroup at pinaiikli ang oras ng rendering.

Paano Gumagana ang Shadow Tree

Shadow Tree — ay ang batayan ng paggana ng Fabric. Hindi tulad ng lumang arkitektura, kung saan ang Shadow Tree ay umiral lamang sa C++ side at nahiwalay sa JS tree sa pamamagitan ng asynchronous na Bridge, lumilikha ang Fabric ng isang ganap na naka-synchronize na hierarchical na representasyon ng UI. Ang mga node ng Shadow Tree ay nag-iimbak ng mga props, estado, at estilo ng mga component, at kinakalkula ng Yoga ang layout nang direkta sa antas ng C++.

Kapag in-update ng isang React component ang estado nito, nagpapadala ang React Native ng bagong Shadow Node sa Fabric. Hindi muling ni-re-render ng Fabric ang buong UI — gumagamit ito ng algorithm ng paghahambing (diffing) sa antas ng C++ upang matukoy kung aling mga node ang nagbago. Ang mga nabagong node lamang ang ipinapadala sa native rendering, na makabuluhang binabawasan ang dami ng trabaho.

Tatlong-phase na Rendering ng Fabric

Ang proseso ng rendering sa Fabric ay binubuo ng tatlong phase na isinasagawa nang sabay-sabay sa antas ng C++ nang walang paglipat ng thread. Unang phase — Render: Tinatawagan ng React ang render function ng component, na nagbabalik ng React Element Tree. Pangalawang phase — Commit: Lumilikha ang React Native ng bagong Shadow Tree at kinakalkula ang mga pagbabago batay sa lumang bersyon. Pangatlong phase — Mount: Inilalapat ng Fabric ang mga pagbabago sa native na UI, na lumilikha, nag-a-update, o nagtatanggal ng UIView.

• Render — isinasagawa sa JS thread, lumilikha ng React Element Tree.
• Commit — kinakalkula ng C++ Shadow Tree ang diff at bumubuo ng listahan ng mutasyon.
• Mount — inilalapat ang mga mutasyon sa native na UI sa pangunahing thread.

Lahat ng tatlong phase ay gumagana bilang isang pipeline, kung saan ang data ay ipinapadala sa pamamagitan ng JSI nang walang serialization. Ito ang pangunahing pagkakaiba mula sa lumang arkitektura, kung saan may mga pagkaantala sa pagitan ng mga phase: JS → (JSON) → Shadow Thread → (layout) → Native Thread.

Fabric vs Lumang Renderer: Paghahambing

Ang paghahambing ng Fabric sa lumang renderer ay nagpapakita kung gaano kalaki ang pagbabago ng arkitektura ng React Native. Ang lumang renderer ay gumagana nang asynchronous, hinahati ang proseso ng rendering sa tatlong independiyenteng thread. Pinagsasama ng Fabric ang lahat sa isang C++ pipeline.

Sa praktika, ang Fabric ay lalong kapaki-pakinabang para sa mga application na may madalas na pag-update ng UI: mga animation, pag-scroll na may lumulutang na mga header, real-time na data. Para sa mga static na pahina (teksto, mga button) ang pagkakaiba ay hindi gaanong kapansin-pansin. Ayon sa mga benchmark ng Meta, binabawasan ng Fabric ang oras ng rendering ng unang pag-load ng listahan ng 40–60%.

JSI at Fabric: Bagong Komunikasyon

JSI (JavaScript Interface) — ay ang pangunahing bahagi na nagpapagana sa Fabric. Sa pamamagitan ng JSI, nakakakuha ang Fabric ng direktang access sa mga halaga ng JavaScript nang walang serialization. Kapag nagpapadala ang React ng props sa Fabric, hindi sila kinokopya sa pamamagitan ng JSON — nagpapadala ang JSI ng mga pointer sa data sa memorya ng JS engine.

Ang arkitektura ng JSI ay nagpapahintulot sa Fabric na gumana sa anumang JavaScript engine — Hermes, JSC o V8. Ang C++ code ng Fabric ay hindi nakadepende sa partikular na implementasyon ng JS engine, na nagpapasimple sa pagpapanatili at pagsubok. Lahat ng operasyon sa UI — paglikha, pag-update, pagtanggal — ay isinasagawa sa pamamagitan ng JSI, na ginagarantiyahan ang minimal na pagkaantala.

// C++ rendering pipeline ng Fabric sa pamamagitan ng JSI
void mountShadowNode(
    jsi::Runtime& runtime,
    const ShadowNode::Shared& shadowNode,
    const ShadowNode::SharedList& children
) {
    auto props = shadowNode->getProps();
    auto state = shadowNode->getState();

    // Synchronous na paglipat ng props sa pamamagitan ng JSI
    jsiValue.asObject(runtime)
        .getProperty(runtime, "style")
        .asObject(runtime);

    // Pagkalkula ng layout nang direkta sa pamamagitan ng Yoga
    auto layoutMetrics =
        YogaLayoutableShadowNode::layout(children);

    // Ilapat ang mga mutasyon sa native na UI
    UIManager::synchronouslyUpdateViewOnUIThread(
        shadowNode->getTag(), layoutMetrics
    );
}

Ang pangunahing bentahe — synchronous na pag-update. Sa lumang arkitektura, ang UI ay ina-update sa pamamagitan ng asynchronous na pila: nagpapadala ang React ng utos sa pamamagitan ng Bridge, pinoproseso ng Shadow Thread ang layout, ni-re-render ng Native Thread. Sa Fabric, lahat ng hakbang ay isinasagawa nang sunud-sunod sa isang pagdaan. Tinatanggal nito ang mga race condition at ginagarantiyahan na ang UI ay tumutugma sa kasalukuyang estado ng application.

Paglipat sa Fabric

Ang paglipat sa Fabric ay hindi nangangailangan ng muling pagsulat ng mga React component — lahat ng umiiral na React Native component ay patuloy na gumagana. Gayunpaman, ang mga library na may native code (Native Module, custom ViewManager) ay maaaring mangailangan ng pag-update. Inirerekomenda ng Meta na suriin ang compatibility ng bawat library bago i-activate ang bagong arkitektura.

Upang i-activate ang Fabric sa isang React Native 0.76+ project, itakda ang flag na newArchEnabled: true sa react-native.config.js. Awtomatikong mag-a-activate ang Fabric kasama ng Turbo Module. Kung may problema, maaaring i-deactivate ang Fabric sa pamamagitan ng pagbabalik sa lumang renderer nang hindi binabago ang application code — parehong arkitektura ay sinusuportahan nang magkatulad.

// package.json — suriin ang mga library na compatible sa Fabric
"react-native": "0.76.6",
"react-native-safe-area-context": "^5.0.0",
"react-native-screens": "^4.0.0",
"react-native-reanimated": "^3.16.0",
"react-native-gesture-handler": "^2.21.0"

Sa paglipat, mahalagang i-update ang lahat ng native library sa mga bersyong compatible sa Fabric. Ang malalaking library tulad ng react-native-reanimated at react-native-gesture-handler ay sumusuporta na sa bagong arkitektura. Para sa mga library na hindi pa na-update, nagbibigay ang Fabric ng compatibility mechanism — kung hindi sinusuportahan ng library ang Fabric, awtomatikong lumilipat ang renderer sa luma para sa library na iyon.