Bridging method and system for cross-language interface of KaihongOS, terminal and storage medium

Abstract

The invention relates to the technical field of computer software, and discloses a bridging method and system for a cross-language interface of KaihongOS, a terminal and a storage medium. The method comprises the steps that an interface definition file is analyzed, and function declaration information of a target interface is obtained; analyzing a native interface definition file to obtain implementation information of a native interface corresponding to the target interface; and based on the function declaration information and the implementation information, according to a preset bridging rule, automatically generating a bridging function code conforming to a target operation environment, and bridging a cross-language interface through the bridging function code. According to the method, through automatic analysis and code generation, the bridging function code meeting the target operation environment is automatically generated by improving the code quality, and repeated labor and potential errors in manual writing are avoided. A preset bridging rule ensures the consistency and maintainability of codes, the technical threshold can be effectively reduced, and the project cycle is shortened.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a bridging method, system, terminal, and computer-readable storage medium for a cross-language interface of KaihongOS. Background Technology

[0002] In the Kaihong Operating System (KaihongOS), a layered architecture is typically employed: the application layer is developed using high-level languages ​​such as JavaScript (JS) or TypeScript (TS), with TypeScript specifically being Ark TypeScript (ArkTS). The system framework layer, on the other hand, uses native languages ​​such as C (C programming language) or C++ (C++ programming language) to implement core functionalities. The Native Application Programming Interface (NAPI) serves as a crucial bridge mechanism, enabling JavaScript code in the application layer to safely and efficiently call C or C++ interfaces in the system layer.

[0003] Currently, writing corresponding NAPI functions for every C or C++ interface that needs to be exposed to the application layer is a highly manual process. Developers must have a deep understanding of NAPI's complex programming conventions and manually complete tedious and error-prone steps such as type conversion, asynchronous callback handling, and memory management. This development model has the following significant drawbacks: 1. Inefficiency: When the system framework needs to expose a large number of interfaces to the application layer, manually writing NAPI functions becomes a development bottleneck and seriously slows down the project progress.

[0004] 2. High skill threshold: Developers are required to be proficient in both high-level languages ​​and native languages, and to master NAPI programming skills, which increases labor costs.

[0005] 3. Inconsistent code quality: Differences in coding habits and styles among different developers result in inconsistent NAPI code styles, poor readability and maintainability, and a high risk of introducing potential errors.

[0006] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0007] The main objective of this invention is to provide a bridging method, system, terminal, and computer-readable storage medium for a cross-language interface in KaihongOS. This invention aims to solve the problems of low development efficiency, high technical threshold, and inconsistent code quality in cross-language interface bridging caused by manually writing NAPI bridging functions in existing operating system development technologies.

[0008] To achieve the above objectives, the present invention provides a bridging method for a cross-language interface of KaihongOS, the bridging method for a cross-language interface of KaihongOS comprising the following steps: Parse the interface definition file to obtain the function declaration information of the target interface; Parse the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface; Based on the function declaration information and the implementation information, and according to the preset bridging rules, bridging function code that conforms to the target runtime environment is automatically generated, and the cross-language interface is bridged through the bridging function code.

[0009] Furthermore, the parsing of the interface definition file to obtain the function declaration information of the target interface includes: Lexical and syntactic analysis are performed on the interface definition file to generate an abstract syntax tree; Traverse the abstract syntax tree, identify and extract function declaration nodes, and obtain initial function declaration information based on the function declaration nodes; The initial function declaration information is converted into a standardized intermediate representation, and the data types of the intermediate representation are uniformly mapped to obtain the function declaration information, wherein the function declaration information includes the function name, parameter list, return type, and call type.

[0010] Furthermore, the step of parsing the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface includes: The native interface definition file is preprocessed, the header file content of the preprocessed native interface definition file is parsed, and macro definitions and conditional compilation directives are ignored to obtain the syntax tree information of function declarations; Extract the function signature of the native interface corresponding to the target interface from the syntax tree information, wherein the function signature includes the function name, return value type, parameter type list and parameter order; Based on the function signature, a mapping table is established from the native programming language type to the native application interface type, and the mapping table is used as the implementation information of the native interface.

[0011] Furthermore, based on the function declaration information and the implementation information, and according to preset bridging rules, automatically generating bridging function code that conforms to the target runtime environment, and bridging the cross-language interface through the bridging function code, includes: Based on the function name in the function declaration information, a basic framework for bridging functions that conforms to the target runtime environment specifications is created, wherein the basic framework includes standardized function signatures and error handling mechanisms; Based on the parameter type mapping relationship between the function declaration information and the corresponding type in the implementation information, parameter parsing and type conversion logic code is generated and injected into the basic framework of the bridge function. The parameter parsing and type conversion logic code is used to convert parameters described in the high-level language into parameters that can be recognized by the native programming language. Based on the call type in the function declaration information and the implementation information, native interface call logic and return result processing logic are generated, and the native interface call logic and return result processing logic are injected into the basic framework of the bridge function to obtain the bridge function code. The parameters used by the native interface call logic are native language parameters obtained by the parameter parsing and type conversion logic code.

