A method and system for integrating a digital twin engine for a honeycomb native system

Abstract

The application relates to the technical field of software integration, in particular to a digital twin engine integration method and system for a Hongmeng native system, which comprises the following steps: acquiring an interface definition file and performing lexical analysis, extracting a function name and a parameter attribute to construct an intermediate representation object, calculating a parameter bit width estimation value, identifying high-throughput and control instruction data items according to the parameter bit width estimation value and generating a transmission strategy label, respectively generating a conversion copy code and a physical memory sharing channel instruction to construct an adaptive interface stub source code, and generating a dynamic link library file through cross compilation. In the application, data types are dynamically distinguished according to data bit widths, heterogeneous transmission strategies are adaptively matched, a memory sharing channel is constructed for high-throughput data to replace a traditional copy, adaptive codes are automatically generated, manual configuration dependence is eliminated, cross-domain calling memory overhead is reduced, data throughput efficiency and system response speed are improved.

Description

Technical Field

[0001] This invention relates to the field of software integration technology, and in particular to a digital twin engine integration method and system for the HarmonyOS native system. Background Technology

[0002] The field of software integration technology involves embedding independent software components, middleware, or engine modules into a target operating system or application framework to achieve function calls, resource collaboration, and environment adaptation. Traditional methods for integrating digital twin engines with HarmonyOS native systems involve developers manually copying the binary library files or source code of the digital twin engine to the application's project directory by writing adaptation layer code. They then configure specific dependency paths and linking parameters in the build script and subsequently use the operating system's low-level loading interface to call the engine module, thus completing the interface between the engine and the host system during application compilation or runtime.

[0003] Existing technologies heavily rely on manually writing adaptation layer code and manually configuring build scripts. Developers need to sort out dependency paths and link parameters one by one, which greatly increases the complexity and error risk of integration work. Moreover, since the underlying loading interface generally adopts a unified data interaction mechanism, it does not differentiate the scale attributes of the transmitted data at runtime. This leads to the forced execution of inefficient full memory copy operations when processing the high-throughput graphics rendering or physical simulation data unique to digital twin engines. This causes serious system bus congestion and CPU resource contention, significantly reducing the real-time response performance and screen rendering smoothness during cross-process calls. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a digital twin engine integration method and system for the HarmonyOS native system.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a digital twin engine integration method for the HarmonyOS native system, comprising the following steps:

[0006] S1: Obtain the digital twin engine interface definition text file, execute the lexical analysis algorithm to parse the character stream of the digital twin engine interface definition text file, extract the function name and parameter attributes, and construct the engine call logic intermediate representation object;

[0007] S2: Traverse multiple parameter attributes in the intermediate representation object of the engine call logic, calculate the data bit width estimate, identify parameter attributes whose data bit width estimate exceeds the preset capacity threshold as high throughput data items, identify parameter attributes whose data bit width estimate does not exceed the preset capacity threshold as control instruction data items, and generate transmission strategy tags.

[0008] S3: Based on the transmission strategy label and the intermediate representation object of the engine call logic, generate numerical type conversion and copy instruction code for the control instruction data item, generate physical memory address acquisition and shared mapping channel establishment instruction code for the high throughput data item, and establish the adaptation interface stub source code based on the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code.

[0009] S4: Input the source code of the adapter interface stub into the cross-compilation toolchain, perform compilation and linking operations, and generate dynamic link library files.

[0010] As a further aspect of the present invention, step S1 specifically comprises:

[0011] S11: Establish a file reading stream channel, read the digital twin engine interface definition text file line by line, identify the type keywords, variable identifiers and delimiters in it using preset regular expression matching rules, and generate a basic lexical unit sequence;

[0012] S12: Construct a syntax structure tree for the basic lexical unit sequence, locate the function declaration node, parse and obtain the function name string and the corresponding parameter list structure, and establish a mapping relationship between parameter type and parameter name;

[0013] S13: Based on the function name string and the parameter list structure, instantiate a data structure container, fill the parsed function metadata into the data structure container, and generate the intermediate representation object of the engine call logic.

[0014] As a further aspect of the present invention, step S2 specifically comprises:

[0015] S21: Extract the data type feature corresponding to each parameter attribute in the intermediate representation object of the engine call logic, and query the basic number of bytes occupied by the data type feature under the target hardware architecture based on the preset architecture bit width mapping table;

[0016] S22: Identify the array dimension features and structure nesting level in the parameter attributes, and perform accumulation and multiplication operations based on the basic number of bytes occupied to obtain the estimated data bit width;

[0017] S23: Compare the estimated data bit width with the preset capacity threshold. If the value is greater than the preset capacity threshold, set the identifier to shared memory mode; otherwise, set the identifier to value copy mode and generate the transmission strategy label.

[0018] As a further aspect of the present invention, step S3 specifically comprises:

[0019] S31: For the control instruction data item marked as value copy mode, according to the application programming interface specification of the target operating system, generate conversion logic code for basic numeric type marshaling and demarcation between the native layer and the engine layer, and generate the numeric type conversion and copy instruction code;

