A cross-end plug-in code generation method, device, equipment and medium

Abstract

The application discloses a cross-terminal plug-in code generation method, device and equipment and a medium. The cross-terminal plug-in code generation method comprises the following steps: acquiring a declarative domain-specific language (DSL) file, wherein the DSL file is used for describing plug-in capability semantics; parsing the DSL file, generating a cross-terminal interface model based on the parsing result, wherein the cross-terminal interface model comprises interface definition information which is composed of method definition, type definition, event definition, component attribute, component command and platform support range information; and generating interface implementation code for at least two target platforms and structured description information required for code generation based on the interface definition information in the cross-terminal interface model. The technical scheme of the embodiment of the application can reduce the manual synchronization cost and the risk of missing configuration in the development of the cross-terminal plug-in.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for generating cross-platform plug-in code. Background Technology

[0002] In cross-platform application development, the same plugin capability requires corresponding call entry points, native bridges, and type definitions to be implemented on the cross-platform rendering side, the mobile web side, and each native platform side. Currently, developers typically maintain these interface declarations and implementations manually in the code of each platform, which can easily lead to inconsistencies in method names, parameter types, return value structures, and event definitions for the same capability across multiple platforms.

[0003] The cross-platform framework's automatic interface code generation tool can generate some interface artifacts based on the declaration file. However, this declaration file and the manually written glue code for each platform are maintained independently, lacking a unified source constraint. This can easily lead to mismatches between the automatically generated interface artifacts and those from other platforms. When adding or modifying plugin capabilities, adjustments need to be made simultaneously in the multi-platform code, the interface generation tool's configuration, and the plugin shell configuration. This results in high manual synchronization costs and difficulty in controlling the mismatch rate. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for generating cross-platform plugin code, in order to solve the problem of inconsistencies between multiple platforms that are easily caused by maintaining plugin code separately for each platform.

[0005] According to one aspect of the present invention, a method for generating cross-platform plugin code is provided, comprising: Obtain a declarative domain-specific language (DSL) file, which describes the semantics of plugin capabilities; The DSL file is parsed, and a cross-platform interface model is generated based on the parsing results. The cross-platform interface model includes interface definition information consisting of method definitions, type definitions, event definitions, component attributes, component commands, and platform support scope information. Based on the interface definition information in the cross-platform interface model, generate interface implementation code for at least two target platforms and the structured description information required for code generation.

[0006] According to another aspect of the present invention, a cross-platform plugin code generation system is provided, comprising: The DSL file acquisition module is used to acquire a declarative domain-specific language DSL file, which is used to describe the semantics of plug-in capabilities. A cross-platform interface model generation module is used to parse the DSL file and generate a cross-platform interface model based on the parsing results. The cross-platform interface model includes interface definition information consisting of method definitions, type definitions, event definitions, component attributes, component commands, and platform support scope information. The plugin code generation module is used to generate interface implementation code and structured description information required for code generation for at least two target platforms based on the interface definition information in the cross-platform interface model.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the cross-platform plug-in code generation method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the cross-platform plug-in code generation method according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is provided, including a computer program that, when executed by a processor, implements the cross-platform plug-in code generation method of any embodiment of the present invention.

[0010] The technical solution of this invention obtains a declarative DSL file and parses it to generate a cross-platform interface model. This model contains all interface information, including method signatures, type definitions, event definitions, component attributes, component commands, and platform support scope. Then, based on the cross-platform interface model, it extracts interface definition information and drives the automatic generation of multi-platform glue code and structured description files. This achieves the same-source derivation of interface definitions and multi-platform implementation products, eliminates the problem of inconsistent method signatures, types, and event definitions caused by manual maintenance on each platform, and reduces the manual synchronization cost and the risk of missing configuration in cross-platform plugin development.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a cross-platform plugin code generation method provided in Embodiment 1 of the present invention; Figure 2a This is a flowchart of a cross-platform plugin code generation method provided in Embodiment 2 of the present invention; Figure 2b This is a flowchart illustrating the plug-in code generation method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of a cross-platform plugin code generation device according to Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the cross-platform plugin code generation method of this invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1This is a flowchart illustrating a cross-platform plugin code generation method according to Embodiment 1 of the present invention. This embodiment is applicable to situations where a cross-platform interface model is generated by parsing a DSL, and multiple platform interface implementation codes are generated based on the cross-platform interface model. This method can be executed by a cross-platform plugin code generation device, which can be implemented in hardware and / or software and can be configured in various general-purpose computing devices. Figure 1 As shown, the method includes: S110. Obtain a declarative domain-specific language (DSL) file, which is used to describe the semantics of plug-in capabilities.

[0017] A declarative Domain-Specific Language (DSL) file is a structured declarative file defined to describe the semantics of cross-platform plugin capabilities. A DSL file is not directly equivalent to the program code for a specific target platform; it does not contain any platform-specific implementation details, but rather declaratively describes the capabilities of the plugin. DSL files use a structured data format to describe the complete semantic information of the plugin's capabilities. For example, DSL files may use JSON, YAML, or a custom DSL syntax data format.