[0012] Furthermore, the basic framework for creating a bridge function that conforms to the target runtime environment specifications includes: Generate the corresponding bridge function name based on the function name of the target interface; Construct a bridge function signature that returns a specific type and takes a runtime environment handle and a callback information handle as input parameters; Inside the bridging function, declare state variables used to record and check the state of application interface calls.

[0013] Furthermore, based on the parameter types in the function declaration information and the corresponding type mapping relationship in the implementation information, parameter parsing and type conversion logic code is generated, including: Based on the mapping relationship between the parameter types in the function declaration information and the corresponding types in the implementation information, a code segment is generated to parse the number of parameters and the parameter value array from the callback information handle; Based on the pre-defined type mapping relationship, type checking code and type conversion code are generated for each parameter in the code segment; wherein, the parameter parsing and type conversion logic code includes the code segment, the type checking code and the type conversion code, and the type conversion code is used to convert the parameter value representation in the high-level language runtime environment into the variable representation in the native programming language.

[0014] Furthermore, the logic for generating the native interface call and the logic for processing the return result include: When the call type is a synchronous call, perform the following operations: Generate code that directly calls the native interface, passing in converted native language parameters when calling it; Generate code to convert the return value of the native interface to the return value type of the bridge function; When the call type is an asynchronous call, perform the following operation: generate code to create an asynchronous task object; Generate asynchronous execution function code, which contains statements calling native interfaces; Generate completion callback function code, wherein the completion callback function code includes logic for processing the result of asynchronous operation and resolving or rejecting asynchronous commitment objects; Generate code to submit the asynchronous task object to the execution queue.

[0015] Furthermore, to achieve the above objectives, the present invention also provides a bridging system for a cross-language interface of KaihongOS, wherein the bridging system for a cross-language interface of KaihongOS includes: The first parsing module is used to parse the interface definition file and obtain the function declaration information of the target interface; The second parsing module is used to parse the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface; The code generation module is used to automatically generate bridging function code that conforms to the target runtime environment based on the function declaration information and the implementation information, according to preset bridging rules, and to bridge the cross-language interface through the bridging function code.

[0016] Furthermore, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and a bridging program for a cross-language interface for KaihongOS stored in the memory and executable on the processor, wherein when the bridging program for the cross-language interface for KaihongOS is executed by the processor, it implements the steps of the bridging method for the cross-language interface for KaihongOS as described above.

[0017] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a bridging program for a cross-language interface for KaihongOS, and the bridging program for the cross-language interface for KaihongOS, when executed by a processor, implements the steps of the bridging method for the cross-language interface for KaihongOS as described above.

[0018] The beneficial effects of this invention are as follows: This invention automatically extracts key information by parsing interface definition files and native interface definition files, avoiding the time cost of manually reviewing and writing code. Pre-defined bridging rules further eliminate repetitive work.

[0019] This invention automatically generates bridging function code that conforms to the target runtime environment, supporting batch parsing and code generation of a large number of interface definition files. The bridging function code bridges cross-language interfaces, making it suitable for scenarios where the system framework layer needs to expose a large number of interfaces to the application layer. Compared to traditional manual methods, this improves code generation speed and shortens the development cycle of cross-language interface bridging projects. Attached Figure Description

[0020] Figure 1 This is a flowchart of a preferred embodiment of the bridging method for a cross-language interface of KaihongOS according to the present invention; Figure 2 This is a flowchart of the overall framework of the bridging method for cross-language interfaces of KaihongOS according to the present invention; Figure 3 This is a flowchart of step S10 of a preferred embodiment of the bridging method for a cross-language interface of KaihongOS according to the present invention; Figure 4 This is a flowchart of step S20 of a preferred embodiment of the bridging method for a cross-language interface of KaihongOS according to the present invention; Figure 5 This is a flowchart of step S30 of a preferred embodiment of the bridging method for a cross-language interface of KaihongOS according to the present invention; Figure 6 This is a flowchart of the automatic generation scheme of NAPI bridging functions based on KaihongOS in the bridging method for cross-language interfaces of KaihongOS in this invention; Figure 7 This is a structural diagram of a preferred embodiment of the bridging system for a cross-language interface of KaihongOS according to the present invention; Figure 8 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

[0021] This application provides a bridging method, system, terminal, and storage medium for a cross-language interface of KaihongOS. To make the objectives, technical solutions, and effects of this application clearer and more explicit, the following detailed description is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application.

[0022] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0023] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0024] The bridging method for a cross-language interface for KaihongOS described in the preferred embodiment of the present invention, such as... Figure 1 and Figure 2 As shown, the bridging method for the cross-language interface of KaihongOS includes the following steps: S10. Parse the interface definition file to obtain the function declaration information of the target interface.