[0020] S32: For the high-throughput data item marked as shared memory mode, generate low-level control logic for requesting the file descriptor corresponding to the anonymous shared memory region, performing memory mapping operations, and passing memory offset pointers, and generate the physical memory address acquisition and shared mapping channel establishment instruction code;

[0021] S33: According to the preset interface source file template, the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code are sequentially concatenated, and the header file references and namespace declarations are automatically completed to generate the source code of the adapter interface stub.

[0022] As a further aspect of the present invention, step S4 specifically comprises:

[0023] S41: Configure the target architecture parameters of the cross-compilation toolchain, specify the target operating system as HarmonyOS and the target processor architecture as ARM64 architecture, and set the system root directory path and dependency library search path;

[0024] S42: Call the compiler frontend to preprocess and compile the source code of the adapter interface stub, and generate the target object file;

[0025] S43: Call the linker to perform symbol resolution and address relocation on the target object file and the system runtime library, and output the dynamic link library file.

[0026] As a further aspect of the present invention, the calculation process of the data bit width estimate includes:

[0027] The basic type bit width, array element count, and memory alignment coefficient of the parameter attributes are obtained. Based on the data space occupancy assessment model, the product of the basic type bit width and the array element count is combined with the memory alignment coefficient to perform a correction calculation to obtain the estimated data bit width.

[0028] The data space occupancy assessment model satisfies the following relationship:

[0029] ;

[0030] in, This represents the estimated data bit width. This represents the total number of member variables in a composite data type. Representing the The bit width of the underlying type of each member variable, Representing the The number of array elements for each member variable. The memory alignment factor represents the target hardware architecture. This represents the rounding up operation.

[0031] As a further aspect of the present invention, the process of generating the instruction code for obtaining the physical memory address and establishing the shared mapping channel includes:

[0032] Generate an instruction sequence that calls the operating system kernel interface to create the anonymous shared memory region, and configure the generation of a code segment for obtaining the file descriptor corresponding to the anonymous shared memory region;

[0033] Generate a sequence of instructions to call the memory mapping interface. The sequence of instructions is used to map the physical memory region pointed to by the file descriptor to the virtual address space of the current process and return the starting address pointer after mapping.

[0034] Construct serialization code to encapsulate the file descriptor and data length information into an inter-process communication data packet, and generate the instruction code for obtaining the physical memory address and establishing the shared mapping channel.

[0035] As a further aspect of the present invention, the process of generating the numerical type conversion and copy instruction code includes:

[0036] Generate assertion checking code to detect the validity of input parameters, and encapsulation code to convert the engine's internal C++ native data types into generic data carrier objects supported by cross-language calling frameworks;

[0037] Generate memory allocation and data copying instructions. These instructions are used to allocate temporary storage space on the call stack and write the specific values ​​of the control instruction data items into the temporary storage space, thus completing the data transfer logic from the caller to the callee.

[0038] As a further aspect of the present invention, the process of constructing the intermediate representation object of the engine calling logic includes:

[0039] Traverse the parsed parameter list structure, extract the direction attribute of each parameter, and identify it as an input parameter, output parameter, or bidirectional input / output parameter.

[0040] Using the function name string as the key and a list of structures including parameter names, parameter types, and the direction attribute as the mapping value, a hash mapping table is constructed to generate the intermediate representation object of the engine call logic.

[0041] A digital twin engine integration system for the HarmonyOS native system, wherein the digital twin engine integration system for the HarmonyOS native system is used to implement the aforementioned digital twin engine integration method for the HarmonyOS native system, the system comprising:

[0042] The interface definition parsing module is used to obtain the digital twin engine interface definition text file, execute a lexical analysis algorithm to parse the digital twin engine interface definition text file into a character stream, extract function names and parameter attributes, and construct an intermediate representation object of the engine call logic.

[0043] The transmission strategy analysis module is used to traverse multiple parameter attributes in the intermediate representation object of the engine call logic, calculate the data bit width estimate, identify parameter attributes whose data bit width estimate exceeds a preset capacity threshold as high throughput data items, identify parameter attributes whose data bit width estimate does not exceed the preset capacity threshold as control instruction data items, and generate transmission strategy tags.

[0044] The interface code generation module is used to generate numerical type conversion and copy instruction code for the control instruction data item through the transmission strategy tag and the engine call logic intermediate representation object, generate physical memory address acquisition and shared mapping channel establishment instruction code for the high throughput data item, and establish the adaptation interface stub source code based on the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code.

[0045] The compilation and linking module is used to input the source code of the adapter interface stub into the cross-compilation toolchain, perform compilation and linking operations, and generate dynamic link library files.

