React Native Dynamic List Integration in Android RecyclerView

In 2022, fine‑grained operation has become a strong demand for major App manufacturers. Existing DSL‑based dynamic solutions have performance advantages but lack Turing completeness, making some logic‑driven requirements costly or impossible. To address this, the authors explored a React Native (RN) based approach that leverages an existing RN infrastructure to provide dynamic capabilities with acceptable performance.

The RN dynamic list solution embeds an RN container inside an Android RecyclerView ViewHolder . The main UI framework remains native, ensuring fast first‑screen load, while the RN part adds dynamic behavior. The authors rank several dynamic solutions in terms of overall performance, dynamic capability, and implementation capability, placing the RN dynamic list in a middle‑to‑upper position.

Overall performance: Pure Native > DSL‑based > RN dynamic list >= Pure RN page > H5

Dynamic capability: H5 = Pure RN page > RN dynamic list > DSL‑based > Pure Native

Implementation capability: Pure Native >= RN dynamic list = Pure RN page > H5 > DSL‑based

From an Android perspective, the solution includes the following technical details:

moduleName – unique key of an RN offline bundle.

componentName – the RN component registered via AppRegistry.registerComponent , serving as the entry point for a specific business feature.

Cards – UI elements displayed inside each ViewHolder on the cloud music home page.

RN engine – the JS runtime environment based on the RN bridge.

The overall architecture is data‑driven: the server sends data containing fields such as type , moduleName , and component . The client parses these fields to decide whether to render with native code or RN, and which RN component to launch.

Key implementation points:

Data‑driven rendering: the page only needs to forward data to RN without caring about its concrete presentation.

Pre‑loading of RN bundles: because loading an offline bundle can delay rendering, the entire bundle is pre‑loaded before the RecyclerView binds data.

One RN bundle can serve multiple cards, reducing resource consumption.

Data flow is split into three steps:

Server data definition and delivery – the server includes type , moduleName , and component in the JSON payload. Example structure: [ { "type":"rn", "rnInfo":{ "moduleName":"bizDiscovery", "component":"hotSong", "otherInfo":{} }, "data":{ "songInfo":{} } }, { "type":"dragonball", "data":{ "showInfo":{} } } ]

Container data pass‑through – the RN container is embedded in the ViewHolder . A ReactRootView is created and added to a native ViewGroup . Data is passed via initialProperties : mReactRootView?.startReactApplication(reactInstanceManager, componentName, initialProperties) Reuse of ReactRootView is handled to avoid re‑initializing JS when scrolling between different card types.

JS side implementation – card development follows normal RN practices, but multiple components are registered: AppRegistry.registerComponent('hotTopic', () => EStyleTheme(HotTopic)); AppRegistry.registerComponent('musicCalendar', () => EStyleTheme(MusicCalendar)); AppRegistry.registerComponent('newSong', () => EStyleTheme(NewSong));

Communication between JS and native layers uses a unique key generated from a timestamp hash to identify the originating card, ensuring correct routing of events such as "not interested" actions.

RN engine pre‑heating is performed by creating the ReactInstanceManager and invoking createReactContextInBackground() : ReactInstanceManager.builder() .setApplication(ApplicationWrapper.getInstance()) .setJSMainModulePath("index.android") .addPackage(MainReactPackage()) ... .build() .createReactContextInBackground() Memory consumption was measured with the Android Profiler. Results show that even with up to five RN containers, memory increase remains modest and does not cause OOM issues. Exception handling relies on NativeExceptionHandler to listen for soft and fatal exceptions. When an error occurs, a unified callback notifies the RecyclerView layer, which can rebuild the RN container if needed. The error rate in production is less than 0.01%. For RN version upgrades that may cause data incompatibility, the offline bundle includes a configuration file describing supported card information. The client can filter server responses based on this config to avoid mismatches. Future plans include integrating the RN dynamic list with low‑code capabilities for dynamic home‑page publishing, and upgrading the RN version (currently 0.60.5) to improve JS execution efficiency and multithreading performance.