Client service development and loading method and system based on ReactNative framework
By using a graphical development interface to generate script files within the React Native framework and supporting mixed calls between native modules and RN components, the problem of coupling between business logic and client code is solved. This enables rapid and lightweight business development and loading, improves development efficiency and user experience, and ensures stable operation and resource management for multiple business instances.
Patent Information
- Application Number
- CN202511958533.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-01-23
AI Technical Summary
Existing technologies, when developing mobile applications based on the React Native framework, result in strong coupling between business logic and client-side code, long iteration cycles, low performance of dynamic solutions, poor user experience, and complex dependencies between business modules, making it difficult to achieve free combination and orchestration across business lines.
It adopts a client-side business development approach based on the React Native framework, generates script files through a graphical development interface, uses the BDL language to support mixed calls of native modules and RN components, realizes dynamic parsing and execution, supports the parallel operation of multiple business instances and adopts isolation and scheduling mechanisms to ensure stability and performance.
It enables lightweight, high-performance business development and operation, supports rapid loading of new business functions without the need to release new versions, improves development efficiency and user experience, and ensures stable operation and resource management of multiple business instances.
Smart Images

Figure CN121387398A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of mobile application development, and in particular to a client business development and loading method and system based on a ReactNative framework. BACKGROUND
[0002] ReactNative framework: ReactNative is an open-source framework developed by Facebook (now Meta) for building cross-platform mobile applications. It allows developers to use JavaScript and React to develop iOS and Android applications, and ultimately generates mobile applications with near-native performance. In this document, it is referred to as RN.
[0003] Currently, when developing mobile applications (APP) based on the ReactNative framework, the following development methods are commonly used: Hard-coded business logic: business logic is directly coded in the client. The disadvantage of this method is that the business logic is strongly coupled with the client code, and the business logic needs to be updated by publishing a new version, which has a long iteration cycle.
[0004] II. Dynamic scheme based on H5 or WebView: dynamic update is achieved through Web technology. The disadvantage of this method is that the dynamic scheme has low performance and poor user experience. III. Native plug-in + RN hybrid development: although it can reuse native capabilities, the dependence between business modules is complex, making it difficult to achieve free combination and arrangement across businesses, and there is a lack of unified business description language and runtime environment, which cannot achieve dynamic analysis and execution. SUMMARY
[0005] The present application aims to at least solve one of the technical problems in the related art. To this end, one object of the present application is to provide a client business development and loading method and system based on a ReactNative framework, which overcomes the technical problems of inconvenience and slowness in developing and loading new businesses on the client APP in the prior art, and enables rapid and convenient development and loading of new businesses on the client APP.
[0006] The technical solution adopted by the present application is: In a first aspect, the present application provides a client business development and loading method based on a ReactNative framework, which is executed by a client APP, comprising: obtaining a script file corresponding to a business running on the client APP from a server device, the client APP being developed based on a ReactNative framework; and executing business logic based on the script file.
[0007] The content of the script file includes a UI, a data flow, and an event response, the script file is developed in a BDL language, the BDL language supports mixed calling of a native module and an RN component, and a development environment of the script file is a graphical development interface.
[0008] The business logic is executed based on the script file, including: loading and parsing the script file, generating a virtual DOM and a business logic instruction; loading the virtual DOM to complete UI rendering; executing the business logic instruction to determine whether a native module needs to be called, if yes, the native module is called, and if no, the next step is executed, wherein the native module is an API function encapsulating a native function; and listening to an event in the script file and executing the event.
[0009] The number of the businesses is multiple, when multiple businesses run in parallel, each business corresponds to a script file, and an isolation and scheduling mechanism is used to ensure stable running of the multiple businesses.
[0010] In the second aspect, the application provides a client business development and loading method based on a ReactNative framework, executed by a PC front-end device, including: automatically generating a script file in response to operations of dragging a graphical component, configuring component attributes, and defining an event flow; and uploading the script file to a server device.
[0011] In the third aspect, the application provides a client business development and loading method based on a ReactNative framework, executed by a server device, including: receiving a script file from a PC front-end device and saving the script file.
[0012] In the fourth aspect, the application provides a client APP, including: a script file acquisition module, configured to acquire a script file corresponding to a business running on the client APP from a server device; and a business logic execution module, configured to execute business logic based on the script file.
[0013] In the fifth aspect, the application provides a PC front-end device, including: a script file generation module, configured to automatically generate a script file in response to operations of dragging a graphical component, configuring component attributes, and defining an event flow; and a script file sending module, configured to send the script file to a server device.
[0014] In the sixth aspect, the application provides a server device, including: a script file saving module, configured to receive a script file from a PC front-end device and save the script file.
[0015] In a seventh aspect, the present application provides a client-side service development and loading system based on a ReactNative framework, comprising: a client-side APP as described above; a PC front-end device as described above; and a server device as described above.
[0016] The present application has the following advantages: The present application provides a lightweight and high-performance service development and running environment. When a client-side APP needs to add a new service function, the present application develops a script file for the new service on a PC front-end device, then uploads the script file to a server device, and the client-side APP can run the script file corresponding to the service pulled from the server device when running the service. Compared with the traditional method, the present application realizes dynamic description, combination and deployment of RN services, without the need to publish a new version of the APP, and realizes efficient development and loading of new services.
[0017] Further, the script file of the present application is developed by using a specific BDL language, and the language development environment is a visual graphical interface environment, which improves the development efficiency. Moreover, the BDL language of the present application supports mixed calling of native modules and RN components, and can well compatible with the RN development framework.
[0018] Further, the present application supports dynamic analysis and execution of BDL when running the service, and has high execution efficiency.
[0019] In addition, the present application supports parallel running of multiple service instances, which are isolated from each other to avoid conflicts. Moreover, the present application provides resource management and priority scheduling mechanism to ensure the performance and stability of the running of multiple service instances. BRIEF DESCRIPTION OF DRAWINGS
[0020] Figure 1 is a flowchart of an embodiment of the client-side service development and loading method of the present application based on a ReactNative framework; Figure 2 is an embodiment of the step S15 of Figure 1 Figure 3 is a structural diagram of an embodiment of the client-side service development and loading system of the present application based on a ReactNative framework; Figure 4 is an embodiment of the service logic execution module 32 of Figure 3 DETAILED DESCRIPTION
[0021] It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. EMBODIMENT
[0022] Please refer toFigure 1 , Figure 1 is a flowchart of an embodiment of a mobile application development and loading method based on a ReactNative framework. As shown in Figure 1 , the method comprises the following steps: S11: The PC front-end device 10 automatically generates a script file in response to user operations of dragging graphical components, configuring component attributes, and defining event flows; The PC front-end device 10 is arranged on a PC front end, and the content of the script file includes UI, data flow, and event response.
[0023] The script file is developed in BDL language, which is designed based on JSON or YAML and contains four fields to ensure covering all business needs: (1) component: defining UI components (such as buttons, lists, and maps), including component ID, style, and initial state; (2) data: defining business data (such as initial value, data source (local / network), and data type); (3) logic: defining business logic (such as conditional branching if-else, loop for-each, and asynchronous operation async); (4) event: defining event response (such as user clicks, native capability returns, and system events), and associating corresponding logic execution.
[0024] The BDL language supports control structures such as conditional branching, looping, and asynchronous operation, and supports mixed calling of native modules and RN components.
[0025] The development environment of the script file is a graphical development interface, which integrates debugging tools and supports functions such as breakpoints, variable monitoring, and execution logs to improve development experience.
[0026] Preferably, the user can drag graphical components, configure component attributes, and define event flows, and after the operation is completed, the script file is automatically generated. Alternatively, the user can manually write the script file in BDL language.
[0027] S12: The PC front-end device 10 uploads the script file to the server device 20; After developing the script file, the user can click the upload icon to upload the script file to the server device 20.
[0028] S13: The server device 20 receives the script file from the PC front-end device 10 and saves the script file; The server device 20 of the present application is arranged on a server, which can be a physical device or a virtual server. The server can be a process server or a remote server, which is not limited herein.
[0029] In this step, the server device 20 does not perform other operations on the script file, but only saves the script file for downloading.
[0030] S14: The client APP 30 obtains the script file corresponding to the service running on the client APP 30 from the server device 20. The client APP 30 is an APP running on a client, which is developed based on the ReactNative framework. When the APP enters a certain service, the script file corresponding to the service is automatically obtained from the server device 20.
[0031] The number of services can be multiple, and the multiple services can run in parallel. When multiple services run in parallel, the script file corresponding to each service is obtained from the server device 20, that is, each service corresponds to a script file.
[0032] S15: The client APP 30 executes the service logic based on the script file. Please refer to Figure 2 , Figure 2 is Figure 1 the flowchart of an embodiment of step S15. As shown in Figure 2 , the step includes: S151: Load and parse the script file to generate a virtual DOM and service logic instructions; This step is performed by a BDL parsing engine (Runtime Engine), which is integrated in the APP described in step S14.
[0033] First, load the script file and verify the syntax legality during the loading process.
[0034] Then, parse the script file, generate service logic instructions by parsing the logic field, generate a virtual DOM by parsing the component field, and initialize the service data context by parsing the data field.
[0035] The service logic instruction is an "executable service logic fragment" generated based on the JSON format (homogeneous with BDL, ensuring lightweight and easy parsing), which includes four major elements: operation type, parameter, dependency relationship, and callback logic, corresponding to the service logic defined by BDL language (conditional branching, loop, native capability calling, etc.). Taking the service of "calling GPS and displaying content according to location" as an example, the specific form of the service logic instruction is as follows: { "instructionSetId": "GPS_ShowLogic_001", / / Unique identifier for the instruction set "instructions": [ { "type": "CALL_NATIVE", / / Operation type: Invoking native capabilities "params": { "nativeModule": "GPS", / / Native module name "method": "getHighAccuracyLocation", / / Native method name "timeout": 10000 / / Parameter: Timeout period }, "callback": "handleGPSResult", / / Callback function name after execution "nextInstructionId": "IF_001" / / Next instruction ID (flow connection) }, { "id": "IF_001", "type": "CONDITION", / / Operation type: conditional branch "condition": "${location.latitude} > 30", / / Condition (referencing the location data returned by the preceding instruction) "trueBranch": "SHOW_001", / / The instruction ID to execute when the condition is true "falseBranch": "SHOW_002" / / Instruction ID to execute when the condition is false }, { "id": "SHOW_002", "type": "UPDATE_UI", / / Operation type: Update UI "params": { "componentId": "locationText", / / Target UI component ID "content": "Current location latitude ≤ 30°" / / Updated content } } ] } The business logic instruction can be directly parsed and executed by the RN runtime, while the explicit flow dependency (such as "the conditional judgment is executed after the GPS is called") ensures the orderliness of the business logic.
[0036] S152: loading the virtual DOM completes the UI rendering; S153: executing the business logic instruction, determining whether the native module needs to be called, if yes, calling the native module, if no, executing the next step; The native module is an API function encapsulating a native function.
[0037] S154: listening to the event in the script file and executing the event; The event defined in the event field in the script file is listened to, and data updating and re-parsing are triggered. By executing the interaction or system event, the closed-loop operation of the business logic is realized. The event includes two types: (1) Interaction event: after calling the native module, the user needs to further interact to complete the business. For example, after calling the camera to take a picture, the interaction event of "user clicking the save / cancel button" needs to be listened to. If "save" is clicked, a new instruction of "calling the storage module to save the picture" is triggered; if "cancel" is clicked, an instruction of "quitting the camera scene" is triggered.
[0038] (2) System event: after the execution of the native module, the change of the system state may affect the business. For example, after calling the GPS to obtain the location, the "network connection state change" event needs to be listened to. If the network changes from disconnected to connected, the instruction of "uploading the location data to the server" is triggered; if the network remains disconnected, the instruction of "locally caching the location data" is triggered.
[0039] It should be noted that the number of businesses described in steps S14 and S15 can be multiple. When multiple business instances run in parallel, the following mechanisms are used to realize the scheduling and isolation between multiple business instances: (1) Isolation mechanism: ensure that the multiple business instances do not conflict in resources and do not interfere with the state, which is realized by 3-layer isolation: Resource isolation: allocate independent memory space and threads for each business instance, for example: when "take-out order business" and "map navigation business" run simultaneously, two instances use independent memory blocks to store business data and independent threads to execute instruction sets, avoiding memory overflow or thread preemption.
[0040] Data isolation: Create independent "data context" for each instance - data between instances cannot be directly accessed, and controlled interaction needs to be realized through "standardized interface" (such as cross-instance data transmission API), for example: the "delivery address" data of "take-out order business" needs to be transmitted to "map navigation business" through an authorized interface to avoid data leakage or mismodification.
[0041] Native capability isolation: The native bridge layer allocates "native module call quota" for each business instance. For example: limit the number of native modules called by a single instance at the same time (such as maximum GPS+storage, cannot call camera again), avoid multiple instances competing for the same native resource (such as camera hardware) leading to crash.
[0042] (2) Scheduling mechanism: Ensure that multiple business instances have "stable performance and ordered priority", the core is "resource allocation + priority scheduling". Specifically includes: Resource allocation: The business instance manager monitors CPU, memory, and battery status in real time, and allocates resources for instances - for example: when the battery power is lower than 20%, reduce the CPU occupancy of "background statistics business", and prioritize the resource needs of "foreground payment business".
[0043] Priority scheduling: Set "high / medium / low" three levels of priority for multiple business instances, and allocate execution rights according to priority - for example: when "payment business" (high priority) is triggered, suspend the instruction execution of "product recommendation business" (low priority), and prioritize the payment process; after payment is completed, resume the execution of low-priority instances. Embodiment
[0044] Please refer to Figure 3 , Figure 3 is a structural schematic diagram of an embodiment of the client business development and loading system based on the ReactNative framework. As Figure 3 shown, the system includes a PC front-end device 10, a server device 20, and a client APP 30.
[0045] The PC front-end device 10 includes a script file generation module 11 and a script file sending module 12. The script file generation module 11 is used to automatically generate a script file in response to user operations of dragging a graphical component, configuring component attributes, and defining an event flow. The script file sending module 12 is used to send the script file to the server device 20.
[0046] The server device 20 includes a script file saving module 21, which is used to receive the script file from the PC front-end device 10 and save the script file.
[0047] The client APP 30 comprises a script file obtaining module 31 and a business logic executing module 32. The script file obtaining module 31 is configured to obtain a script file corresponding to a business running on the client APP 30 from a server device. The business logic executing module 32 is configured to execute business logic based on the script file.
[0048] Specifically, referring to Figure 4 as shown in Figure 4 , the business logic executing module 32 comprises a script file loading and parsing unit 321, a UI generating unit 322, a business logic instruction executing unit 323 and an event executing unit 324. The script file loading and parsing unit 321 is configured to load and parse the script file to generate a virtual DOM and business logic instructions. The UI generating unit 322 is configured to load the virtual DOM to complete UI rendering. The business logic instruction executing unit 323 is configured to execute the business logic instructions, determine whether to call a native module, if yes, call the native module, if not, execute the next step, wherein the native module is an API function encapsulating a native function. The event executing unit 324 is configured to listen to events in the script file and execute the events.
[0049] Specifically, the working methods of the modules in the embodiment have been described in detail in Embodiment 1, and will not be repeated here.
[0050] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the described embodiments. Those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the present application. These equivalent modifications or replacements are all included in the scope defined by the claims of the present application.
Claims
1. A method for developing and loading client-side services based on a ReactNative framework, executed by a client APP, characterized in that, The application relates to a method for generating and uploading a script file of a client APP based on a ReactNative framework. The method comprises the following steps: The script file is used to execute business logic.
2. The client service development and loading method of claim 1, wherein, The content of the script file comprises UI, data flow and event response, the script file is developed by using a BDL language, the BDL language supports mixed calling of a native module and an RN component, and a development environment of the script file is a graphical development interface.
3. The client service development and loading method of claim 1, wherein, The method for executing business logic based on the script file comprises the following steps: The script file is loaded and parsed to generate a virtual DOM and business logic instructions; The virtual DOM is loaded to complete UI rendering; The business logic instructions are executed to determine whether a native module needs to be called, if yes, the native module is called, and if not, the next step is executed, wherein the native module is an API function encapsulating a native function; Events in the script file are listened to and the events are executed.
4. The client service development and loading method of claim 1, wherein, The method further comprises the following steps: The number of the businesses is multiple, when multiple businesses are run in parallel, each business corresponds to a script file, and an isolation and scheduling mechanism is used to ensure stable running of the multiple businesses.
5. A client service development and loading method based on a ReactNative framework, executed by a PC front-end device, characterized in that, The method comprises the following steps: In response to operations of dragging a graphical component, configuring component attributes and defining an event flow, a script file is automatically generated; The script file is uploaded to a server device.
6. A method for developing and loading client-side applications based on the React Native framework, executed by a server device, characterized in that, The method comprises the following steps: The script file is received from a PC front-end device and saved.
7. A client APP, characterized in that, The method comprises the following steps: A script file acquisition module is used to acquire, from a server device, a script file corresponding to a business running on a client APP; A business logic execution module is used to execute business logic based on the script file.
8. A PC front end device, characterized by The method comprises the following steps: A script file generation module is used to automatically generate a script file in response to operations of dragging a graphical component, configuring component attributes and defining an event flow; A script file sending module is used to send the script file to a server device.
9. A server apparatus characterized by comprising: The method comprises the following steps: A script file saving module is used to receive a script file from a PC front-end device and save the script file.
10. A client service development and loading system based on a ReactNative framework, characterized in that, The application relates to a client APP according to claim 7; The application relates to a PC front-end device according to claim 8; The application relates to a server device according to claim 9.
Citation Information
Patent Citations
Method and device for uploading and pushing script
CN103353845A
Method and device for allowing script module to quote native resource, and terminal device
CN108052319A
Application program generation method and device, server and storage medium
CN109683893A
Application React Native service execution method and device , storage medium and terminal device
CN110442399A
Business processing method, device and equipment and computer readable storage medium
CN113542323A