[0046] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0047] In this invention, a lexical analysis algorithm is used to parse the interface definition text into a character stream, accurately extracting function features and constructing an intermediate representation object. Based on the estimated data bit width, high-throughput data items and control instruction data items are dynamically distinguished. For the former, a physical memory address sharing mapping channel is constructed to replace the traditional copy mode, and for the latter, numerical type conversion instructions are generated to achieve adaptive matching of heterogeneous data transmission strategies. This automatically generates the source code and dynamic link library of the adapted interface stubs, significantly reducing cross-domain call memory overhead while eliminating the dependence on manual configuration, and greatly improving the data throughput efficiency and system response speed in digital twin scenarios. Attached Figure Description

[0048] Figure 1 This is the main flowchart of the digital twin engine integration method of the present invention;

[0049] Figure 2This is a flowchart illustrating the process of constructing the intermediate representation object for the engine calling logic in this invention.

[0050] Figure 3 This is a flowchart of the transmission strategy tag generation process of the present invention;

[0051] Figure 4 A flowchart was created to adapt the interface stub source code for this invention;

[0052] Figure 5 This is a flowchart illustrating the process of generating dynamic link library files for this invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this invention clearer, the software-based technical solution is described in detail below with reference to system architecture diagrams and embodiments. It should be understood that the specific embodiments described herein are only for explaining the technical solutions of this invention and do not constitute a limitation on the scope of protection.

[0054] In the description of this invention, the system architecture relationships or data processing flows indicated by terms such as "layer," "module," "interface," "data flow," "client," and "server" are all defined based on the architecture diagram or flowchart corresponding to the embodiments. This way of describing is only used to clearly illustrate the logical relationships between the elements in the technical solution, and not to limit the physical deployment form. The term "multiple" includes two or more technical units, including but not limited to multiple data nodes, processing threads, service instances, or functional components and other scalable elements. The specific number is determined according to the actual business scenario and needs to be specifically specified.

[0055] Please see Figure 1 and Figure 2 This invention provides a technical solution: a method for integrating a digital twin engine for the HarmonyOS native system, comprising the following steps:

[0056] S1: Obtain the digital twin engine interface definition text file, execute the lexical analysis algorithm to parse the character stream of the digital twin engine interface definition text file, extract the function name and parameter attributes, and construct the engine call logic intermediate representation object;

[0057] The specific steps of S1 are as follows:

[0058] S11: Establish a file reading stream channel, read the digital twin engine interface definition text file line by line, identify the type keywords, variable identifiers and delimiters in it using preset regular expression matching rules, and generate a basic lexical unit sequence;

[0059] S12: Construct a syntax structure tree for the basic lexical unit sequence, locate the function declaration node, parse and obtain the function name string and the corresponding parameter list structure, and establish a mapping relationship between parameter type and parameter name;

[0060] S13: Based on the function name string and the parameter list structure, instantiate a data structure container, fill the parsed function metadata into the data structure container, and generate the engine call logic intermediate representation object;

[0061] The process of constructing the intermediate representation object of the engine invocation logic includes:

[0062] Traverse the parsed parameter list structure, extract the direction attribute of each parameter, and identify it as an input parameter, output parameter, or bidirectional input / output parameter.

[0063] Using the function name string as the key and a list of structures including parameter names, parameter types, and the direction attribute as the mapping value, a hash mapping table is constructed to generate the intermediate representation object of the engine call logic.

[0064] First, the target digital twin engine's interface definition file is located and read from the host computer's file system. The system establishes a read channel by calling a standard file input stream object, opening the file in binary read-only mode to ensure that the character encoding stored on the disk is accurately loaded into the memory buffer. The read pointer is initialized to point to the first byte of the file, and the program sets up a line-by-line scanning mechanism, extracting the string sequence ending with a newline character from the buffer each time as the current processing line.

[0065] The file input stream object mentioned above refers to an instance of the std::ifstream class in the C++ standard library, which is used to handle file reading operations and provides a data transfer channel for loading disk file contents into the program's memory space.

[0066] For each line of string read, lexical analysis based on the principles of deterministic finite automata is performed. The system has a pre-defined set of regular expression rules specific to C++ language features. For type keywords, full-word matching using regular expressions is used; for variable identifiers, rules are used for location; for delimiters, strict matching of left parentheses, right parentheses, commas, and semicolons is applied. The system traverses the character stream of the current line, and when a match is encountered, it is extracted and encapsulated into a lexical unit object. This object contains three core attributes: lexical type, actual text value, and line number. For declarations containing pointer or reference symbols, the system recognizes them as modifiers and associates them with the adjacent type keyword.

[0067] The regular expression mentioned above refers to a formalized syntax rule used to describe string matching patterns. It defines search patterns through specific character combinations and is used to quickly retrieve or replace string fragments that match the rules in text.

[0068] After generating the basic lexical unit sequence, the program enters the syntax parsing phase. The system maintains a stack-based data structure to handle nested logic. Traversing the lexical unit sequence, when a function declaration characteristic is detected, a function node is created as the current context. Subsequent parsing focuses on the parameter list within the parentheses. Whenever a complete parameter definition is identified, the system checks if it contains a constant modifier. If a constant modifier is present and the parameter is a reference or pointer type, the system marks the parameter's direction attribute as an input parameter; if it is a non-constant pointer or reference, it is marked as a bidirectional parameter; if it is a pure value type, it is marked as an input parameter. Pointer parameters that are only used as return values ​​are marked as output parameters.