[0025] The purpose of this step is to extract metadata about function declarations from high-level language interface definition files (such as ArkTS's .d.ts files), including function names, return types, parameter types, and call types (synchronous or asynchronous). This information forms the basis for generating bridge functions, ensuring that the generated code accurately reflects the interface semantics.

[0026] In this embodiment, taking the common ArkTS interface of KaihongOS as an example, such as a function declared as `declarefunction getUser(id: number): Promise`. <string>The .d.ts file needs to be parsed to extract the function name getUser, the parameter type number, and the return type Promise. <string>and asynchronous call types.

[0027] like Figure 3 As shown, step S10 includes: S11. Perform lexical and syntactic analysis on the interface definition file to generate an abstract syntax tree.

[0028] The purpose of this step is to convert the source code into a structured tree representation, facilitating precise information extraction. In practice, tools such as the TypeScript compiler API or ANTLR can be used for parsing. First, lexical analysis is performed, breaking down the file content into tokens, such as keywords (function), identifiers (getUser), and operators. Then, syntax analysis is performed, constructing an abstract syntax tree based on ArkTS syntax rules. For example, for the function declaration mentioned above, the abstract syntax tree will contain a function declaration node, whose child nodes represent the function name, parameter list (including parameter id and type number), and return type annotation, respectively. In this embodiment, compatibility with ArkTS-specific syntax, such as decorators or generics, is required to ensure the integrity of the parsing. It should be noted that the parsing process should handle error recovery mechanisms to avoid interruptions due to syntax errors.

[0029] S12. Traverse the abstract syntax tree, identify and extract function declaration nodes, and obtain initial function declaration information based on the function declaration nodes.

[0030] The purpose of this step is to extract key information from the abstract syntax tree (AST) to form structured initial data. A depth-first traversal algorithm is used to access the AST nodes, filtering function declaration nodes (such as the `FunctionDeclaration` type). For each node, initial function declaration information is extracted, including: function name (obtained from the `name` property), parameter list (parameter names and type annotations are extracted from the `parameters` child node), and return type (obtained from the `returnType` child node, such as `Promise`). <string>The initial information includes the function name `getUser`, the parameter list `[{name:"id", type: "number"}]`, and the return type `Promise`. For example, for the `getUser` function, the initial information includes: function name `getUser`, parameter list `[{name:"id", type: "number"}]`, and return type `Promise`. <string>The call type is asynchronous. In this embodiment, for complex types (such as union types), all subtypes need to be extracted recursively to ensure information integrity. It should be noted that the traversal process should record node position information for easy debugging and error location.

[0031] S13. Convert the initial function declaration information into a standardized intermediate representation, and perform a unified mapping on the data type of the intermediate representation to obtain the function declaration information, wherein the function declaration information includes the function name, parameter list, return type, and call type.

[0032] The purpose of this step is to eliminate differences in development styles and improve the consistency of code generation. Initial information is converted into a standardized intermediate representation (such as JSON Schema or a custom IR format) and type mapping is performed.

[0033] For example, mapping ArkTS's number to the intermediate representation INT32, string to STRING, and Promise to... <t>The function is mapped to the asynchronous type ASYNC and the generic parameter T is recorded. The final function declaration information includes: function name, parameter list (each parameter includes name and mapped type), return type (mapped type), and call type.

[0034] In this embodiment, the intermediate representation can be designed as a key-value pair structure, which facilitates processing by subsequent modules; the mapping rules are based on a preset type table and support expansion.

[0035] It should be noted that the normalization process needs to handle type aliases and default values ​​to ensure the correspondence with the target runtime environment type.

[0036] S20. Parse the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface.

[0037] The purpose of this step is to extract function implementation details from native language files (such as C++ header files) to provide a basis for calling the bridging function. In this embodiment, taking the C++ header file of the KaihongOS system framework layer as an example, such as a .h file declared as std::string getUser(int id);, it is necessary to parse out the function name getUser, the return type std::string, the parameter type list int, and the order of the parameters.

[0038] like Figure 4 As shown, step S20 includes: S21. Preprocess the native interface definition file, parse the header file content of the preprocessed native interface definition file, ignore macro definitions and conditional compilation directives, and obtain the syntax tree information of function declarations.

[0039] The purpose of this step is to reduce noise and improve parsing accuracy. The header file is preprocessed using a Clang or GCC parsing library (such as LibClang), expanding macro definitions (such as #define) and filtering conditional compilation blocks (such as #ifdef). Then, a syntax tree (similar to an abstract syntax tree) is generated, focusing on the function declaration section.

[0040] For example, for the `getUser` function, the syntax tree will contain a function declaration node, whose child nodes represent the return type `std::string`, the function name `getUser`, and the parameter list `int id`. In this embodiment, a parser needs to be configured to recognize KaihongOS-specific annotations (such as exported macros) to ensure that critical information is not lost.

[0041] It should be noted that type definitions and namespace information should be preserved during the preprocessing stage to avoid semantic distortion.

[0042] S22. Extract the function signature of the native interface corresponding to the target interface from the syntax tree information. The function signature includes the function name, return value type, parameter type list and parameter order.

[0043] The purpose of this step is to extract standardized function signatures, laying the foundation for type mapping. Traverse the syntax tree, matching function names with the target interface names extracted in S10 (e.g., through a function name mapping table). Extract the complete function signature, for example: function name getUser, return type std::string, parameter type list ["int"], with the first parameter being int.

[0044] In this embodiment, for overloaded functions, different versions need to be distinguished by parameter types; for template functions, the specific type needs to be extracted after instantiation.

[0045] It should be noted that signature extraction should handle reference types (such as const std::string&) and constant modifiers to ensure accuracy.

[0046] S23. Based on the function signature, establish a mapping table from the native programming language type to the native application interface type, and the mapping table serves as the implementation information of the native interface.

[0047] The purpose of this step is to establish type conversion rules to achieve seamless integration between native language and NAPI types. Based on function signatures, a mapping table is created to map C++ types to NAPI type processing functions.

[0048] For example, `std::string` is mapped to the NAPI functions `napi_create_string_utf8` (for creating strings) and `napi_get_value_string_utf8` (for retrieving strings), and `int` is mapped to `napi_create_int32` and `napi_get_value_int32`. The mapping table can be stored as a hash table or a configuration file, containing the type name, corresponding NAPI function, and memory management conventions.

[0049] In this embodiment, basic types (such as double), composite types (such as structures), and pointer types must be supported to ensure comprehensive coverage.

[0050] It should be noted that the mapping relationship should handle low-level details such as type endianness and memory alignment to ensure cross-platform compatibility.

[0051] S30. Based on the function declaration information and the implementation information, according to the preset bridging rules, automatically generate bridging function code that conforms to the target runtime environment, and bridge the cross-language interface through the bridging function code.

[0052] This step is the core of the invention, aiming to convert the parsed results into compilable NAPI bridging function code. The pre-defined bridging rules include parameter conversion, asynchronous callback processing, and error handling mechanisms, based on the NAPI framework design of KaihongOS.

[0053] In this embodiment, taking the generation of NAPI bridging code for the getUser function as an example, a complete function body needs to be generated according to the call type (asynchronous).

[0054] like Figure 5 As shown, step S30 includes: S31. Based on the function name in the function declaration information, create a basic framework for a bridging function that conforms to the target runtime environment specification. The basic framework includes a standardized function signature and an error handling mechanism.

[0055] The purpose of this step is to define the function entry point and basic structure. A bridge function name is generated based on the function name (e.g., the ArkTS function `getUser` corresponds to the NAPI function `napi_getUser`), and the function signature is constructed: the return value type is `napi_value`, and the parameters are `napi_env env` (runtime environment handle) and `napi_callback_info info` (callback information handle). Within the function body, state variables (e.g., `napi_status status`) and an error handling framework (e.g., using `napi_throw_error` to throw an exception) are declared. For example, the generated basic framework code is as follows: napi_value napi_getUser(napi_env env, napi_callback_info info) { napi_status status; napi_value result; / / Error checking framework status = napi_create_object(env,&result); if (status != napi_ok) { napi_throw_error(env, NULL, "Failed to initialize result"); return nullptr; } / / Subsequent logic will be injected here return result; } In this embodiment, the framework must conform to the NAPI programming specification to ensure thread safety. It should be noted that error handling should cover potential failure points such as parameter parsing and type conversion.

[0056] Furthermore, the basic framework for creating a bridging function that conforms to the target runtime environment specifications includes: Generate the corresponding bridge function name based on the function name of the target interface; Construct a bridge function signature that returns a specific type and takes a runtime environment handle and a callback information handle as input parameters; Inside the bridging function, declare state variables used to record and check the state of application interface calls.

[0057] It should be noted that this embodiment achieves uniformity in framework generation, accuracy in environment adaptation, and controllability in error handling by establishing a standardized and normalized bridging function framework. Furthermore, this embodiment transforms the framework building process, which originally relied on the individual experience of developers, into an automated and standardized process, ensuring from the source that the generated bridging functions meet the specifications of the target runtime environment.

[0058] S32. Based on the parameter type mapping relationship between the function declaration information and the corresponding type in the implementation information, generate parameter parsing and type conversion logic code, and inject the parameter parsing and type conversion logic code into the basic framework of the bridge function. The parameter parsing and type conversion logic code is used to convert the parameters described in the high-level language into parameters that can be recognized by the native programming language.

[0059] The purpose of this step is to convert parameters from ArkTS to C++. First, a parameter parsing code segment is generated: the `napi_get_cb_info` function is called to extract the number of parameters and the value array from the `info` handle. Then, based on the type mapping, type checking code (e.g., using `napi_typeof` to verify the type) and type conversion code (e.g., using `napi_get_value_int32` to convert `napi_value` to a C++ `int`) are generated for each parameter. For example, for the parameter `id:number` in the `getUser` function, the generated logic code is as follows: size_t argc = 1; napi_value args[1]; status = napi_get_cb_info(env, info,&argc, args, NULL, NULL); if (status != napi_ok || argc<1) { napi_throw_type_error(env, NULL, "Expected 1 argument"); return nullptr; } / / Type checking: Validate the first parameter as a number napi_valuetype valuetype; status = napi_typeof(env, args[0],&valuetype); if (status != napi_ok || valuetype != napi_number) { napi_throw_type_error(env, NULL, "Argument must be number"); return nullptr; } / / Type conversion: Convert napi_value to int int id; status = napi_get_value_int32(env, args[0],&id); if (status != napi_ok) { napi_throw_error(env, NULL, "Failed to convert argument"); return nullptr; } In this embodiment, code generation needs to handle multiple parameters and nested types (such as objects or arrays). It should be noted that the conversion logic should avoid memory leaks and ensure that resources are released correctly.

[0060] Furthermore, based on the parameter types in the function declaration information and the corresponding type mapping relationship in the implementation information, parameter parsing and type conversion logic code is generated, including: Based on the mapping relationship between the parameter types in the function declaration information and the corresponding types in the implementation information, a code segment is generated to parse the number of parameters and the parameter value array from the callback information handle; Based on the pre-defined type mapping relationship, type checking code and type conversion code are generated for each parameter in the code segment; wherein, the parameter parsing and type conversion logic code includes the code segment, the type checking code and the type conversion code, and the type conversion code is used to convert the parameter value representation in the high-level language runtime environment into the variable representation in the native programming language.

[0061] It should be noted that this embodiment automates, standardizes, and secures parameter processing logic. It transforms tedious tasks that previously relied on manual intervention by developers (such as parameter extraction, type validation, and conversion) into a systematic, automated generation process. This significantly reduces the risk of human error, improves code consistency, and ensures the reliability of cross-language calls. Its value lies not only in the improved efficiency of single code generation but also in providing a reusable parameter processing paradigm for large-scale interface development.

[0062] S33. Based on the call type in the function declaration information and the implementation information, generate native interface call logic and return result processing logic, and inject the native interface call logic and return result processing logic into the basic framework of the bridging function to obtain the bridging function code. The bridging function code is used to bridge the cross-language interface; wherein, the parameters used by the native interface call logic are native language parameters obtained by the parameter parsing and type conversion logic code.

[0063] The purpose of this step is to complete the function call loop and handle both synchronous and asynchronous scenarios. The process branches according to the call type.

[0064] Furthermore, the logic for generating the native interface call and the logic for processing the return result include: When the call type is a synchronous call, perform the following operations: Generate code that directly calls the native interface, passing in converted native language parameters when calling it; Generate code to convert the return value of the native interface to the return value type of the bridge function; In other words, when the call type is synchronous: generate code that directly calls the native interface and transform the return value.

[0065] For example, for the C++ function std::string getUser(int id), generate the calling statement and return value conversion code: std::string user = getUser(id); / / Directly call the native function napi_value napi_user; status = napi_create_string_utf8(env, user.c_str(), user.size(),&napi_user); if (status != napi_ok) { napi_throw_error(env, NULL, "Failed to convert return value"); return nullptr; } return napi_user; When the call type is an asynchronous call, perform the following operation: generate code to create an asynchronous task object; Generate asynchronous execution function code, which contains statements calling native interfaces; Generate completion callback function code, which includes logic for processing the result of asynchronous operations and resolving or rejecting asynchronous commitment objects; Generate code to submit the asynchronous task object to the execution queue.

[0066] In other words, when the call type is asynchronous: generate asynchronous task processing code, including creating an asynchronous task object, defining the execution function, and the completion callback function. For example, for an asynchronous call to `getUser`, the following logic is generated: Generate code to create asynchronous task objects: Initialize the task using `napi_create_async_work` and bind context data. Specifically, Generate asynchronous execution function code: Call native interfaces in a background thread, for example: void ExecuteFunction(napi_env env, void* data) { auto* context = static_c abstract syntax tree<AsyncContext*> (data); context->result = getUser(context->id); / / Call a C++ function } The generated callback function code: processes the result in the main thread, resolving the Promise, for example: void CompleteFunction(napi_env env, napi_status status, void* data) { auto* context = static_c abstract syntax tree<AsyncContext*> (data); napi_value napi_result; napi_create_string_utf8(env, context->result.c_str(), context->result.size(),&napi_result); napi_resolve_deferred(env, context->deferred, napi_result); / / Resolve Promise } Generate code to submit tasks to the queue: Call `napi_queue_async_work` to start the asynchronous task.

[0067] In this embodiment, asynchronous processing must ensure thread safety of the context data. It should be noted that the generated code should be optimized for performance, such as avoiding unnecessary memory copying.

[0068] like Figure 6 As shown, a specific embodiment of the bridging method for cross-language interfaces of KaihongOS described in this invention (an automatic generation scheme for NAPI bridging functions based on KaihongOS) is as follows: This embodiment uses the KaihongOS operating system as the practical environment and demonstrates how to generate NAPI bridging functions through an automated solution to address the interface bridging requirements between the application layer and the system framework layer. The specific scenario is the need to securely and efficiently connect application layer interfaces defined in the ArkTS language with system layer functions implemented in C++. The implementation process of this solution is as follows: Phase 1: Interface definition parsing.

[0069] First, the high-level language interface definition file is parsed in a structured manner to extract key metadata information. This stage uses automated tools to identify core attributes of the interface, such as function names, parameter structures, return types, and invocation methods, laying the foundation for subsequent code generation.

[0070] The system then performs a deep analysis of the native interface definition file to obtain the corresponding function signature information. The system automatically establishes a mapping relationship between the two language type systems to ensure accurate data type conversion.

[0071] Phase Two: Building the Bridge Function Framework.

[0072] Based on the parsed interface information, a basic function structure conforming to the NAPI specification is automatically created. This process generates standardized function signatures, including fundamental framework elements such as return type definitions and parameter receiving mechanisms.

[0073] During the framework construction process, the system pre-configures a complete error handling mechanism to ensure the robustness of the generated bridge functions. Simultaneously, it automatically adapts to synchronous or asynchronous call modes based on the interface characteristics.

[0074] Phase 3: Generation of parameter processing logic.

[0075] For interface parameters, the system automatically generates conversion logic from the high-level language environment to the native language. This process includes three key steps: parameter parsing, type validation, and numerical conversion, ensuring the integrity and accuracy of data during cross-language transmission.

[0076] For asynchronous interfaces, the system will intelligently generate corresponding asynchronous task management logic, including execution context maintenance, thread scheduling and callback handling mechanisms, to ensure the orderly execution of asynchronous operations.

[0077] Phase 4: Function call and return handling.

[0078] Different invocation strategies are adopted based on whether the interface is synchronous or asynchronous. For synchronous interfaces, native function call statements and return value conversion logic are generated directly; for asynchronous interfaces, complete asynchronous task lifecycle management code is generated.

[0079] During the return processing, the system automatically handles type conversion and result encapsulation to ensure that the return value conforms to the specifications of the target runtime environment. Simultaneously, it generates corresponding resource release code to avoid issues such as memory leaks.

[0080] As can be seen, this solution automates the entire process from interface definition to executable code, significantly reducing the need for manual intervention. Through a standardized workflow, the originally tedious manual coding task is transformed into a highly efficient automated generation process. The generated bridging function code exhibits high consistency and standardization, avoiding style differences and potential errors caused by manual coding. The system's built-in verification mechanism ensures that the output code conforms to the technical specifications of the target platform. Due to the use of unified generation rules and templates, subsequent code maintenance and updates become much simpler. When the interface definition changes, simply re-executing the generation process quickly yields the updated bridging function.

[0081] In summary, this embodiment demonstrates the significant benefits of the automated generation solution in real-world development scenarios. By reducing repetitive work, lowering the technical threshold, and improving code quality, this solution provides reliable technical support for operating system-level interface development. Particularly in the development of complex systems requiring extensive interface bridging, this automated solution can significantly improve development efficiency and ensure system stability. It should be noted that this technical solution is not only applicable to the specific scenario described above but can also be extended to other development environments requiring cross-language interface bridging, demonstrating broad application prospects and promotional value.

[0082] In summary, the beneficial effects of the bridging method for cross-language interfaces in KaihongOS described in this invention are as follows: The bridging method for cross-language interfaces in KaihongOS described in this invention automatically extracts key information by parsing interface definition files and native interface definition files, avoiding the time cost of manually reviewing and writing code. Pre-defined bridging rules further eliminate repetitive work.

[0083] The bridging method for cross-language interfaces in KaihongOS described in this invention automatically generates bridging function code that conforms to the target runtime environment. This bridging function code then bridges the cross-language interfaces, supporting batch parsing and code generation of numerous interface definition files. It is particularly suitable for scenarios where the system framework layer needs to expose a large number of interfaces to the application layer. Compared to traditional manual methods, this improves code generation speed and shortens project cycles.

[0084] Furthermore, such as Figure 7 As shown, based on the above-described bridging method for a cross-language interface of KaihongOS, the present invention also provides a corresponding bridging system for a cross-language interface of KaihongOS, wherein the bridging system for a cross-language interface of KaihongOS includes: The first parsing module 51 is used to parse the interface definition file and obtain the function declaration information of the target interface.

[0085] Specifically, the parsing of the interface definition file to obtain the function declaration information of the target interface includes: Lexical and syntactic analysis are performed on the interface definition file to generate an abstract syntax tree; Traverse the abstract syntax tree, identify and extract function declaration nodes, and obtain initial function declaration information based on the function declaration nodes; The initial function declaration information is converted into a standardized intermediate representation, and the data types of the intermediate representation are uniformly mapped to obtain the function declaration information, wherein the function declaration information includes the function name, parameter list, return type, and call type.

[0086] The second parsing module 52 is used to parse the native interface definition file and obtain the implementation information of the native interface corresponding to the target interface.

[0087] Specifically, parsing the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface includes: The native interface definition file is preprocessed, the header file content of the preprocessed native interface definition file is parsed, and macro definitions and conditional compilation directives are ignored to obtain the syntax tree information of function declarations; Extract the function signature of the native interface corresponding to the target interface from the syntax tree information. The function signature includes the function name, return value type, parameter type list and parameter order. Based on the function signature, a mapping table is established from the native programming language type to the native application interface type, and the mapping table serves as the implementation information of the native interface.

[0088] The code generation module 53 is used to automatically generate bridging function code that conforms to the target runtime environment based on the function declaration information and the implementation information, according to preset bridging rules, and to bridge the cross-language interface through the bridging function code.

[0089] Specifically, the step of automatically generating bridging function code that conforms to the target runtime environment based on the function declaration information and the implementation information, according to preset bridging rules, and bridging the cross-language interface through the bridging function code includes: Based on the function name in the function declaration information, a basic framework for bridging functions that conforms to the target runtime environment specifications is created. The basic framework includes standardized function signatures and error handling mechanisms. Based on the parameter type mapping relationship between the function declaration information and the corresponding type in the implementation information, parameter parsing and type conversion logic code is generated and injected into the basic framework of the bridge function. The parameter parsing and type conversion logic code is used to convert the parameters described in the high-level language into parameters that can be recognized by the native programming language. Based on the call type in the function declaration information and the implementation information, native interface call logic and return result processing logic are generated, and the native interface call logic and return result processing logic are injected into the basic framework of the bridge function to obtain the bridge function code; wherein, the parameters used by the native interface call logic are native language parameters obtained by the parameter parsing and type conversion logic code.

[0090] Furthermore, based on the parameter types in the function declaration information and the corresponding type mapping relationship in the implementation information, parameter parsing and type conversion logic code is generated, including: Based on the mapping relationship between the parameter types in the function declaration information and the corresponding types in the implementation information, a code segment is generated to parse the number of parameters and the parameter value array from the callback information handle; Based on the pre-defined type mapping relationship, type checking code and type conversion code are generated for each parameter in the code segment; wherein, the parameter parsing and type conversion logic code includes the code segment, the type checking code and the type conversion code, and the type conversion code is used to convert the parameter value representation in the high-level language runtime environment into the variable representation in the native programming language.

[0091] Furthermore, the native interface call logic and return result processing logic are generated, including: When the call type is a synchronous call, perform the following operations: Generate code that directly calls the native interface, passing in converted native language parameters when calling it; Generate code to convert the return value of the native interface to the return value type of the bridge function; When the call type is an asynchronous call, perform the following operation: generate code to create an asynchronous task object; Generate asynchronous execution function code, which contains statements calling native interfaces; Generate completion callback function code, which includes logic for processing the result of asynchronous operations and resolving or rejecting asynchronous commitment objects; Generate code to submit the asynchronous task object to the execution queue.

[0092] The beneficial effects of the bridging system for the cross-language interface of KaihongOS described in this invention are as follows: The bridging system for cross-language interfaces in KaihongOS described in this invention automatically extracts key information by parsing interface definition files and native interface definition files, avoiding the time cost of manually reviewing and writing code. Pre-defined bridging rules further eliminate repetitive work.

[0093] The cross-language interface bridging system for KaihongOS described in this invention automatically generates bridging function code that conforms to the target runtime environment. This bridging function code then bridges the cross-language interfaces, supporting batch parsing and code generation of numerous interface definition files. It is particularly suitable for scenarios where the system framework layer needs to expose a large number of interfaces to the application layer. Compared to traditional manual methods, this improves code generation speed and shortens the development cycle of cross-language interface bridging projects.

[0094] Furthermore, such as Figure 8 As shown, based on the bridging method and system for the cross-language interface of KaihongOS described above, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 8 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0095] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard disk or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as the program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores a bridging program 40 for a cross-language interface of KaihongOS, which can be executed by the processor 10 to implement the bridging method for the cross-language interface of KaihongOS in this application.

[0096] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the bridging method for the cross-language interface of KaihongOS.

[0097] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The components of the terminal communicate with each other via a system bus.

[0098] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a bridging program for a cross-language interface for KaihongOS, which, when executed by a processor, implements the steps of the bridging method for a cross-language interface for KaihongOS as described above.

[0099] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0100] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0101] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.< / t> < / string> < / string> < / string> < / string>