[0018] In this embodiment of the invention, the DSL file is first obtained. Specifically, it can be read from a pre-written DSL file at a set storage address, or it can be obtained from a DSL file submitted by the user through a visual configuration interface. The DSL file may contain declarations of module name, plugin type, method definition, parameter definition, return value definition, event definition, type alias, enumeration definition, component attributes, component commands, platform support scope, and long task flag information.

[0019] After obtaining the DSL file, lexical analysis and syntax checking are performed on it to ensure that the DSL file is structurally complete and conforms to the preset DSL syntax rules, so as to provide structurally correct input for subsequent parsing steps.

[0020] By describing plugin capabilities using a declarative DSL rather than platform-specific code, the declaration of plugin capabilities can be decoupled from platform implementation, serving as the information basis for subsequent unified parsing and automatic generation of multi-platform code.

[0021] S120. Parse the DSL file and generate a cross-platform interface model based on the parsing results. The cross-platform interface model contains interface definition information consisting of method definitions, type definitions, event definitions, component attributes, component commands, and platform support scope information.

[0022] A cross-platform interface model refers to an intermediate representation obtained by structuring and organizing the plugin capability information declared in the DSL file. The cross-platform interface model is a neutral data structure decoupled from the code implementation of each platform. It carries information including method definitions (method name, parameter list and types, return type), type definitions (type aliases, enumeration definitions), event definitions (event name and its data structure), component attribute definitions, component command definitions, and platform support scope information. All of the above information collectively constitutes the interface definition information of the cross-platform interface model.

[0023] Unlike the raw text form of DSL files, the cross-platform interface model is obtained by classifying, integrating, and structuring the declared information in the DSL according to a predefined interface description specification. The cross-platform interface model is not directly equivalent to the code implementation details of any target platform. Its role is to serve as the sole source of facts for all subsequent code generation steps, ensuring that the interface information on which multi-platform code generation is based is completely consistent.

[0024] In this embodiment of the invention, the DSL file is first parsed to extract the declared module name, plugin type, method definition, parameter definition, return value definition, event definition, type alias definition, enumeration definition, component attribute definition, component command definition, platform support scope, and long task marker information. For declarations where the plugin type is a rendering component, the corresponding component attribute definition and component command definition information are extracted.

[0025] Furthermore, the extracted information is categorized and integrated according to a predefined interface description specification, establishing relationships between the various pieces of information. For example, method definitions are associated with their respective modules, parameter definitions with their respective methods, event definitions with the module or component that triggered the event, component attribute definitions and component command definitions with their respective components, and long-task markers with their corresponding method definitions. After integration, this information is generated into a cross-platform interface model with a cross-platform independent intermediate representation.

[0026] By generating a cross-platform interface model, the various information declared in the DSL are integrated into a structured unified interface model, providing a unique source of facts for the subsequent generation of multi-platform code and structured description files. This fundamentally avoids the inconsistencies in method signatures, type definitions, event definitions, and other information caused by manual maintenance across multiple platforms.

[0027] S130. Based on the interface definition information in the cross-platform interface model, generate interface implementation code for at least two target platforms and the structured description information required for code generation.

[0028] Interface implementation code refers to the entry point code, glue code, and bridging template code on each target platform side. Its function is to enable the plugin capabilities to be correctly invoked on different platforms. The structured description information required for code generation refers to the intermediate description files, such as schema files, that are recognized by cross-platform framework interface automatic generation tools. These files drive the automatic generation tools to produce the underlying interface binding code required by the framework.

[0029] The interface definition information (including method definitions, type definitions, event definitions, component properties, component commands, and platform support scope information) in the cross-platform interface model is used as the sole input source. Each generation step reads the interface facts from the cross-platform interface model without introducing new method signatures or new platform scopes.

[0030] In this embodiment of the invention, the interface definition information in the cross-platform interface model is read, and the following generation operations are performed in parallel or sequentially: for the cross-platform rendering side and the mobile webpage side, the method definition, event definition, type definition, component attribute definition, component command definition and platform support range information in the model are read, and glue code for the cross-platform rendering side and the mobile webpage side is generated respectively.

[0031] The mobile webpage side generates method declaration code and type definition code for developers to populate with business logic; the cross-platform rendering side generates entry point code, which is used to call the business logic populated by the developer in the glue code on the mobile webpage side. Each side's glue code includes entry point code, type definition code, event subscription code, bridging wrapper code, and component wrapper code.

[0032] For each native platform, the platform support scope information and method definitions are read from the model. Based on the platform support scope information, the methods supported by each native platform are determined. According to the respective bridging interface specifications of each native platform, corresponding bridging template code is generated, including parameter conversion code, method forwarding code, event callback code, and component command template code. The bridging template code for each native platform follows the interface specifications and programming language characteristics of its respective platform.

[0033] For structured description information, the cross-platform interface model is converted into a structured description file that can be recognized by the cross-platform framework interface automatic generation tool, and the file is used as input to the automatic generation tool to trigger the tool to generate the interface artifacts required by the framework.