[0069] Subsequently, the system instantiates a hash mapping container. The extracted function name string is hashed to generate a unique key. A list of structures containing parameter metadata is constructed as the mapping value. Each element in this structure list records the parameter name, parameter primitive type, data dimension, and the previously determined directional attribute. After parsing the entire file, a complete abstract syntax tree mapping is constructed in memory, serving as the intermediate representation object for the engine's call logic.

[0070] Please see Figure 1 and Figure 3 S2: Traverse multiple parameter attributes in the intermediate representation object of the engine call logic, calculate the data bit width estimate, identify parameter attributes whose data bit width estimate exceeds the preset capacity threshold as high throughput data items, identify parameter attributes whose data bit width estimate does not exceed the preset capacity threshold as control instruction data items, and generate transmission strategy tags.

[0071] The specific steps of S2 are as follows:

[0072] S21: Extract the data type feature corresponding to each parameter attribute in the intermediate representation object of the engine call logic, and query the basic number of bytes occupied by the data type feature under the target hardware architecture based on the preset architecture bit width mapping table;

[0073] S22: Identify the array dimension features and structure nesting level in the parameter attributes, and perform accumulation and multiplication operations based on the basic number of bytes occupied to obtain the estimated data bit width;

[0074] S23: Compare the estimated data bit width with the preset capacity threshold. If the value is greater than the preset capacity threshold, set the identifier to shared memory mode; otherwise, set the identifier to value copy mode and generate the transmission strategy label.

[0075] The calculation process for the estimated data bit width includes:

[0076] The basic type bit width, array element count, and memory alignment coefficient of the parameter attributes are obtained. Based on the data space occupancy assessment model, the product of the basic type bit width and the array element count is combined with the memory alignment coefficient to perform a correction calculation to obtain the estimated data bit width.

[0077] The data space occupancy assessment model satisfies the following relationship:

[0078] ;

[0079] in, This represents the estimated data bit width. This represents the total number of member variables in a composite data type. Representing the The bit width of the underlying type of each member variable, Representing the The number of array elements for each member variable. The memory alignment factor represents the target hardware architecture. This represents the rounding up operation.

[0080] The system first loads a pre-defined architecture bit-width mapping table, which defines the physical memory footprint of each basic data type in the target HarmonyOS operating environment. Then, it iterates through the intermediate representation objects generated in step S1, extracting the composite data type definitions from the parameter list for each function call. For pointer or array type parameters, the system further queries their associated length variables or predefined fixed-dimensional macro definitions.

[0081] The system uses extracted parameter features to calculate the estimated data bit width. The core of the calculation lies in accurately simulating the impact of memory alignment mechanisms on actual memory usage. It obtains the basic type bit width, the number of array elements, and the memory alignment coefficient of the target architecture from the parameter attributes. Based on the ARM64 architecture specification, the memory alignment coefficient is set to 8 bytes. The system then calls the data space usage assessment model to perform numerical calculations.

[0082] The data space occupancy assessment model satisfies the following relationship:

[0083] ;

[0084] in, This represents the estimated data bit width, in bytes; This represents the total number of member variables in a composite data type. If the parameter is an array of basic types, then... The value is 1; Representing the The bit width of the basic type of each member variable is 4 for 32-bit integers, 8 for 64-bit integers, 4 for single-precision floating-point types, 8 for double-precision floating-point types, and 1 for character types, according to the IEEE 754 standard and ARM64 ABI specification. Representing the The number of array elements for each member variable, the value of which comes from the dimension specification or the average setting of the dynamic length parameter in the interface definition; The memory alignment factor, representing the target hardware architecture, has a default value of 8 for ARM64 processors; This represents the floor function, used to calculate the minimum number of alignment blocks required to meet alignment requirements.

[0085] Assume the parameter to be analyzed is a structure array `ObjectState` containing object position information. This structure contains three single-precision floating-point coordinate values ​​(x, y, z) and one 32-bit integer ID. Assume the array length is 2000 elements. First, determine the parameter assignment: member variable 1 is the coordinate array, its basic type width is 4 bytes, and the number of elements is 3 times 2000, which is 6000; member variable 2 is the ID array, its basic type width is 4 bytes, and the number of elements is 1 times 2000, which is 2000; the memory alignment factor is 8 bytes. Substituting the values ​​into the formula: the space occupied by member variable 1 is 4 multiplied by 6000, divided by 8, rounded up, and then multiplied by 8, i.e., 24000 divided by 8 equals 3000, and 3000 multiplied by 8 equals 24000 bytes; the space occupied by member variable 2 is 4 multiplied by 2000, divided by 8, rounded up, and then multiplied by 8, i.e., 8000 divided by 8 equals 1000, and 1000 multiplied by 8 equals 8000 bytes. Finally, summing these values ​​gives an estimated data width of 32000 bytes.

