Mobile Development 27 min read

Ctrip's CRN Framework Adaptation and Performance Optimization for HarmonyOS

This article details Ctrip's migration of its large‑scale React Native (RN) codebase to HarmonyOS using the custom CRN framework, covering technology selection, version upgrades, native component re‑implementation, component C‑ization, performance optimizations such as pre‑loading, TurboModule worker threads, instruction pruning, and future roadmap.

Ctrip Technology
Ctrip Technology
Ctrip Technology
Ctrip's CRN Framework Adaptation and Performance Optimization for HarmonyOS

Ctrip, as a key partner of the HarmonyOS ecosystem in the travel industry, began collaborating with Huawei during the service card phase and launched a beta HarmonyOS travel app in December 2023, later moving to full‑business adaptation after HarmonyOS Next entered internal testing in June 2024.

1. RN Usage in Ctrip Business – Since 2019 Ctrip has been using React Native (RN) and evolved it into the proprietary CRN framework, which by 2021 became the primary development framework for over 20 apps, supporting more than 2000 pages and handling 80% of business logic.

2. Technology Selection (Why CRN) – The chosen solution needed full functionality, high performance, and low migration cost. CRN offered mature infrastructure, low adaptation cost, rapid onboarding, and efficient product iteration on HarmonyOS.

3. CRN Adaptation Practice

3.1 Version Upgrade – Upgraded RN from 0.70.1 to 0.72.5 to match HarmonyOS RN, adding compatibility layers for deprecated components and APIs.

Key upgrade tasks included:

RN version diff analysis and compatibility handling.

CRN framework overhaul covering documentation, CLI upgrade tools, native runtime, JS bundling, third‑party libraries, Hermes engine, and custom components/APIs.

Release system adaptation to isolate HarmonyOS builds from iOS/Android.

Monitoring and debugging integration for HarmonyOS.

3.2 Differentiated Work – Implemented 100+ custom components and APIs on native HarmonyOS (ArkTS) and staged their migration based on priority, added react-native-harmony dependencies, adapted platform APIs, upgraded third‑party libraries, and handled compatibility issues.

3.3 Native Component Development – Re‑implemented over 100 custom components and TurboModules in ArkTS, addressing challenges such as large code ownership, complex UI components, and HarmonyOS security restrictions on media access.

3.4 Component C‑ization – Forced C‑API implementation for container‑node components (e.g., <RNComponent>…</RNComponent> ) and four specific components (SwipeoutView, ScrollView, CustomScrollView, CRNModal). The C‑ization process involved modifying the RNOH SDK, adding C‑API nodes, and handling lifecycle and attribute issues.

facebook::react::ShadowViewMutationList MountingManagerCAPI::getValidMutations(
  const facebook::react::ShadowViewMutationList &mutations) {
    // whitelist container component names
    std::unordered_set<std::string> whiteListArkTsComponentNames = {
        "AdapterMap", "AdapterMapMarkersContainer", "AdapterMapMarker"};
    // first pass: collect tags of created container components
    for (auto mutation : mutations) {
        if (mutation.type == facebook::react::ShadowViewMutation::Create) {
            if (whiteListArkTsComponentNames.count(newChild.componentName)) {
                arkTsComponentTags.push(newChild.tag);
            }
        }
    }
    // second and third passes filter mutations based on collected tags …
    return validMutations;
}

4. Issues and Solutions – Resolved RN new‑architecture bugs (iOS animation, sticky headers, zIndex), HarmonyOS‑specific problems (media picker security model, modal layering), and performance bottlenecks caused by TurboModule execution on the main thread.

5. Performance Optimizations

5.1 CRN Pre‑loading – Leveraged FrameNode for off‑screen rendering. Two versions were built:

Pre‑load 1.0: Render an empty RN surface with only the framework, then load business bundles after navigation, eliminating first‑frame white‑screen.

Pre‑load 2.0: Fully render the target RN page (framework, business code, network data) in the background, then swap it onto the screen instantly when the user navigates.

Both approaches use FrameNode’s off‑screen rendering capability while carefully isolating side effects.

5.2 TurboModule on Worker Thread – Moved TurboModule execution to a dedicated worker thread, adapting Sendable annotations and handling cross‑thread data transfer to avoid main‑thread blocking.

5.3 Instruction Pruning – Implemented a filtering algorithm in MountingManagerCAPI to keep only necessary commands for ArkTS components, reducing mutation count by >99% (e.g., hotel home page reduced from 3092 to 11 commands).

private myDisplaySync?: displaySync.DisplaySync
updateStage() {
  if (this.stages == 0) {
    this.myDisplaySync = displaySync.create();
    this.myDisplaySync.start();
    this.myDisplaySync.on('frame', (frameInfo) => {
      this.updateStage();
    });
  }
  this.stages++;
  if (this.stages == 3) {
    this.myDisplaySync?.stop();
  }
}

5.4 Frame‑by‑Frame Rendering – Controlled multi‑screen UI loading by rendering secondary grid after three frames, cutting startup time by ~20 ms.

5.5 Future Optimizations – Exploring JSVM (V8‑based) engine replacement and further performance tuning.

6. Results and Future Plans – After four months of development, Ctrip released the first full‑business HarmonyOS travel app in June 2024. The same CRN codebase now runs on Android, iOS, and HarmonyOS with minimal changes. Future work includes enhancing user experience, expanding the one‑code‑multiple‑platform strategy with xTaro, and continuous performance refinement.

Mobile DevelopmentPerformance OptimizationHarmonyOSReact NativeComponent CizationCRNTurboModule
Ctrip Technology
Written by

Ctrip Technology

Official Ctrip Technology account, sharing and discussing growth.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.