[0034] Through the above generation operations, with the cross-platform interface model as the sole input source, the interface implementation code and structured description information required by each target platform are generated. This allows the multi-platform interface implementation to be generated driven by the same source of fact, eliminating the need for manual maintenance of interface definitions on multiple platforms simultaneously. This reduces development costs and avoids the risks of missing configurations and errors.

[0035] The technical solution of this invention obtains a declarative DSL file and parses it to generate a cross-platform interface model. This model contains all interface information, including method signatures, type definitions, event definitions, component attributes, component commands, and platform support scope. Then, based on the cross-platform interface model, it extracts interface definition information and drives the automatic generation of multi-platform glue code and structured description files. This achieves the same-source derivation of interface definitions and multi-platform implementation products, eliminates the problem of inconsistent method signatures, types, and event definitions caused by manual maintenance on each platform, and reduces the manual synchronization cost and the risk of missing configuration in cross-platform plugin development.

[0036] Example 2 Figure 2a This is a flowchart of a cross-platform plugin code generation method provided in Embodiment 2 of the present invention. This embodiment further refines the above embodiment, providing specific steps for parsing the DSL file, generating a cross-platform interface model based on the parsing results, and generating interface implementation code for at least two target platforms and structured description information required for code generation based on the interface definition information in the cross-platform interface model. Figure 2a As shown, the method includes: S210. Obtain the declarative domain-specific language (DSL) file, which describes the semantics of plugin capabilities.

[0037] S220. Parse the DSL file and extract the module name, plugin type, method definition, parameter definition, return value definition, event definition, type alias definition, enumeration definition, component property definition, component command definition, platform support scope, and long task marker information declared in the DSL file. Among them, the plugin type includes native module type and rendering component type.

[0038] In this embodiment of the invention, the plugin code generation process is as follows: Figure 2b As shown, the DSL file is first read and parsed according to the DSL syntax rules. During the parsing process, the module name, plugin type, method definition, parameter definition, return value definition, event definition, type alias definition, enumeration definition, component property definition, component command definition, platform support scope, and long task flag information declared in the DSL file are extracted item by item according to the DSL structure. Among them, the plugin type includes native module type and rendering component type.

[0039] Optionally, before parsing the DSL file, the following steps are also included: The DSL file is subjected to field integrity checks, type mapping checks, naming conflict checks, platform tag validity checks, event definition validity checks, and component command validity checks. If the checks fail, the subsequent steps are terminated.

[0040] S230. The extracted information is integrated according to the preset interface description specification, the relationship between the information is established, and a cross-end interface model in intermediate representation form is generated based on the integrated information.

[0041] The cross-platform interface model contains interface definition information consisting of method definitions, type definitions, event definitions, component properties, component commands, and platform support scope information.

[0042] The extracted module names, plugin types, method definitions, parameter definitions, return value definitions, event definitions, type alias definitions, enumeration definitions, component attribute definitions, component command definitions, platform support scope, and long task flags are categorized and integrated according to a predefined interface description specification. This specification defines the standard organization format for each type of information; for example, method definitions use the structure "method name + parameter list + return value type," event definitions use "event name + data type," and component attribute definitions use "attribute name + attribute type + default value." Through the constraints of this interface description specification, the declaration information of different plugins and modules is organized into a consistent, structured format.

[0043] After classification and integration, the relationships between various pieces of information are established. These relationships can include the affiliation between a method definition and its module, the dependency between a parameter definition and its method definition, the affiliation between an event definition and its module or component, the affiliation between component attribute definitions / command definitions and their rendering components, the relationship between long task marker information and its corresponding method definition, and the correspondence between platform support scope information and each method definition, event definition, component attribute definition, and component command definition. These relationships are used for conditional filtering when generating platform artifacts later.

[0044] Through the above integration and model generation operations, the various information declared in the DSL are transformed into a well-structured and clearly related cross-platform interface model. This cross-platform interface model serves as the sole source of fact for all subsequent code generation steps. Each subsequent generation step reads the interface definition information from this model, avoiding inconsistencies in method signatures, type definitions, event definitions, and other information caused by manual maintenance across multiple platforms.

[0045] S240: Read the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information in the cross-platform interface model, and generate glue code for the cross-platform rendering side and the mobile webpage side. The glue code includes call entry code, type definition code, event subscription code, bridging wrapper code, and component wrapper code.

[0046] In this embodiment of the invention, the method definition, event definition, type definition, component attribute definition, component command definition and platform support range information in the cross-platform interface model are read to generate glue code for both the cross-platform rendering side and the mobile webpage side.

[0047] Specifically, the system first reads method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information from the cross-platform interface model. Then, based on the platform support scope information, it determines the availability of each method, event, and component capability on the cross-platform rendering side and the mobile webpage side. If a method is unavailable on the cross-platform rendering side or the mobile webpage side, the corresponding side will not generate the entry code for that method, or will generate a runtime exception message that says "platform not supported".