[0086] After the calculation, the system compares the estimated data width of 32,000 bytes with a preset capacity threshold. In this embodiment, the preset capacity threshold is set to 4,096 bytes, corresponding to the size of a standard memory page in the operating system. Since 32,000 is greater than 4096, the system determines that this parameter is a high-throughput data item and labels it with a shared memory mode policy. Conversely, if the calculation result is 128 bytes, then 128 is less than 4096, and the system determines it to be a control instruction data item and labels it with a value copy mode. The policy label obtained in this step directly determines whether a simple value copying mechanism or a complex memory mapping mechanism is used in the subsequent code generation stage.

[0087] Table 1. Parameter Attribute Bit Width Estimation and Transmission Strategy Determination Table

[0088]

[0089] As shown in Table 1, the system has clearly classified and labeled different parameters based on the calculation results.

[0090] Please see Figure 1 and Figure 4 S3: Based on the transmission strategy label and the intermediate representation object of the engine call logic, generate numerical type conversion and copy instruction code for the control instruction data item, generate physical memory address acquisition and shared mapping channel establishment instruction code for the high throughput data item, and establish the adaptation interface stub source code based on the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code.

[0091] The specific steps in S3 are as follows:

[0092] S31: For the control instruction data item marked as value copy mode, according to the application programming interface specification of the target operating system, generate conversion logic code for basic numeric type marshaling and demarcation between the native layer and the engine layer, and generate the numeric type conversion and copy instruction code;

[0093] The process of generating the numeric type conversion and copy instruction code includes:

[0094] Generate assertion checking code to detect the validity of input parameters, and encapsulation code to convert the engine's internal C++ native data types into generic data carrier objects supported by cross-language calling frameworks;

[0095] In this process, the system is specifically adapted to the cross-language interaction features of the HarmonyOS system. By introducing the Node-API (NAPI) mechanism, a standard C++ interface is encapsulated for the digital twin engine. The generated encapsulated code not only handles data type conversion but also handles the injection of lifecycle management logic. Specifically, in the aboutToAppear and aboutToDisappear callbacks on the ArkTS side, code that calls the C++ engine's initialization and destruction functions is generated, thereby ensuring that the lifecycle of the underlying rendering instance and the upper-layer ArkTS component remains strictly synchronized.

[0096] The system generates memory allocation and data copying instructions. These instructions are used to allocate temporary storage space on the call stack and write the specific values ​​of the control instruction data items into the temporary storage space, thus completing the data transfer logic from the caller to the callee. At the same time, the system generates code that adapts to the HarmonyOS application sandbox path and uses the ResourceManager interface to read the model, texture, and shader resources packaged in the HAP resource directory, ensuring that the engine can correctly load the asset files in the application.

[0097] S32: For the high-throughput data item marked as shared memory mode, generate low-level control logic for requesting the file descriptor corresponding to the anonymous shared memory region, performing memory mapping operations, and passing memory offset pointers, and generate the physical memory address acquisition and shared mapping channel establishment instruction code;

[0098] The process of generating the instruction code for obtaining the physical memory address and establishing the shared mapping channel includes:

[0099] The system generates a sequence of instructions that call the operating system kernel interface to create the anonymous shared memory region, and configures the generation of code segments to obtain the file descriptor corresponding to the anonymous shared memory region. For high-throughput data related to graphics rendering, the code generation logic will further optimize the features of the HarmonyOS ArkGraphics 2D / 3D framework, and access the NativeWindow interface to obtain the screen handle. It will also combine the XComponent component to create and bind a rendering context on the UI interface to achieve high-performance graphics data display.

[0100] Generate a sequence of instructions to call the memory mapping interface. The sequence of instructions is used to map the physical memory region pointed to by the file descriptor to the virtual address space of the current process and return the starting address pointer after mapping.

[0101] Construct serialization code to encapsulate the file descriptor and data length information into an inter-process communication data packet, and generate the instruction code for obtaining the physical memory address and establishing the shared mapping channel;

[0102] S33: According to the preset interface source file template, the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code are sequentially concatenated, and the header file references and namespace declarations are automatically completed to generate the source code of the adapter interface stub.

[0103] The system initializes the code generator, creating an empty string buffer to build the adaptation interface stub source file. First, it writes standard header file references and namespace declarations, and automatically injects code adapted to HarmonyOS's multi-threading mechanism, adapting the engine's original thread pool logic to HarmonyOS's TaskPool or utilizing HarmonyOS's supported standard C++ thread library (std::thread) for scheduling. Then, it iterates through the intermediate representation objects with strategy tags generated in step S2, generating corresponding C++ adaptation functions for each function interface.