Claims

1. A bridging method for a cross-language interface in KaihongOS, characterized in that, The bridging method for the cross-language interface of KaihongOS includes: Parse the interface definition file to obtain the function declaration information of the target interface; Parse the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface; Based on the function declaration information and the implementation information, and according to the preset bridging rules, bridging function code that conforms to the target runtime environment is automatically generated, and the cross-language interface is bridged through the bridging function code.

2. The bridging method for a cross-language interface for KaihongOS according to claim 1, characterized in that, The parsing of the interface definition file yields the function declaration information of the target interface, including: Lexical and syntactic analysis are performed on the interface definition file to generate an abstract syntax tree; Traverse the abstract syntax tree, identify and extract function declaration nodes, and obtain initial function declaration information based on the function declaration nodes; The initial function declaration information is converted into a standardized intermediate representation, and the data types of the intermediate representation are uniformly mapped to obtain the function declaration information, wherein the function declaration information includes the function name, parameter list, return type, and call type.

3. The bridging method for a cross-language interface for KaihongOS according to claim 2, characterized in that, The process of parsing the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface includes: The native interface definition file is preprocessed, the header file content of the preprocessed native interface definition file is parsed, and macro definitions and conditional compilation directives are ignored to obtain the syntax tree information of function declarations; Extract the function signature of the native interface corresponding to the target interface from the syntax tree information, wherein the function signature includes the function name, return value type, parameter type list and parameter order; Based on the function signature, a mapping table is established from the native programming language type to the native application interface type, and the mapping table is used as the implementation information of the native interface.