[0048] In a specific example, based on the method name, parameter list, and return type in the method definition, call entry functions for both the cross-platform rendering side and the mobile web side are generated. These functions encapsulate cross-platform communication call logic, serialize the call request, send it to the native side, and receive the return result. Based on the type definitions (including type alias definitions and enumeration definitions), type declaration code for both the cross-platform rendering side and the mobile web side is generated for the call entry code to reference, providing type checking and code completion support. Based on the event definitions, utility functions for event subscription and unsubscription are generated, encapsulating the registration and removal logic for event listeners in cross-platform communication. Based on the method and event definitions, wrapper code for the cross-platform communication bridge layer is generated to convert the function call from the call entry point into the underlying cross-platform communication protocol format and deserialize the return result into a type-safe return value object. When the plugin type in the cross-platform interface model is a rendering component type, the component attribute definition and component command definition are read to generate component wrapper code for both the cross-platform rendering side and the mobile web side, encapsulating the native rendering component into a component class recognizable by each side's UI framework. Through the above generation operations, a complete plugin call interface encapsulation is provided for the cross-platform rendering side and the mobile web side, so that the upper-layer business does not need to care about the underlying cross-platform communication details to call the plugin capabilities.

[0049] Optionally, the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information in the cross-platform interface model are read to generate glue code for both the cross-platform rendering side and the mobile webpage side, including: Read the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information in the cross-platform interface model, and determine the methods, events, and component capabilities supported by each target platform based on the platform support scope information; Generate glue code for mobile web pages, wherein the mobile web page glue code includes method declaration code and type definition code for developers to fill in business logic; The mobile webpage glue code is used as a proxy layer for the cross-platform rendering side to generate entry code for the cross-platform rendering side; the entry code is used to call the business logic filled in by the developer in the mobile webpage glue code.

[0050] In this optional embodiment, a specific method is provided for reading method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information from the cross-platform interface model to generate glue code for both the cross-platform rendering side and the mobile webpage side: First, the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information are read from the cross-platform interface model. The platform support scope information indicates the set of target platforms supported by each method, event, component attribute, or component command. Based on the read platform support scope information, platform availability is marked for each method, event, component attribute, and component command. For the cross-platform rendering side, the available methods, events, and component capabilities are marked; for the mobile webpage side, the available methods, events, and component capabilities are marked; for each native platform side, the methods, events, and component capabilities supported by each native platform are marked.

[0051] Based on the annotated methods, events, and component capabilities available on the mobile webpage, a glue code file for the mobile webpage is generated. This glue code includes method declaration code and type definition code. The type definition code maintains strict consistency with the type definitions in the cross-platform interface model.

[0052] Based on the annotated methods, events, and component capabilities available on the cross-platform rendering side, a cross-platform rendering entry point code file is generated. Unlike the mobile web-side glue code, the cross-platform rendering entry point code does not contain a method body framework that requires developers to fill in business logic; instead, it generates an entry function that directly calls the mobile web-side glue code. The signature (method name, parameter list, return type) of the cross-platform rendering entry function is consistent with the method declaration in the mobile web-side glue code. For plugins that render component types, component entry point code is generated for the cross-platform rendering side, making the mobile web-side glue code a proxy layer for the cross-platform rendering side. The cross-platform rendering side operates on the component instances filled in by the developer on the mobile web side through this entry point code.

[0053] Through the above generation process, the cross-platform rendering side does not need to carry any business logic implementation. It only forwards the call request to the mobile web page proxy layer through a lightweight call entry point, and the mobile web page side completes the execution of the actual business logic. This architecture design minimizes the amount of code on the cross-platform rendering side and eliminates the need to maintain independent business implementations on the cross-platform rendering side.

[0054] By reading the platform support scope information in the cross-platform interface model, the capabilities supported by each target platform are determined. Glue code containing method declarations and type definitions for developers to populate with business logic is generated for the mobile web side. This mobile web side glue code serves as a proxy layer for the cross-platform rendering side, generating the entry point code. The mobile web side, acting as the proxy layer, carries the complete business logic declaration and implementation framework, while the cross-platform rendering side only generates a lightweight entry point. The cross-platform rendering side does not need to repeatedly implement the business logic, reducing its code size and maintenance burden. Furthermore, developers only need to populate the business logic once in the mobile web side glue code, and the cross-platform rendering side can reuse this implementation through the entry point, reducing repetitive work in cross-platform plugin development.

[0055] S250: Read the platform support scope information and method definitions in the cross-platform interface model, and generate at least one native platform-side bridging template code. The bridging template code includes parameter conversion code, method forwarding code, event callback code, and component command template code.

[0056] In this embodiment of the invention, platform support scope information and method definitions in the cross-platform interface model are read to generate at least one bridging template code on the native platform side. The bridging template code is a code framework on the native platform side used to receive cross-platform call requests, execute native implementations, and return results. Its function is to route cross-platform call requests to the specific implementation logic on the native platform side.

[0057] Specifically, the platform support scope information and method definitions are first read from the cross-platform interface model. Based on the platform support scope information, the target native offset is determined, and bridging template code is generated for the target native platform. For each target native platform to be generated, the method definitions supported by that native platform are read, and the corresponding bridging template code is generated according to the bridging interface specification of that native platform.