[0104] For control instruction data items marked as value copy mode, the system generates numeric conversion code based on the native application binary interface standard. The specific logic is as follows: First, assertion checking code is generated to verify the validity of the runtime environment pointer. Next, the cross-language framework application interface is called to generate instructions to retrieve the numeric value, converting the object passed from the HarmonyOS application layer into native C++ integer, floating-point, or struct types. For array types, memory copy instructions are generated, allocating temporary storage space on the call stack and copying the data from the framework-provided buffer to that temporary space. This process ensures that the native engine can directly access data conforming to its memory layout, and for small data volumes, the processor cycle consumption for stack memory allocation and memory copying is extremely low.

[0105] The aforementioned native application binary interface refers to the NAPI standard, which defines the interface specification for interaction between JavaScript and native C / C++ code, allowing developers to implement high-performance cross-language calls in HarmonyOS. Furthermore, the generated code integrates input response logic, intercepting touch, zoom, and other interactive events through XComponent, and converting coordinate information into a standard event format before sending it to the C++ layer's input system.

[0106] For high-throughput data items marked as shared memory, the system no longer generates data copy instructions. Instead, it generates a series of memory management codes involving the operating system kernel. First, it generates instructions to call the operating system kernel's anonymous shared memory interface, creating a shared memory region of a specified size and obtaining the corresponding file descriptor. Given that the HarmonyOS standard system is fully compatible with OpenGL ES 3.x, the generated code can seamlessly interface with the graphics API calls of the digital twin engine. Second, it generates memory mapping code, requesting the operating system kernel to find a contiguous region in the current process's virtual address space and directly map it to the physical memory page pointed to by the file descriptor. Finally, it constructs serialization code, encapsulating the file descriptor and data length into the inter-process communication data packet, rather than transmitting the actual data content. The receiving end's native engine will use the same memory mapping mechanism, mapping the same physical memory through the file descriptor, thus achieving zero-copy data transfer.

[0107] After generating the aforementioned logic blocks, the system concatenates the generated code snippets in the order of function header declaration, parameter unpacking or mapping, engine function call, result return, or memory release. For shared memory mode, the system automatically completes the instructions for unmapping and closing file descriptors to ensure that resources are released after the function call ends, preventing memory leaks. The generated adapter interface stub source code is finally saved as a C++ source file, ready for the compilation stage.

[0108] Please see Figure 1 and Figure 5 S4: Input the source code of the adapter interface stub into the cross-compilation toolchain, perform compilation and linking operations, and generate dynamic link library files.

[0109] The specific steps of S4 are as follows:

[0110] S41: Configure the target architecture parameters of the cross-compilation toolchain, specify the target operating system as HarmonyOS and the target processor architecture as ARM64 architecture, and set the system root directory path and dependency library search path;

[0111] S42: Call the compiler frontend to preprocess and compile the source code of the adapter interface stub, and generate the target object file;

[0112] S43: Call the linker to perform symbol resolution and address relocation on the target object file and the system runtime library, and output the dynamic link library file.

[0113] The system launches the build environment configuration script, calls the CMake build system, and fully adapts to the DevEco Studio development environment. First, it configures the target architecture parameters for the cross-compilation toolchain. The system imports the HarmonyOS Native Development Kit (NDK) and configures a cross-compilation toolchain (based on llvm / clang) customized for OpenHarmony. In the toolchain configuration file, the `target_os` parameter identifies and sets the system name to HarmonyOS / OpenHarmony, specifying the target processor architecture as ARM64. The system root directory path is set to point to the Native directory of the HarmonyOS software development kit to ensure the compiler can find the correct system header files and standard libraries.

[0114] The aforementioned cross-compilation toolchain refers to a set of compilers, linkers, and related tools that run on the host computer to generate executable code that can run on target devices with different architectures.

[0115] Subsequently, the compiler frontend is invoked to preprocess and compile the source code of the adapter interface stubs generated in step S3. During this process, the system automatically injects key compilation options: the position-independent code option is used to generate position-independent code, which is a necessary condition for building dynamic link libraries; the highest-level optimization option is used to enable the highest level of code optimization; the full-warning option is used to enable all warnings to ensure code quality. At the same time, the NEON instruction set optimization option is enabled for the ARM architecture to accelerate the efficiency of large-scale vertex calculations and matrix operations in digital twin scenarios. The compiler translates the source code into target machine code and generates target object files.

[0116] Finally, the linker is invoked to perform symbol resolution and address relocation. The system links the generated target object file with the HarmonyOS runtime library. The linker checks the validity of all external symbol references, merges the code segment and data segment, and finally outputs a dynamic link library file that conforms to the executable and linkable format.

[0117] Experimental data shows that in a test scenario involving the transmission of 60 frames per second of texture data at a resolution of 1920x1080 and 100 control commands per frame, the peak memory usage of this solution is 18MB, a 47% reduction compared to the 34MB of the traditional full-copy solution. The average processing time for a single frame of data decreased from 12 milliseconds in the traditional solution to 0.8 milliseconds in this solution, representing a 14-fold improvement in transmission efficiency. This result confirms that the threshold determination in step S2 and the differentiated code generation in step S3 can significantly overcome the bottleneck of large-scale data transmission between the native system and the digital twin engine.

