React Native

01Ինչպես է աշխատում React Native-ը

Ձեր հավելվածն ունի երկու աշխարհ։ JavaScript աշխարհը Hermes-ի ներսում աշխատեցնում է ձեր React կոմպոնենտները, state-ը և բիզնես տրամաբանությունը․ Hermes-ը մոբայլի համար կառուցված JavaScript շարժիչ է, որը build-ի ժամանակ ձեր կոդը compile է անում bytecode-ի, որպեսզի հավելվածներն ավելի արագ մեկնարկեն և ավելի քիչ հիշողություն օգտագործեն։ Native աշխարհին են պատկանում իրական UIView և Android View օբյեկտները, տեսախցիկը, keychain-ը և այլն։ React-ը նկարագրում է, թե ինչպիսին պետք է լինի էկրանը, իսկ React Native-ը այդ նկարագրությունը վերածում է native view-երի։ <View>-ն iOS-ում դառնում է UIView, Android-ում՝ ViewGroup, <Text>-ը դառնում է native տեքստ։ WebView չկա․ scroll-ը, ժեստերը և տեքստի մուտքագրումը native են, ահա թե ինչու RN հավելվածները զգացվում են որպես իրական հավելվածներ։ Layout-ն օգտագործում է Yoga՝ Flexbox իրականացնող շարժիչ, այնպես որ նույն style-ն աշխատում է երկու պլատֆորմներում էլ։

02New Architecture՝ JSI, Fabric, TurboModules

Հին ճարտարապետությունը JavaScript-ի և native-ի միջև յուրաքանչյուր հաղորդագրություն ուղարկում էր serialize արված JSON-ով ասինխրոն «bridge»-ի միջոցով՝ queue, որը խցան էր դառնում անիմացիաների և մեծ ցուցակների համար։ New Architecture-ը, որը default է 0.76-ից և միակ տարբերակը՝ 0.82-ից, փոխարինում է այն։ JSI-ը (JavaScript Interface) թույլ է տալիս JavaScript-ին պահել C++ օբյեկտների ուղղակի հղումներ և կանչել դրանք սինխրոն՝ առանց serialize անելու։ Fabric-ը նոր renderer-ն է․ այն UI ծառը կառուցում է C++-ում, աջակցում է React 18+ concurrent հնարավորություններին և կարող է սինխրոն չափել ու թարմացնել layout-ը։ TurboModules-ը native մոդուլներ են, որոնք lazy կերպով բեռնվում են առաջին օգտագործման ժամանակ և տիպավորվում են Codegen-ի միջոցով, որը ձեր TypeScript spec-ից գեներացնում է C++ glue-ն, այնպես որ սխալները երևում են build-ի ժամանակ։ Գործնական ազդեցություն՝ ավելի հարթ ժեստեր և անիմացիաներ (Reanimated 4-ին դա պետք է), ավելի արագ մեկնարկ, և գրադարանները պետք է համատեղելի լինեն New Architecture-ի հետ, ստուգեք նախքան տեղադրելը։

• JSI՝ ուղղակի, սինխրոն JS ↔ C++ կանչեր, առանց JSON bridge-ի
• Fabric՝ C++ renderer, concurrent React, սինխրոն layout
• TurboModules + Codegen՝ lazy, type-safe native մոդուլներ
• Hermes՝ bytecode-ի compile արվող շարժիչ, default երկու պլատֆորմներում էլ

03Bare React Native, թե՞ Expo