[0058] In a specific example, based on the parameter type information in the method definition, code is generated to convert the parameters transmitted in cross-platform communication into native platform type objects, including type validation and type conversion logic. Based on the method definition, code is generated for each method to forward the call request to the specific implementation class of the native platform, pass the converted parameters to the corresponding method of the native implementation class, and receive the return value. Based on the event definition, callback code is generated for each event to trigger the event on the native platform side, encapsulating the event data generated on the native side into a format recognizable by the cross-platform communication protocol and sending it to the cross-platform rendering side or mobile web side through the cross-platform communication channel. When the plugin type in the cross-platform interface model is a rendering component type, template code is generated based on the component command definition to receive and execute component commands on the native platform side, routing the component commands sent by the cross-platform side to the corresponding method of the native rendering component. Through the above generation operations, a bridging template code framework that can be directly populated with business logic is generated for each native platform. Developers only need to fill in the platform-related specific implementation in the specified location of the template code, without having to manually write the cross-platform communication protocol processing logic.

[0059] S260. Convert the cross-platform interface model into a structured description file that can be recognized by the cross-platform framework interface automatic generation tool.

[0060] In this embodiment of the invention, the cross-platform interface model is converted into a structured description file that can be recognized by the cross-platform framework interface automatic generation tool. The structured description file is a data file organized according to the format specified by the cross-platform framework interface automatic generation tool, and its function is to serve as input to the tool, driving it to generate interface binding code at the framework level.

[0061] Specifically, the process first obtains the input format specifications required by the cross-platform framework interface automatic generation tool. Then, based on these specifications, all interface definition information (including method definitions, type definitions, event definitions, component attribute definitions, component command definitions, and platform support scope information) carried in the cross-platform interface model is mapped and converted into a structured description file conforming to the specified format. This conversion process only involves format adaptation and does not introduce new method signatures, type definitions, or platform support scope information. The method names, parameter types, return value types, event names, component attributes, component commands, and platform support scope information described in the structured description file are all consistent with their corresponding information in the cross-platform interface model.

[0062] After the conversion, the generated structured description file is used as input to the cross-platform framework interface automatic generation tool, triggering the tool to generate the interface artifacts required by the framework. Through the above conversion operation, the cross-platform framework interface automatic generation tool is incorporated into the code generation chain with the cross-platform interface model as the sole source of fact. The interface artifacts it generates are driven by the same interface model as other platform artifacts, eliminating the need to maintain an independent set of interface definitions.

[0063] Optionally, after generating interface implementation code for at least two target platforms and the structured description information required for code generation, the following may also be included: Obtain the plugin manifest and plugin lock file. Based on the plugin manifest and plugin lock file, generate the plugin shell's dependency configuration, build configuration, and native registration code as the plugin shell's registration artifacts. Based on the cross-platform interface model, plugin manifest, and plugin locking file, a structured capability manifest is generated; A consistency check is performed between the capability list and the registered artifacts of the plugin shell. If the consistency check fails, subsequent build or release operations are blocked.

[0064] In this optional embodiment, specific steps are provided after generating interface implementation code for at least two target platforms and the structured description information required for code generation: obtaining a plugin manifest and a plugin locking file; generating the plugin shell's dependency configuration, build configuration, and native registration code based on the plugin manifest and plugin locking file, as the registration artifacts of the plugin shell. The plugin manifest is used to determine the list of plugins to be included in the running shell, and the plugin locking file is used to record the version information, source information, and integration status of each plugin.

[0065] Specifically, the process begins by obtaining the plugin manifest and plugin lock file. Based on the manifest, the list of plugins to be included is determined, and based on the lock file, the version and source information of each plugin is obtained. Next, the identifier and version information of each plugin are written into the dependency configuration file according to the format required by the package management tool. The compilation path and compilation options of each plugin module are written into the build configuration file. Finally, a corresponding registration class (such as TurboPackage, FabricPackage) and its registration and calling code in the PluginRegistry are generated for each plugin.

[0066] The plugin manifest file is generated by retrieving a list of required plugin identifiers from the plugin manifest, obtaining version information for each plugin from the plugin locking file, and extracting corresponding interface definition information (including method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information) from the cross-platform interface model. This information is then organized according to a preset data format to generate a structured capability manifest file. The interface signature (module, method, event, type, and platform scope) for each capability in the capability manifest file originates from the cross-platform interface model, while the version information comes from the plugin locking file.

[0067] Furthermore, a consistency check is performed between the capability list and the registered artifacts of the plugin shell. If the consistency check fails, subsequent build or release operations are blocked. The consistency check operation may include verifying whether the capability items in the structured capability list and the plugin shell are consistent, whether the supported platform range is consistent, and whether the version information is consistent.

[0068] By generating the registration artifact of the plugin shell based on the plugin manifest and lock file, generating a structured capability manifest based on the cross-platform interface model, plugin manifest and lock file, and performing consistency checks on the capability manifest and registration artifact, the build or release is blocked when the check fails. This enables the integration configuration of the plugin shell to be automatically derived from the manifest and lock file without manual writing, and the consistency check prevents semi-finished products with inconsistent capability manifest and shell registration status from entering the release chain.