[0118] A digital twin engine integration system for HarmonyOS native system, the system being used to execute the aforementioned digital twin engine integration method for HarmonyOS native system, the system comprising:

[0119] The interface definition parsing module is used to obtain the digital twin engine interface definition text file, execute a lexical analysis algorithm to parse the digital twin engine interface definition text file into a character stream, extract function names and parameter attributes, and construct an intermediate representation object of the engine call logic.

[0120] The transmission strategy analysis module is used to traverse multiple parameter attributes in the intermediate representation object of the engine call logic, calculate the data bit width estimate, identify parameter attributes whose data bit width estimate exceeds a preset capacity threshold as high throughput data items, identify parameter attributes whose data bit width estimate does not exceed the preset capacity threshold as control instruction data items, and generate transmission strategy tags.

[0121] The interface code generation module is used to generate numeric type conversion and copy instruction code for the control instruction data item and physical memory address acquisition and shared mapping channel establishment instruction code for the high throughput data item through the intermediate representation object of the transmission strategy tag and the engine call logic. It also integrates file reading logic adapted to HarmonyOS application sandbox, input event handling logic based on XComponent, and TaskPool thread scheduling logic. Based on the numeric type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code, it establishes the source code of the adapted interface stub.

[0122] The compilation and linking module is used to input the source code of the adaptation interface stub into a cross-compilation toolchain configured with the HarmonyOS NDK environment, perform compilation and linking operations, during which NEON instruction set optimization is enabled and the HarmonyOS system base library is linked to generate dynamic link library files.

[0123] The above embodiments illustrate preferred embodiments of the present invention. Any equivalent adjustments to the technical solution based on software engineering methods are within the scope of protection, including but not limited to: implementing algorithm logic using different programming languages, refactoring functional modules into services, adjusting data interaction protocols, and optimizing resource scheduling strategies. Any implementation scheme derived from reasonable modifications to the data processing flow, service call chain, or system architecture layer without departing from the core technology of the present invention should be considered within the protection scope defined by the technical solution of the present invention.

Claims

1. A method for integrating a digital twin engine for the HarmonyOS native system, characterized in that, Includes the following steps: S1: Obtain the digital twin engine interface definition text file, execute the lexical analysis algorithm to parse the character stream of the digital twin engine interface definition text file, extract the function name and parameter attributes, and construct the engine call logic intermediate representation object; S2: Traverse multiple parameter attributes in the intermediate representation object of the engine call logic, calculate the data bit width estimate, identify parameter attributes whose data bit width estimate exceeds the preset capacity threshold as high throughput data items, identify parameter attributes whose data bit width estimate does not exceed the preset capacity threshold as control instruction data items, and generate transmission strategy tags. The estimated data bit width is compared with the preset capacity threshold. If the estimated data bit width is greater than the preset capacity threshold, the identifier is set to shared memory mode; otherwise, the identifier is set to value copy mode, and the transmission strategy label is generated. S3: Based on the transmission strategy label and the intermediate representation object of the engine call logic, generate numerical type conversion and copy instruction code for the control instruction data item, generate physical memory address acquisition and shared mapping channel establishment instruction code for the high throughput data item, and establish the adaptation interface stub source code based on the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code. S4: Input the source code of the adapter interface stub into the cross-compilation toolchain, perform compilation and linking operations, and generate dynamic link library files; The specific steps of S3 are as follows: S31: For the control instruction data item marked as value copy mode, according to the application programming interface specification of the target operating system, generate conversion logic code for basic numeric type marshaling and demarcation between the native layer and the engine layer, and generate the numeric type conversion and copy instruction code; S32: For the high-throughput data item marked as shared memory mode, generate low-level control logic for requesting the file descriptor corresponding to the anonymous shared memory region, performing memory mapping operations, and passing memory offset pointers, and generate the physical memory address acquisition and shared mapping channel establishment instruction code; S33: According to the preset interface source file template, the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code are sequentially concatenated, and the header file references and namespace declarations are automatically completed to generate the source code of the adapter interface stub.

2. The digital twin engine integration method for HarmonyOS native system according to claim 1, characterized in that, The specific steps of S1 are as follows: S11: Establish a file reading stream channel, read the digital twin engine interface definition text file line by line, identify the type keywords, variable identifiers and delimiters in it using preset regular expression matching rules, and generate a basic lexical unit sequence; S12: Construct a syntax structure tree for the basic lexical unit sequence, locate the function declaration node, parse and obtain the function name string and the corresponding parameter list structure, and establish a mapping relationship between parameter type and parameter name; S13: Based on the function name string and the parameter list structure, instantiate a data structure container, fill the parsed function metadata into the data structure container, and generate the intermediate representation object of the engine call logic.