4. The bridging method for a cross-language interface for KaihongOS according to claim 3, characterized in that, Based on the function declaration information and the implementation information, and according to preset bridging rules, the system automatically generates bridging function code that conforms to the target runtime environment. This bridging function code is then used to bridge cross-language interfaces, including: Based on the function name in the function declaration information, a basic framework for bridging functions that conforms to the target runtime environment specifications is created. The basic framework includes standardized function signatures and error handling mechanisms. Based on the parameter type mapping relationship between the function declaration information and the corresponding type in the implementation information, parameter parsing and type conversion logic code is generated and injected into the basic framework of the bridge function. The parameter parsing and type conversion logic code is used to convert parameters described in the high-level language into parameters that can be recognized by the native programming language. Based on the call type in the function declaration information and the implementation information, native interface call logic and return result processing logic are generated, and the native interface call logic and return result processing logic are injected into the basic framework of the bridge function to obtain the bridge function code. The parameters used by the native interface call logic are native language parameters obtained by the parameter parsing and type conversion logic code.

5. The bridging method for a cross-language interface for KaihongOS according to claim 4, characterized in that, The basic framework for creating bridge functions that conform to the target runtime environment specifications includes: Generate the corresponding bridge function name based on the function name of the target interface; Construct a bridge function signature that returns a specific type and takes a runtime environment handle and a callback information handle as input parameters; Inside the bridging function, declare state variables used to record and check the state of application interface calls.