[0069] Optionally, a consistency check is performed between the capability list and the registered artifacts of the plugin shell. If the consistency check fails, subsequent build or release operations are blocked, including: The structured capability list contains capability items that are not registered in the registered product of the plug-in shell; The detection shows that the registered product of the plug-in shell contains capability items that are missing from the structured capability list; Check whether the range of supported platforms recorded in the structured capability list is consistent with the range of supported platforms actually registered in the registered product of the plug-in shell; Check whether the version information recorded in the plugin lock file is consistent with the version information recorded in the structured capability list; If any of the tests fails, the consistency test is considered to have failed, and subsequent build or release operations are blocked.

[0070] In this optional embodiment, the following steps are provided for performing a consistency check on the capability list and the registered artifacts of the plugin shell, and blocking subsequent build or release operations if the consistency check fails: Detecting capability items that exist in the structured capability list but are not registered in the plugin shell's registered artifacts: Specifically, traversing each capability in the capability list and searching for the corresponding registration code in the registered artifacts. Detecting capability items that exist in the plugin shell's registered artifacts but are missing from the structured capability list: Specifically, traversing each registered capability in the registered artifacts and searching for the corresponding declaration item in the capability list. Detecting whether the platform support scope recorded in the structured capability list is consistent with the actual platform support scope registered in the plugin shell's registered artifacts: Specifically, comparing the platform support scope declared in the list for each capability with the actual platform scope registered in the registered artifacts. Detecting whether the version information recorded in the plugin lock file is consistent with the version information recorded in the structured capability list.

[0071] If any of the above checks result in a mismatch, the consistency check is deemed a failure, an error message is output, and subsequent build or release operations are blocked. If all consistency checks pass, subsequent build or release operations are allowed to continue. Performing consistency checks on the capability list and registered artifacts, and blocking builds or releases when checks fail, can prevent semi-finished products with inconsistent capability lists and actual shell registration status from entering the release chain, thus improving the controllability of delivery quality.

[0072] Optional, also includes: Identify methods marked as long tasks from the cross-platform interface model, and generate a unique task identifier for each call of the identified long task method; A task object is generated on both the cross-platform rendering side and the mobile webpage side. The task object includes a cancel method, a pause method, a resume method, a status query method, and a progress event binding interface. On the native platform side, a task management mapping is generated with the task identifier as the key, and the sending and receiving of progress events, cancellation methods, pause methods, resumption methods, and status query methods are all bound to the same task identifier.

[0073] In this optional embodiment, the method definition is further included: traversing the method definitions in the cross-platform interface model to determine whether each method definition is associated with long task marker information. For methods carrying long task markers, they are identified as long task methods. When the upper-layer business calls the long task method, a unique task identifier is generated before the call is executed.

[0074] For each identified long task method, a corresponding task object class is generated when generating glue code for both the cross-platform rendering side and the mobile webpage side. This task object includes: a cancel method to send a command to the native side to cancel the current task; a pause method to send a command to pause the current task; a resume method to send a command to resume a paused task; a status query method to query the execution status of the current task from the native side; and a progress event binding interface to register progress event listener callback functions and receive progress data sent from the native side. Each of these method calls carries the generated task identifier. When generating bridging template code for each native platform, the declaration and operation code for the long task management map are generated. When a long task is created, the task instance is stored in the map using the task identifier as the key; when the task is completed or canceled, it is removed from the map.

[0075] In addition, all communication and operations related to long tasks are bound to the same task identifier. Progress events are sent to the cross-platform side using the task identifier as the event identifier, and the cross-platform side routes them to the corresponding task object based on the task identifier. Control commands such as cancel, pause, resume, and status query invoked by the cross-platform side all carry the task identifier. After receiving them, the native side uses this identifier to find the corresponding task instance in the mapping and executes the operation. Through the above binding operation, a one-to-one correspondence is established between the task object on the cross-platform side and the task actually executed on the native side through the same task identifier.

[0076] By generating a unique task identifier for each long-running task, a task object containing control methods and progress event binding interfaces is generated on the cross-platform side, and a task management mapping with the task identifier as the key is generated on the native side. The progress events and control methods are all bound to the same task identifier, realizing a one-to-one correspondence between the cross-platform task object and the native task entity. This allows control operations such as cancellation, pause, resume, status query, and progress monitoring to be accurately routed to the correct native task instance without requiring developers to implement them separately on multiple platforms.

[0077] The technical solution of this invention obtains a declarative DSL file and parses it to generate a cross-platform interface model. This model contains all interface information, including method signatures, type definitions, event definitions, component attributes, component commands, and platform support scope. Then, based on the cross-platform interface model, it extracts interface definition information and drives the automatic generation of multi-platform glue code and structured description files. This achieves the same-source derivation of interface definitions and multi-platform implementation products, eliminates the problem of inconsistent method signatures, types, and event definitions caused by manual maintenance on each platform, and reduces the manual synchronization cost and the risk of missing configuration in cross-platform plugin development.