React Native թիմն այժմ խորհուրդ է տալիս սկսել framework-ով, և Expo-ն գլխավորն է։ Expo-ն տալիս է սպասարկվող native մոդուլների մեծ հավաքածու, ֆայլերի վրա հիմնված routing (Expo Router), config plugin-ներ, որոնք ձեր փոխարեն խմբագրում են native նախագծերը, development build-եր և EAS՝ cloud build-երի, submission-ի և OTA թարմացումների համար։ «Bare»-ը նշանակում է, որ ios/ և android/ թղթապանակներն ուղղակիորեն ձերն են (սկսված React Native Community CLI-ով)։ Bare-ը տալիս է լիարժեք վերահսկողություն և հարմար է native փորձ ունեցող կամ ծանր custom native SDK-ներով թիմերի համար։ Սահմանը մշուշոտվել է․ Expo հավելվածները կարող են ներառել ցանկացած native կոդ config plugin-ների կամ prebuild-ի միջոցով, իսկ bare հավելվածները կարող են օգտագործել Expo մոդուլներ։ Իմ կանոնը՝ ստանդարտ կարիքներով նոր պրոդուկտի համար սկսեք Expo-ով․ այն հավելվածի համար, որը պետք է ինտեգրի անսովոր native SDK-ներ կամ հետևում է գոյություն ունեցող native template-ի, bare-ը նորմալ է, պարզապես պարբերաբար upgrade արեք։

1# Expo (recommended start)
2npx create-expo-app@latest my-app --template default
3cd my-app && npx expo start
4 
5# Bare React Native (Community CLI)
6npx @react-native-community/cli@latest init MyApp
7cd MyApp && npx react-native run-ios

04Իրական հավելվածի կառուցում զրոյից՝ կառուցվածք, env, API, state

Կառուցվածքը դասավորեք ըստ feature-ի, ոչ թե ըստ ֆայլի տեսակի, որպեսզի էկրանը, դրա hook-երը և կոմպոնենտներն ապրեն միասին։ Երեք layer պահեք առանձին։ API layer-ը մեկ HTTP client է՝ base URL-ով, auth header-ով, token refresh-ով և timeout-ներով․ adapter-ները backend-ի պատասխանները վերածում են հավելվածի տիպերի, այնպես որ backend-ում վերանվանված դաշտը փոխում է մեկ ֆայլ, ոչ թե քսան էկրան։ Store-երը (Zustand-ը թեթև է և լավ է աշխատում) պահում են հավելվածի state-ը, օրինակ՝ session, զամբյուղ և կարգավորումներ․ էկրանները կարդում են store-երը և կանչում action-ներ, երբեք ուղղակիորեն fetch չեն անում։ Սերվերային տվյալների համար TanStack Query-ն ավելացնում է caching, retry-ներ և refetch՝ focus-ի ժամանակ։ Միջավայր՝ API URL-ը և key-երը պահեք ըստ build-ի (dev, staging, prod)՝ build-time config-ի միջոցով, երբեք hard-code մի արեք և երբեք իրական գաղտնիքներ մի դրեք հավելվածում․ bundle-ում եղած ամեն ինչ կարելի է դուրս հանել։ Ավտոմատ retry արեք միայն idempotent հարցումները (GET, PUT՝ key-երով)․ կրկնված POST-ը կարող է կրկնօրինակ պատվեր ստեղծել։

1src/
2  app/          # navigation, providers, deep links
3  features/
4    auth/       # screens, hooks, components for sign-in
5    cart/
6    orders/
7  shared/
8    api/        # http client, adapters, endpoints
9    stores/     # zustand stores (session, cart, settings)
10    ui/         # Button, Text, Card — built on tokens
11    theme/      # colors, spacing, typography tokens
12    i18n/       # en / hy / ru dictionaries
13  native/       # bridges to custom native modules

05Navigation, auth flow և push