6. The bridging method for a cross-language interface for KaihongOS according to claim 5, characterized in that, Based on the parameter types in the function declaration information and the corresponding type mapping relationship in the implementation information, parameter parsing and type conversion logic code is generated, including: Based on the mapping relationship between the parameter types in the function declaration information and the corresponding types in the implementation information, a code segment is generated to parse the number of parameters and the parameter value array from the callback information handle; Based on the pre-defined type mapping relationship, type checking code and type conversion code are generated for each parameter in the code segment; The parameter parsing and type conversion logic code includes the code segment, the type checking code, and the type conversion code. The type conversion code is used to convert the parameter value representation in the high-level language runtime environment into the variable representation in the native programming language.

7. The bridging method for a cross-language interface for KaihongOS according to claim 4, characterized in that, The logic for generating native interface calls and the logic for processing return results include: When the call type is a synchronous call, perform the following operations: Generate code that directly calls the native interface, passing in converted native language parameters when calling it; Generate code to convert the return value of the native interface to the return value type of the bridge function; When the call type is an asynchronous call, perform the following operations: Generate code to create asynchronous task objects; Generate asynchronous execution function code, which contains statements calling native interfaces; Generate completion callback function code, wherein the completion callback function code includes logic for processing the result of asynchronous operation and resolving or rejecting asynchronous commitment objects; Generate code to submit the asynchronous task object to the execution queue.

8. A bridging system for a cross-language interface of KaihongOS, characterized in that, The bridging system for the cross-language interface of KaihongOS includes: The first parsing module is used to parse the interface definition file and obtain the function declaration information of the target interface; The second parsing module is used to parse the native interface definition file to obtain the implementation information of the native interface corresponding to the target interface; The code generation module is used to automatically generate bridging function code that conforms to the target runtime environment based on the function declaration information and the implementation information, according to preset bridging rules, and to bridge the cross-language interface through the bridging function code.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and a bridging program for a cross-language interface for KaihongOS stored in the memory and executable on the processor. When the bridging program for the cross-language interface for KaihongOS is executed by the processor, it implements the steps of the bridging method for the cross-language interface for KaihongOS as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a bridging program for a cross-language interface for KaihongOS, which, when executed by a processor, implements the steps of the bridging method for a cross-language interface for KaihongOS as described in any one of claims 1-7.

Images