[0078] Example 3 Figure 3 This is a schematic diagram of a cross-platform plugin code generation device provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes: The DSL file acquisition module 310 is used to acquire a declarative domain-specific language DSL file, which is used to describe the semantics of plug-in capabilities. The cross-platform interface model generation module 320 is used to parse the DSL file and generate a cross-platform interface model based on the parsing result. The cross-platform interface model includes interface definition information consisting of method definition, type definition, event definition, component attributes, component commands and platform support scope information. The plugin code generation module 330 is used to generate interface implementation code and structured description information required for code generation for at least two target platforms based on the interface definition information in the cross-platform interface model.

[0079] The technical solution of this invention obtains a declarative DSL file and parses it to generate a cross-platform interface model. This model contains all interface information, including method signatures, type definitions, event definitions, component attributes, component commands, and platform support scope. Then, based on the cross-platform interface model, it extracts interface definition information and drives the automatic generation of multi-platform glue code and structured description files. This achieves the same-source derivation of interface definitions and multi-platform implementation products, eliminates the problem of inconsistent method signatures, types, and event definitions caused by manual maintenance on each platform, and reduces the manual synchronization cost and the risk of missing configuration in cross-platform plugin development.

[0080] Optional, the cross-platform interface model generation module 320 is specifically used for: Parse the DSL file and extract the module name, plugin type, method definition, parameter definition, return value definition, event definition, type alias definition, enumeration definition, component attribute definition, component command definition, platform support scope and long task flag information declared in the DSL file. The plugin type includes native module type and rendering component type. The extracted information is integrated according to the preset interface description specifications, the relationship between the information is established, and a cross-end interface model with intermediate representation is generated based on the integrated information.

[0081] Optionally, the plugin code generation module 330 includes: The glue code generation unit is used to read the method definition, event definition, type definition, component attribute definition, component command definition and platform support range information in the cross-platform interface model, and generate glue code for the cross-platform rendering side and the mobile web page side. The glue code includes call entry code, type definition code, event subscription code, bridging wrapper code and component wrapper code. The bridging template code generation unit is used to read the platform support scope information and method definition in the cross-platform interface model and generate at least one native platform-side bridging template code. The bridging template code includes parameter conversion code, method forwarding code, event callback code, and component command template code. The description file generation unit is used to convert the cross-platform interface model into a structured description file that can be recognized by the cross-platform framework interface automatic generation tool.

[0082] Optional, glue code generation unit, specifically used for: Read the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information in the cross-platform interface model, and determine the methods, events, and component capabilities supported by each target platform based on the platform support scope information; Generate glue code for mobile web pages, wherein the mobile web page glue code includes method declaration code and type definition code for developers to fill in business logic; The mobile webpage glue code is used as a proxy layer for the cross-platform rendering side to generate entry code for the cross-platform rendering side; the entry code is used to call the business logic filled in by the developer in the mobile webpage glue code.

[0083] Optionally, the cross-platform plugin code generation device also includes: The plugin lock file acquisition module is used to acquire the plugin manifest and plugin lock file after generating the interface implementation code for at least two target platforms and the structured description information required for code generation. Based on the plugin manifest and the plugin lock file, it generates the plugin shell's dependency configuration, build configuration, and native registration code as the plugin shell's registration artifacts. The capability list generation module is used to generate a structured capability list based on the cross-platform interface model, plugin list, and plugin locking file. The consistency detection module is used to perform consistency detection between the capability list and the registered artifacts of the plugin shell. If the consistency detection fails, subsequent build or release operations will be blocked.

[0084] Optional, a consistency detection module, specifically used for: The structured capability list contains capability items that are not registered in the registered product of the plug-in shell; The detection shows that the registered product of the plug-in shell contains capability items that are missing from the structured capability list; Check whether the range of supported platforms recorded in the structured capability list is consistent with the range of supported platforms actually registered in the registered product of the plug-in shell; Check whether the version information recorded in the plugin lock file is consistent with the version information recorded in the structured capability list; If any of the tests fails, the consistency check is deemed to have failed, and subsequent build or release operations are blocked.

[0085] Optionally, the cross-platform plugin code generation device also includes: The task identifier generation module is used to identify methods marked as long tasks from the cross-end interface model and generate a unique task identifier for each call of the identified long task method. The task object generation module is used to generate task objects on the cross-platform rendering side and the mobile webpage side. The task object includes cancellation method, pause method, resume method, status query method and progress event binding interface. The method binding module is used to generate a task management mapping on the native platform side with the task identifier as the key, and bind the sending and receiving of progress events, cancellation methods, pause methods, resume methods and status query methods to the same task identifier.

[0086] The cross-platform plugin code generation device provided in this embodiment of the invention can execute the cross-platform plugin code generation method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0087] In the technical solution of this invention, the information collected is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of related data all comply with the relevant laws, regulations and standards of relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0088] Example 4 According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product.

[0089] Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0090] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0091] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0092] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as cross-platform plug-in code generation methods.

[0093] In some embodiments, the cross-platform plug-in code generation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the cross-platform plug-in code generation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the cross-platform plug-in code generation method by any other suitable means (e.g., by means of firmware).

