Xima React Native: Current Status, Architecture, Performance Optimization, and Future Directions

Preface

Understanding RN: what it is and its characteristics.

Part 1: Xima RN Current Status

1.1 Business Scale

App integration : Main app and live app both integrate RN; several sub‑apps are pure RN.

Number of RN services : More than 70 RN services run in the main app, with 17 added in 2023; core scenarios such as half‑screen playback are covered.

PV coverage : PV reaches tens of millions, up 780% YoY; H1 2023 PV is 4.8× that of H5.

Supported types : Full‑screen, card, embedded tab, transparent, three‑platform co‑construction (examples listed in the original tables).

Business examples include 积分中心, 播放页, 助眠, 创作中心, 话题广场, etc. (images omitted for brevity).

Part 2: Overall Architecture

Architecture diagram (image in original source).

Part 3: Performance Optimization

3.1 Performance Indicators

Startup P90 : Defined as the time from RN bundle load start to the first non‑white‑pixel; iOS 400 ms, Android 900 ms.

Instant open rate : Ratio of launches ≤ 1000 ms; iOS 98 %, Android 92 %.

Open success rate : Status codes 0‑4 with two calculation methods; data shown in charts in the source.

Low‑end device compatibility: Android OS 8.0+, iOS 11+.

3.2 First‑screen Startup Speed Optimization

RN page loading process (image in source).

Optimization schemes

3.2.1 RN framework loading

RAM bundle : Explanation of RAM vs plain bundle; Indexed RAM bundle (iOS) and File RAM bundle (Android). RAM bundles load only the needed parts of a large bundle, reducing memory and startup time.

Using the Hermes engine eliminates the need for RAM bundles because Hermes ships bytecode that can be mmap‑ed on demand.

3.2.2 Bundle splitting and base bundle pre‑loading

Common libraries such as react, react‑native, react‑navigation are extracted into a base bundle that is shipped with the native app. Business bundles are built without the duplicated parts.

Base bundle loading timing diagram (image in source).

3.2.3 RN container cache and pre‑warm

After a business page is loaded, its RN container is cached. When the cache exceeds 3 instances on iOS or 5 on Android, the oldest instance is recycled. Approximately 70 % of scenarios reuse a cached container.

iOS and Android flowcharts (images in source) illustrate the caching mechanism.

Data comparison shows a ~43 % reduction in first‑screen time after optimization.

3.2.4 Hermes engine upgrade

Hermes is an open‑source JavaScript engine optimized for React Native. It uses AOT compilation to bytecode, which shortens startup time, reduces memory usage, and shrinks app size.

Since RN 0.70, Hermes is enabled by default. Performance gains of 23‑75 % have been observed.

3.3 Code loading strategies

Lazy loading using React.lazy and Suspense:

import { lazy } from 'react';

const CancellationTip = lazy(() => import("../components/CancellationTip"));
const Comp = () => (
}>
);

Module inspection script to list loaded and waiting modules:

const modules = require.getModules();
const moduleIds = Object.keys(modules);
const loadedModuleNames = moduleIds
  .filter(id => modules[id].isInitialized)
  .map(id => modules[id].verboseName);
const waitingModuleNames = moduleIds
  .filter(id => !modules[id].isInitialized)
  .map(id => modules[id].verboseName);

console.log('loaded:', loadedModuleNames.length, 'waiting:', waitingModuleNames.length);
console.log(`module.exports = ${JSON.stringify(loadedModuleNames.sort())};`);

Flipper launch performance tool helps locate modules with long load times (image in source).

Business code pre‑loading for the half‑screen playback page improves first‑screen speed (effect chart shown).

3.3.3 Business page rendering

Skeleton screen rendering is used: a lightweight placeholder is shown first, then the real UI is rendered after data arrives.

3.3 Component rendering optimization

List rendering options:

FlatList – easy to use but performance degrades with large lists.

recyclerlistview – pure‑JS library with better performance but higher learning curve.

flash‑list – native‑backed, high performance, API similar to FlatList.

Performance charts demonstrate that flash‑list achieves up to 7.5× higher JS FPS compared with FlatList.

Image optimization: memory usage of decoded images is much larger than file size. Android’s resizeMethod (resize, scale, auto) reduces memory consumption. Using FastImage/BetterImage with explicit width/height further cuts memory (example shows reduction from 1.9 MB to 0.65 MB per image).

3.4 Bundle size optimization

CDN‑hosted image resources to shrink the RN bundle.

Third‑party library replacement (lodash → individual modules, moment → dayjs, react‑native‑svg → @xmly/react-native-svg, etc.).

On‑demand loading via babel-plugin-import (example shown).

Timely removal of unused imports, especially for AB‑testing projects.

Part 4: Future Directions

RN new architecture (available from RN 0.72) includes:

JavaScript Interface (JSI) – replaces the Bridge, allowing direct C++ host object access.

Fabric – new rendering system that runs UI work on the main thread for lower latency.

Turbo Modules – lazy loading of native modules, reducing startup cost.

CodeGen – static type‑checking and code generation for JSI/Fabric interfaces.

Current architecture diagram and thread model (JS thread, Native/UI thread, Shadow thread) are shown in the source.

JSI enables synchronous communication between JS and native code, eliminating JSON serialization overhead.

Fabric allows UI updates to be performed synchronously on the main thread, improving interaction smoothness.

Turbo Modules defer native module initialization until actually used, shortening launch time.

CodeGen generates native bindings at build time, reducing runtime overhead.

Overall, the new architecture promises substantial performance improvements, shorter app startup, and smoother user experience.