React Navigation-ը (stack, tab-եր, drawer-ներ native էկրանների վրա) և Expo Router-ը (ֆայլերի վրա հիմնված, կառուցված React Navigation-ի վրա) ստանդարտ ընտրություններն են։ Auth-ը մոդելավորեք որպես navigation state․ root navigator-ը ցույց է տալիս auth stack-ը կամ հիմնական tab-երը՝ կախված նրանից, թե session կա արդյոք, այնպես որ դուրս եկած օգտատերը չի կարող deep link-ով հասնել private էկրանների։ Token-ները պահեք Keychain/Keystore-ում (react-native-keychain կամ expo-secure-store), երբեք AsyncStorage-ում։ Թույլ տվեք հյուրերին թերթել և սահմանափակեք միայն այն գործողությունները, որոնց հաշիվ է պետք, sign-in-ից հետո վերադարձնելով նրանց նույն տեղը։ Deep link-երը և Universal/App Links-ը կարգավորեք վաղ․ push ծանուցումները, email-ները և QR կոդերը բոլորը կախված են դրանցից։ Push-ի համար սարքի token-ը գրանցեք sign-in-ից հետո և ուղարկեք ձեր backend-ին, թույլտվություն խնդրեք իմաստալից պահին, ոչ թե առաջին գործարկման ժամանակ, և ծանուցումների tap-երը մշակեք՝ navigate անելով նույն deep-link route-երով։

1const Stack = createNativeStackNavigator<RootParams>();
2 
3export function RootNavigator() {
4  const session = useSession((s) => s.session);
5  return (
6    <Stack.Navigator screenOptions={{ headerShown: false }}>
7      {session ? (
8        <Stack.Screen name="Main" component={MainTabs} />
9      ) : (
10        <Stack.Screen name="Auth" component={AuthStack} />
11      )}
12      <Stack.Screen name="ForceUpdate" component={ForceUpdateScreen} />
13    </Stack.Navigator>
14  );
15}

06Styling, design token-ներ և ցուցակների արագագործություն

CSS cascade չկա․ յուրաքանչյուր կոմպոնենտ ստանում է style օբյեկտ, և StyleSheet.create-ը դրանք ստատիկ է պահում։ Կառուցեք token-ների փոքր theme՝ գույներ (light և dark), spacing սանդղակ, radius-ներ, տիպոգրաֆիա, և մի քանի բազային կոմպոնենտ (Text, Button, Card, Screen), որոնք օգտագործում են միայն token-ներ։ Այդ դեպքում էկրանները երբեք չեն պարունակում raw hex արժեքներ կամ «կախարդական» թվեր, իսկ dark mode-ը կամ rebrand-ը մեկ ֆայլ է։ Հարգեք safe area-ները (react-native-safe-area-context), Dynamic Type/font scaling-ը և Android-ի edge-to-edge layout-ները։ Երկար ցուցակները երբեք մի render արեք map-ով ScrollView-ի ներսում․ օգտագործեք FlatList կամ, ավելի լավ, FlashList, որը վերաօգտագործում է cell-երը։ Տարրերին տվեք կայուն key-եր, memoize արեք row կոմպոնենտները, renderItem-ում խուսափեք inline ծանր աշխատանքից և նկարները ճիշտ չափսավորեք (expo-image կամ cache անող image գրադարան)։ Անիմացիաներն արեք Reanimated-ով, որը անիմացիաներն աշխատեցնում է UI thread-ի վրա, այնպես որ դրանք մնում են հարթ նույնիսկ այն ժամանակ, երբ JavaScript-ը զբաղված է։

1export const theme = {
2  color: { bg: "#FFFFFF", text: "#111111", primary: "#0A6CFF", muted: "#6B7280" },
3  space: { xs: 4, sm: 8, md: 16, lg: 24, xl: 32 },
4  radius: { sm: 6, md: 12, pill: 999 },
5  font: { body: 16, title: 22, caption: 13 },
6} as const;
7 
8<FlashList
9  data={products}
10  keyExtractor={(p) => p.id}
11  renderItem={({ item }) => <ProductRow product={item} />}
12/>

07Native մոդուլներ, պլատֆորմների տարբերություններ և debugging