[0094] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0095] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0096] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0097] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0098] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0099] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0100] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the cross-platform plug-in code generation method provided in any embodiment of this application. This program product shares the same inventive concept as the cross-platform plug-in code generation method disclosed in the embodiments of this application, and therefore will not be described in detail here.

[0101] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0102] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for generating cross-platform plugin code, characterized in that, include: Obtain a declarative domain-specific language (DSL) file, which describes the semantics of plugin capabilities; The DSL file is parsed, and a cross-platform interface model is generated based on the parsing results. The cross-platform interface model includes interface definition information consisting of method definitions, type definitions, event definitions, component attributes, component commands, and platform support scope information. Based on the interface definition information in the cross-platform interface model, generate interface implementation code for at least two target platforms and the structured description information required for code generation.

2. The method according to claim 1, characterized in that, Parse the DSL file and generate a cross-platform interface model based on the parsing results, including: Parse the DSL file and extract the module name, plugin type, method definition, parameter definition, return value definition, event definition, type alias definition, enumeration definition, component attribute definition, component command definition, platform support scope and long task flag information declared in the DSL file. The plugin type includes native module type and rendering component type. The extracted information is integrated according to the preset interface description specifications, the relationship between the information is established, and a cross-end interface model with intermediate representation is generated based on the integrated information.

3. The method according to claim 1, characterized in that, Based on the interface definition information in the cross-platform interface model, generate interface implementation code for at least two target platforms and the structured description information required for code generation, including: Read the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information in the cross-platform interface model, and generate glue code for the cross-platform rendering side and the mobile webpage side. The glue code includes call entry code, type definition code, event subscription code, bridging wrapper code, and component wrapper code. Read the platform support scope information and method definitions in the cross-platform interface model, and generate at least one native platform-side bridging template code. The bridging template code includes parameter conversion code, method forwarding code, event callback code, and component command template code. The cross-platform interface model is converted into a structured description file that can be recognized by the cross-platform framework interface automatic generation tool.

4. The method according to claim 3, characterized in that, Read the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information from the cross-platform interface model, and generate glue code for both the cross-platform rendering side and the mobile webpage side, including: Read the method definitions, event definitions, type definitions, component attribute definitions, component command definitions, and platform support scope information in the cross-platform interface model, and determine the methods, events, and component capabilities supported by each target platform based on the platform support scope information; Generate glue code for mobile web pages, wherein the mobile web page glue code includes method declaration code and type definition code for developers to fill in business logic; The mobile webpage glue code is used as a proxy layer for the cross-platform rendering side to generate entry code for the cross-platform rendering side; the entry code is used to call the business logic filled in by the developer in the mobile webpage glue code.

5. The method according to claim 1, characterized in that, After generating the interface implementation code for at least two target platforms and the structured description information required for code generation, it also includes: Obtain the plugin manifest and plugin lock file. Based on the plugin manifest and plugin lock file, generate the plugin shell's dependency configuration, build configuration, and native registration code as the plugin shell's registration artifacts. Based on the cross-platform interface model, plugin list, and plugin locking file, a structured capability list is generated; A consistency check is performed between the capability list and the registered artifacts of the plugin shell. If the consistency check fails, subsequent build or release operations are blocked.

6. The method according to claim 5, characterized in that, Perform a consistency check between the capability list and the registered artifacts of the plugin shell. If the consistency check fails, block subsequent build or release operations, including: The structured capability list contains capability items that are not registered in the registered product of the plug-in shell; The detection shows that the registered product of the plug-in shell contains capability items that are missing from the structured capability list; Check whether the range of supported platforms recorded in the structured capability list is consistent with the range of supported platforms actually registered in the registered product of the plug-in shell; Check whether the version information recorded in the plugin lock file is consistent with the version information recorded in the structured capability list; If any of the tests fails, the consistency check is deemed to have failed, and subsequent build or release operations are blocked.

7. The method according to claim 1, characterized in that, Also includes: Identify methods marked as long tasks from the cross-platform interface model, and generate a unique task identifier for each call of the identified long task method; A task object is generated on both the cross-platform rendering side and the mobile webpage side. The task object includes a cancel method, a pause method, a resume method, a status query method, and a progress event binding interface. On the native platform side, a task management mapping is generated with the task identifier as the key, and the sending and receiving of progress events, cancellation methods, pause methods, resumption methods, and status query methods are all bound to the same task identifier.

8. A cross-platform plugin code generation device, characterized in that, include: The DSL file acquisition module is used to acquire a declarative domain-specific language DSL file, which is used to describe the semantics of plug-in capabilities. A cross-platform interface model generation module is used to parse the DSL file and generate a cross-platform interface model based on the parsing results. The cross-platform interface model includes interface definition information consisting of method definitions, type definitions, event definitions, component attributes, component commands, and platform support scope information. The plugin code generation module is used to generate interface implementation code and structured description information required for code generation for at least two target platforms based on the interface definition information in the cross-platform interface model.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the cross-platform plug-in code generation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the cross-platform plug-in code generation method according to any one of claims 1-7.

Images