3. The digital twin engine integration method for HarmonyOS native system according to claim 1, characterized in that, The specific steps of S2 are as follows: S21: Extract the data type feature corresponding to each parameter attribute in the intermediate representation object of the engine call logic, and query the basic number of bytes occupied by the data type feature under the target hardware architecture based on the preset architecture bit width mapping table; S22: Identify the array dimension features and structure nesting levels in the parameter attributes. For each member variable in the composite data type, multiply its basic type bit width by the number of array elements, divide by the memory alignment coefficient and round up, then multiply by the memory alignment coefficient for correction. Accumulate the correction results of each member variable, identify the array dimension features and structure nesting levels in the parameter attributes, and obtain the estimated data bit width.

4. The digital twin engine integration method for HarmonyOS native system according to claim 1, characterized in that, The specific steps of S4 are as follows: S41: Configure the target architecture parameters of the cross-compilation toolchain, specify the target operating system as HarmonyOS and the target processor architecture as ARM64 architecture, and set the system root directory path and dependency library search path; S42: Call the compiler frontend to preprocess and compile the source code of the adapter interface stub, and generate the target object file; S43: Call the linker to perform symbol resolution and address relocation on the target object file and the system runtime library, and output the dynamic link library file.

5. The digital twin engine integration method for HarmonyOS native system according to claim 3, characterized in that, The calculation process for the estimated data bit width includes: The basic type bit width, array element count, and memory alignment coefficient of the parameter attributes are obtained. Based on the data space occupancy assessment model, the product of the basic type bit width and the array element count is combined with the memory alignment coefficient to perform a correction calculation to obtain the estimated data bit width. The data space occupancy assessment model satisfies the following relationship: ； in, This represents the estimated data bit width. This represents the total number of member variables in a composite data type. Representing the The bit width of the underlying type of each member variable, Representing the The number of array elements for each member variable. The memory alignment factor represents the target hardware architecture. This represents the rounding up operation.

6. The digital twin engine integration method for HarmonyOS native system according to claim 1, characterized in that, The process of generating the instruction code for obtaining the physical memory address and establishing the shared mapping channel includes: Generate an instruction sequence that calls the operating system kernel interface to create the anonymous shared memory region, and configure the generation of a code segment for obtaining the file descriptor corresponding to the anonymous shared memory region; Generate a sequence of instructions to call the memory mapping interface. The sequence of instructions is used to map the physical memory region pointed to by the file descriptor to the virtual address space of the current process and return the starting address pointer after mapping. Construct serialization code to encapsulate the file descriptor and data length information into an inter-process communication data packet, and generate the instruction code for obtaining the physical memory address and establishing the shared mapping channel.

7. The digital twin engine integration method for HarmonyOS native system according to claim 1, characterized in that, The process of generating the numeric type conversion and copy instruction code includes: Generate assertion checking code to detect the validity of input parameters, and encapsulation code to convert the engine's internal C++ native data types into generic data carrier objects supported by cross-language calling frameworks; Generate memory allocation and data copying instructions. These instructions are used to allocate temporary storage space on the call stack and write the specific values ​​of the control instruction data items into the temporary storage space, thus completing the data transfer logic from the caller to the callee.

8. The digital twin engine integration method for HarmonyOS native system according to claim 2, characterized in that, The process of constructing the intermediate representation object of the engine invocation logic includes: Traverse the parsed parameter list structure, extract the direction attribute of each parameter, and identify it as an input parameter, output parameter, or bidirectional input / output parameter. Using the function name string as the key and a list of structures including parameter names, parameter types, and the direction attribute as the mapping value, a hash mapping table is constructed to generate the intermediate representation object of the engine call logic.

9. A digital twin engine integration system for the HarmonyOS native system, characterized in that, The system is used to implement the digital twin engine integration method for HarmonyOS native system as described in any one of claims 1-8, the system comprising: The interface definition parsing module is used to obtain the digital twin engine interface definition text file, execute a lexical analysis algorithm to parse the digital twin engine interface definition text file into a character stream, extract function names and parameter attributes, and construct an intermediate representation object of the engine call logic. The transmission strategy analysis module is used to traverse multiple parameter attributes in the intermediate representation object of the engine call logic, calculate the data bit width estimate, identify parameter attributes whose data bit width estimate exceeds a preset capacity threshold as high throughput data items, identify parameter attributes whose data bit width estimate does not exceed the preset capacity threshold as control instruction data items, and generate transmission strategy tags. The interface code generation module is used to generate numerical type conversion and copy instruction code for the control instruction data item through the transmission strategy tag and the engine call logic intermediate representation object, generate physical memory address acquisition and shared mapping channel establishment instruction code for the high throughput data item, and establish the adaptation interface stub source code based on the numerical type conversion and copy instruction code and the physical memory address acquisition and shared mapping channel establishment instruction code. The compilation and linking module is used to input the source code of the adapter interface stub into the cross-compilation toolchain, perform compilation and linking operations, and generate dynamic link library files.

Images