Երբ գրադարան գոյություն չունի՝ տարածաշրջանային վճարային SDK, տպիչ, custom սկաներ, գրեք TurboModule՝ TypeScript spec, Codegen, ապա Kotlin/Swift իրականացումներ (Expo Modules API-ն ավելի բարեհամբույր այլընտրանք է)։ Մակերեսը պահեք փոքր և promise-ի վրա հիմնված։ Սպասեք պլատֆորմների տարբերությունների՝ թույլտվությունների flow-եր, back կոճակ Android-ում, ստեղնաշարի վարքագիծ, ստվերներ (iOS-ի shadow props ընդդեմ Android-ի elevation-ի), ամսաթվի picker-ներ, տառատեսակներ և iOS-ում ավելի խիստ background սահմանափակումներ։ Platform.select կամ ֆայլերի suffix-ներ (Button.ios.tsx) օգտագործեք միայն այնտեղ, որտեղ վարքագիծն իսկապես տարբերվում է։ Debugging՝ React Native DevTools-ը (Metro-ում սեղմեք j) տալիս է Chrome-ի ոճի debugger, console, React կոմպոնենտներ և profiler Hermes-ի համար։ Native crash-երի համար օգտագործեք Xcode-ի և Android Studio-ի log-երը (Logcat), production-ի համար՝ Crashlytics կամ Sentry, իսկ performance monitor-ը՝ JS-ի և UI-ի frame rate-ին հետևելու համար։ Թեստավորեք իրական թույլ Android հեռախոսի վրա․ simulator-ը ստում է արագագործության մասին։

08Thread-երը և render pipeline-ը

React Native հավելվածն աշխատում է մի քանի thread-ի վրա։ JavaScript thread-ը Hermes-ում աշխատեցնում է React-ը, ձեր state-ի թարմացումները և բիզնես տրամաբանությունը։ Main (UI) thread-ին են պատկանում native view-երը, հպումները և պլատֆորմի frame loop-ը։ Fabric-ը render է անում երեք փուլով։ Render․ React-ը ստեղծում է element-ներ, իսկ Fabric-ը կառուցում է C++ node-երից բաղկացած shadow tree։ Commit․ Yoga-ն հաշվարկում է այդ tree-ի layout-ը, հաճախ՝ background thread-ում, և նոր tree-ն առաջ է քաշվում որպես հաջորդը ցուցադրվելու համար։ Mount․ տարբերությունները կիրառվում են իրական native view-երի վրա UI thread-ում։ 60 Hz-ի դեպքում յուրաքանչյուր frame ունի մոտ 16.7 ms, 120 Hz-ի դեպքում՝ մոտ 8 ms։ Եթե JavaScript thread-ը զբաղված է մեծ JSON response parse անելով կամ մեծ tree վերա-render անելով, հպումները դեռ հասնում են, բայց React-ը չի կարող արձագանքել, և հավելվածը թվում է սառած։ Դրա համար են Reanimated-ի worklet-ները անիմացիաները աշխատեցնում UI thread-ում, և դրա համար startTransition-ը կարող է ոչ հրատապ թարմացումները նշել որպես ընդհատելի։

09TurboModule-ի գրում Codegen-ով

TurboModule-ը սկսվում է որպես տիպավորված JavaScript spec։ Ֆայլի անունը պետք է սկսվի Native-ով, իսկ package.json-ը հայտարարում է codegenConfig, որը Codegen-ին ասում է, թե որտեղ են spec-երը։ Build-ի ժամանակ Codegen-ը կարդում է spec-ը և գեներացնում C++ և պլատֆորմային interface-ներ․ ձեր Kotlin և Objective-C++ կամ Swift class-երը իրականացնում են դրանք, և compiler-ը բողոքում է, եթե method-ի signature-ը չի համընկնում։ Մակերեսը պահեք փոքր՝ պարզ տվյալների տիպեր, promise-ներ ամեն դանդաղ բանի համար և event-ներ թարմացումների հոսքերի համար, օրինակ՝ վճարման կարգավիճակը։ Երբեք մի արգելափակեք JavaScript thread-ը սինխրոն native կանչերով, որոնք դիպչում են network-ին կամ disk-ին․ սինխրոն method-ները միայն էժան ընթերցումների համար են։ Եթե թիմը native-ով ուժեղ չէ, Expo Modules API-ն առաջարկում է ավելի պարզ Swift և Kotlin DSL, որն աշխատում է նաև bare հավելվածներում։

1// specs/NativePayments.ts
2import type { TurboModule } from "react-native";
3import { TurboModuleRegistry } from "react-native";
4 
5export interface Spec extends TurboModule {
6  isAvailable(): boolean; // cheap, synchronous
7  startPayment(amountMinor: number, currency: string): Promise<string>;
8}
9 
10export default TurboModuleRegistry.getEnforcing<Spec>("NativePayments");
11 
12// package.json
13// "codegenConfig": { "name": "PaymentsSpec", "type": "modules",
14//   "jsSrcsDir": "specs", "android": { "javaPackageName": "com.example.payments" } }

10Startup time և bundle-ի չափ

Cold start-ը առաջին տպավորությունն է, և դրա մեծ մասը ձեր վերահսկողության տակ է։ Hermes-ն արդեն մատուցում է նախապես compile արված bytecode, ուստի մնացած ծախսը հիմնականում այն է, ինչ անում է ձեր կոդը module load-ի ժամանակ՝ բոլոր էկրանների և ծանր գրադարանների import-ը սկզբից, storage-ից մեծ տվյալների սինխրոն ընթերցումը կամ շատ SDK-ների initialization-ը մինչև առաջին frame-ը։ Էկրանները բեռնեք lazy, analytics-ը և ոչ կրիտիկական SDK-ները հետաձգեք առաջին render-ից հետո, իսկ splash screen-ը պահեք միայն մինչև առաջին իմաստալից տվյալների պատրաստ լինելը։ Չափեք release build-ով միջին կարգի Android սարքի վրա, երբեք development mode-ում, որը շատ անգամ ավելի դանդաղ է։ Android-ում release-ի համար միացրեք R8 minification-ը և պահեք նրա mapping ֆայլերը Crashlytics-ի համար։ Հետևեք JavaScript bundle-ի չափին ժամանակի ընթացքում․ մեկ ամսաթվի կամ chart-ի գրադարանը կարող է ավելացնել հարյուրավոր կիլոբայթներ, որոնք յուրաքանչյուր օգտատեր ներբեռնում և parse է անում։

11Անվտանգություն և offline կայունություն

Ենթադրեք, որ bundle-ը կկարդացվի․ ցանկացած մեկը կարող է բացել APK կամ IPA և ուսումնասիրել Hermes bytecode-ը և asset-ները։ Secret-ները մնում են սերվերում․ հավելվածը պահում է միայն օգտատիրոջ token-ները Keychain-ում կամ Keystore-ում։ API-ի չարաշահումը դժվարացնելու համար ավելացրեք device attestation (Play Integrity Android-ում, App Attest iOS-ում) և ստուգեք այն սերվերում։ Certificate pinning-ը արգելափակում է որոշ interception հարձակումներ, բայց կարող է բոլոր օգտատերերին դուրս թողնել, եթե certificate-ը անսպասելի rotate լինի, ուստի pin արեք public key-երին՝ backup key-ով և հեռավար kill-switch-ով։ Offline վարքագիծը պահանջում է բացահայտ դիզայն․ հայտնաբերեք կապը, ցույց տվեք cache-ված տվյալները հստակ offline banner-ով, օգտատիրոջ գործողությունները լոկալ դրեք հերթի մեջ և replay արեք idempotency key-երով, որպեսզի կրկնված պատվերը երբեք չկրկնապատկվի։ Sign-out-ի ժամանակ մաքրեք անձնական տվյալներ պարունակող cache-երը, իսկ զգայուն էկրանները բացառեք screenshot-ներից և app switcher-ից, եթե ոլորտը դա պահանջում է։