Native platform function calling method, device and computer equipment

Abstract

The present application relates to a method, apparatus and computer device for calling native platform functions, wherein the method comprises: using a scripting tool to generate a unified interface document for multiple native platforms, wherein the programming languages ​​of the multiple native platforms are different; calling the functions corresponding to the native platforms through the unified interface document of the native platforms, thereby solving the problem that the calling of native platform functions requires respective docking.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus and computer device for calling a native platform function. Background Art

[0002] The plugin is an open source graphics code toolkit from Google that helps developers write efficient and beautiful applications using a domain-specific language (DSL). It supports many native platforms such as iOS, Android, web, desktop, and embedded systems. For example, a plugin can be a Flutter plugin, and the language can be any programming language. As a graphics toolkit, Flutter does not have basic capabilities such as positioning and Bluetooth connection. The Flutter plugin is an official solution provided to solve the problem of insufficient capabilities of the framework itself and the need to bridge the capabilities of the original platform.

[0003] Using plug-ins can solve the problem of insufficient native functions, but due to the loose constraints on code writing, there are some defects: (1) The plug-in finds the corresponding native platform implementation through method string comparison. Since the programming languages ​​of native platforms are different, each native platform needs to write bridge glue code; (2) Adjustments to the method strings of either native platform will not be perceived by the other end, which may cause the plug-in to be unable to call the native capabilities normally; (3) The native platform implementation is not unified, and it needs to be re-implemented when adapting to other cross-end solutions (React Native, H5, mini programs); (4) The native platform implementation is not unified, and multiple external interface documents need to be maintained.

[0004] Currently, no effective solution has been proposed for the above-mentioned problems existing in the relevant technologies. Summary of the invention

[0005] The embodiments of the present application provide a method, apparatus and computer device for calling a native platform function, so as to at least solve the problems existing in calling native platform functions in the related art.

[0006] In a first aspect, an embodiment of the present application provides a method for calling a native platform function, the method comprising:

[0007] Generate unified interface documents for multiple native platforms using a scripting tool, where the programming languages ​​of the multiple native platforms are different;

[0008] The functions corresponding to the native platform are called through the unified interface document of the native platform.

[0009] In some embodiments, the step of generating unified interface documents for multiple native platforms using a scripting tool includes:

[0010] Establishing a repository, the repository is used to describe declarations and annotations of the calling method, as well as models and enumerations required by the calling method;

[0011] A script tool is triggered, and the script tool is used to analyze the abstract syntax tree and the annotations in the warehouse, and a plurality of unified interface documents of the native platforms are respectively generated through the abstract syntax tree and the annotations.

[0012] In some embodiments, calling a function corresponding to the native platform through a unified interface document of the native platform includes:

[0013] Creating a configuration file in the warehouse, wherein the configuration file is used to record each sub-warehouse of the native platform;

[0014] Actively push the interface documents of each native platform generated by the script tool to the sub-warehouse of the corresponding native platform;

[0015] Pull the code of the sub-warehouse respectively and obtain the corresponding interface document;

[0016] The function corresponding to the native platform is called according to the interface document.

[0017] In some of the embodiments, the native platform includes: iOS platform, Android platform and embedded platform.

[0018] In some embodiments, the method further includes updating the warehouse, specifically comprising:

[0019] Re-edit the code in the repository;

[0020] The script tool reparses the abstract syntax tree and comments corresponding to the updated code to generate an update repository.

[0021] In some of the embodiments, after the developer describes the declaration and annotation of the calling method in the warehouse by using the domain specific language, the calling method name and annotation in the warehouse are parsed by using the syntax parsing library of the domain specific language;

[0022] According to the calling method name and comment, automatically generate interfaces of each native platform language and comments of each native platform through a script tool;

[0023] Through the hook of gitLab, the interfaces of each native platform language and the annotations of each native platform are pushed to the sub-repository of the corresponding native platform.

[0024] In some of the embodiments, the configuration file includes a general call layer, and the function of the corresponding native platform is called through the general call layer according to the interface document.

[0025] In a second aspect, an embodiment of the present application provides a native platform function calling device, including: an interface generating module and a calling module; wherein:

[0026] An interface document generation module, used to generate unified interface documents of multiple native platforms using a scripting tool, wherein the programming languages ​​of the multiple native platforms are different;

[0027] The function calling module is used to call the function corresponding to the native platform through the unified interface document of the native platform.

[0028] In a third aspect, an embodiment of the present application provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the first aspect above when executing the computer program.

[0029] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0030] Compared with the related art, the native platform function calling method, apparatus and computer equipment provided in the embodiments of the present application include: using a script tool to generate a unified interface document for multiple native platforms, where the programming languages ​​of the multiple native platforms are different; calling the functions corresponding to the native platforms through the unified interface document of the native platforms solves the problem that the functions of the native platforms need to be connected to each other when calling them.

[0031] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0033] Figure 1 is a flow chart of a method for calling a native platform function provided in an embodiment of the present application;

[0034] Figure 2 This is a schematic diagram of the existing Flutter plugin bridge;

[0035] Figure 3 This is a schematic diagram of the existing Flutter plug-in bridging method through interface constraints;

[0036] Figure 4 is a schematic diagram of a native platform function calling method provided in an embodiment of the present application;

[0037] Figure 5 is a schematic diagram of a native platform function calling device provided in an embodiment of the present application;

[0038] Figure 6 It is a diagram of the internal structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0040] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complicated and lengthy, for ordinary technicians in this field related to the content disclosed in this application, some changes in design, manufacturing or production based on the technical content disclosed in this application are just conventional technical means, and should not be understood as insufficient content disclosed in this application.

[0041] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0042] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantitative limitation, and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships, for example, "A and / or B" can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects before and after are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0043] This embodiment also provides a method for calling a native platform function. Figure 1 As shown, the native platform function calling method includes the following steps:

[0044] Step 110: Generate unified interface documents for multiple native platforms using a scripting tool, where the programming languages ​​of the multiple native platforms are different.

[0045] Step 120: calling the function corresponding to the native platform through the unified interface document of the native platform.

[0046] The plug-ins in this application are not limited to Flutter plug-ins, but can include any cross-platform solutions that require native platform capabilities, including but not limited to React Native, Weex, H5, and mini programs. This application takes the Flutter plug-in as an example for explanation.

[0047] Existing, such as Figure 2As shown in the figure, when the Flutter plug-in developer needs to call a certain capability of the native platform, he initiates the call through [MethodChannel.invoke("funcA")], and each native platform needs to return it to the Flutter developer through string comparison [if(name=="funcA")]. The above solution cannot constrain the developer's behavior by using string comparison, and each native platform developer needs to connect one by one, such as Figure 3 shown.

[0048] This application introduces the idea of ​​interface-oriented. Native developers no longer need to bridge the native platform by comparing strings. Instead, they use actively generated interfaces to constrain the behavior of native developers. This interface can uniformly call the functions of other native platforms. In addition, platform developers do not need to worry about the Flutter bridge code. Through the constraints of interface-oriented programming, they only need to focus on the specific implementation. The interface documents of the native platform are uniformly generated by automated syntax parsing tools, without manual maintenance. In addition, this application actively generates interfaces for each platform through a description language, so that the native platform only needs to focus on the implementation. In addition, since the original Flutter framework layer design did not consider the synchronization problem, the Flutter side and the native platform modifications cannot be synchronized. This application uses automated tools to bind each implementation. When one party changes, the other party will be passively updated.

[0049] In some of these embodiments, reference Figure 4 , the use of script tools to generate unified interface documents for multiple native platforms includes:

[0050] Establishing a repository, the repository is used to describe declarations and annotations of the calling method, as well as models and enumerations required by the calling method;

[0051] A script tool is triggered, and the script tool is used to analyze the abstract syntax tree and the annotations in the warehouse, and a plurality of interface documents of the native platform are respectively generated through the abstract syntax tree and the annotations.

[0052] This application can establish a repository on the code repository GitLab. For Flutter plug-ins, warehouse A can be defined by Flutter developers and written in Dart language. It is understandable that in other embodiments, other plug-ins can also be used to write warehouses in other languages, such as TypeScript. Warehouse A is used to describe the interfaces, models, and enumerations that the business needs to expose and to add code comments to these interfaces, models, and enumerations.

[0053] A scripting tool is a software tool implemented using a high-level scripting language. Typically, a script written in a scripting tool can be interpreted by an execution environment at runtime to perform a specific programming task. The present application uses a scripting tool to parse the abstract syntax tree and annotations in the repository, and generates interface documents of multiple native platforms respectively through the abstract syntax tree and annotations.

[0054] Abstract Syntax Tree (AST) is an abstract representation of the syntax structure of source code. It represents the syntax structure of a programming language in a tree form, and each node in the tree represents a structure in the source code.

[0055] Comments are explanations and descriptions of the code. The purpose is to make it easy for others and yourself to understand what the code is used for. Correct program comments generally include preface comments and functional comments. The main content of preface comments includes the module interface, data description and module function. The main content of module functional comments includes the function of the program segment, the function of the statement and the status of the data.

[0056] The unified interface document includes the calling method, the calling interface and documents of each native platform. Native developers use the interfaces and documents generated by the script tool to implement the functions that really need the plug-in. Flutter developers use the calling code generated by the script tool to implement the needs of the market or product.

[0057] In some embodiments, TypeScript language is used as DSL to provide a set of description specifications for the plug-in to constrain the signatures of synchronous and asynchronous methods and their input and output parameters, as well as data entity classes, so as to strictly limit the implementation of methods and standardize the specific implementation logic of engineers at each end. This set of specifications can also automatically generate interface comments and documents for easy reference.

[0058] Since each end supports different data types, we use custom data structures in DSL so that each end can use them. We also use annotations to determine the version supported by the interface, whether it is deprecated, and whether the parameter is required, which facilitates subsequent development and problem tracing.

[0059] Use TypeScript to develop CLI and translate DSL into Android, iOS and JavaScript interface codes to ensure the logical consistency of codes on each end.

[0060] In some embodiments, calling the function corresponding to the native platform through the calling method and the unified interface document of the native platform includes:

[0061] Creating a configuration file in the warehouse, wherein the configuration file is used to record each sub-warehouse of the native platform;

[0062] Actively push the interface documents of each native platform generated by the script tool to the sub-warehouse of the corresponding native platform;

[0063] Each native platform developer pulls the code of the sub-warehouse and obtains the corresponding interface document;

[0064] Call the corresponding native platform function according to the interface document.

[0065] Because the functions generated by each native platform are the same, the unified interface document is only extracted from the warehouse. However, the interfaces and comments of the native platforms have their own implementation languages ​​(such as iOS-Objective-C, Android-Java, and Embedded-C), so there are multiple copies. That is, the configuration file will maintain multiple sub-warehouses of native platforms, and each sub-warehouse has the interface and document of the corresponding native platform. When using Flutter, developers do not need to care about the interfaces and implementations of each native platform, but only need to focus on the generated documents to call.

[0066] In addition, the functions implemented by a Flutter developer will run on many native platforms, and the native platforms will be implemented by different developers. If the code of the Flutter developer and the code of each native developer are placed in the same warehouse, the management complexity of this warehouse will be greatly increased. Therefore, this application separates the native warehouse so that the native developer can only focus on the implementation of their own platform, which can greatly reduce the coupling of the code and reduce the complexity of code management. When the native warehouse is independent, the native platform no longer cares about the code warehouse address of other platforms. It only needs to modify and submit the code warehouse of its own platform.

[0067] In some of the embodiments, the native platform includes: iOS platform, Android platform and embedded platform.

[0068] In some embodiments, the method further includes updating the warehouse, specifically comprising:

[0069] Re-edit the repository code;

[0070] The script tool reparses the abstract syntax tree and comments corresponding to the updated code to generate an update repository.

[0071] When the requirements change and the interface of the Flutter plug-in needs to be changed, the Flutter developer re-edits the Dart code in the repository, and the script tool re-parses the syntax tree and comments of the Dart language to generate relevant content and resubmit it.

[0072] In some of the embodiments, after the developer describes the declaration and annotation of the calling method in the warehouse by using the domain specific language, the calling method name and annotation in the warehouse are parsed by using the syntax parsing library of the domain specific language;

[0073] Based on the calling method names and comments, the script tool automatically generates interfaces in each native platform language and comments for each native platform;

[0074] Push to the sub-repositories of each native platform through gitLab's hook.

[0075] After Flutter developers describe the declaration and comments of the calling method in the warehouse in Dart language, they use Dart's syntax parsing library analyzer (different languages ​​have their own syntax parsing libraries) to parse the method names and comments in the warehouse. Through the method names and comments, script tools can automatically generate interfaces in each native platform language and comments for each platform, and then push them to the warehouse of each native platform through the gitLab hook.

[0076] In some of the embodiments, the configuration file includes a universal call layer, and according to the interface document, the function of the corresponding native platform is called through the universal call layer. The existing cross-end solutions are relatively scattered and do not consider the compatibility of other frameworks. This application will describe the unified interface of the language, and each native platform only needs to adapt to one more intermediate layer. This application has written a set of universal call layers for cross-end platforms such as flutter, applets, rn, web, etc. to suit different native platforms.

[0077] It should be noted that the steps shown in the above process or the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0078] This embodiment also provides a native platform function calling device, which is used to implement the above-mentioned embodiments and preferred implementation modes, and will not be repeated here. As used below, the terms "module", "unit", "sub-unit", etc. can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0079] Figure 5 is a structural block diagram of a native platform function calling device according to an embodiment of the present application, such as Figure 5 As shown, the device includes: an interface generation module 510 and a function calling module 520; wherein:

[0080] An interface document generation module 510 is used to generate unified interface documents of multiple native platforms using a scripting tool, wherein the programming languages ​​of the multiple native platforms are different;

[0081] The function calling module 520 is used to call the function corresponding to the native platform through the unified interface document of the native platform.

[0082] This embodiment introduces the idea of ​​interface-oriented programming. Native developers no longer need to bridge the native platform by comparing strings. Instead, they use actively generated interfaces to constrain the behavior of native developers. This interface can uniformly call the functions of other native platforms. In addition, platform developers do not need to worry about Flutter bridging code. Through the constraints of interface-oriented programming, they only need to focus on the specific implementation. The interface documents of the native platform are uniformly generated by automated syntax parsing tools, without the need for manual maintenance.

[0083] In some embodiments, the interface document generation module 510 is further used to:

[0084] Establishing a repository, the repository is used to describe declarations and annotations of the calling method, as well as models and enumerations required by the calling method;

[0085] A script tool is triggered, and the script tool is used to analyze the abstract syntax tree and the annotations in the warehouse, and a plurality of unified interface documents of the native platforms are respectively generated through the abstract syntax tree and the annotations.

[0086] In some embodiments, the function calling module 520 is further configured to:

[0087] Creating a configuration file in the warehouse, wherein the configuration file is used to record each sub-warehouse of the native platform;

[0088] Actively push the interface documents of each native platform generated by the script tool to the sub-warehouse of the corresponding native platform;

[0089] Pull the code of the sub-warehouse respectively and obtain the corresponding interface document;

[0090] The function corresponding to the native platform is called according to the interface document.

[0091] In some of the embodiments, the native platform includes: iOS platform, Android platform and embedded platform.

[0092] In some embodiments, an update module is further included, which is used to:

[0093] Re-edit the code in the repository;

[0094] The script tool reparses the abstract syntax tree and comments corresponding to the updated code to generate an update repository.

[0095] In some embodiments, the interface document generation module 510 is further used to:

[0096] Parsing the calling method names and comments in the repository through a domain-specific language syntax parsing library;

[0097] According to the calling method name and comment, automatically generate interfaces of each native platform language and comments of each native platform through a script tool;

[0098] Through the hook of gitLab, the interfaces of each native platform language and the annotations of each native platform are pushed to the sub-repository of the corresponding native platform.

[0099] In some of the embodiments, the configuration file includes a general call layer, and the function of the corresponding native platform is called through the general call layer according to the interface document.

[0100] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0101] In addition, combined Figure 1 The native platform function calling method described in the embodiment of the present application can be implemented by a computer device. Figure 6 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present application.

[0102] The computer device may include a processor 61 and a memory 62 storing computer program instructions.

[0103] Specifically, the processor 61 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0104] Among them, the memory 62 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 62 may include a hard disk drive (HDD), a floppy disk drive, a solid state drive (SSD), a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 62 may include a removable or non-removable (or fixed) medium. Where appropriate, the memory 62 may be inside or outside the data processing device. In a specific embodiment, the memory 62 is a non-volatile memory. In a specific embodiment, the memory 62 includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, PROM for short), an erasable PROM (Erasable Programmable Read-Only Memory, EPROM for short), an electrically erasable PROM (Electrically Erasable Programmable Read-Only Memory, EEPROM for short), an electrically alterable ROM (Electrically Alterable Read-Only Memory, EAROM for short) or a flash memory (FLASH) or a combination of two or more of these. Under appropriate circumstances, the RAM can be a static random access memory (SRAM) or a dynamic random access memory (DRAM), wherein the DRAM can be a fast page mode dynamic random access memory (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0105] The memory 62 may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 61 .

[0106] The processor 61 implements any one of the native platform function calling methods in the above embodiments by reading and executing computer program instructions stored in the memory 62 .

[0107] In some of the embodiments, the computer device may further include a communication interface 63 and a bus 60. Figure 6 As shown, the processor 61, the memory 62, and the communication interface 63 are connected via a bus 60 and communicate with each other.

[0108] The communication interface 63 is used to implement communication between the modules, devices, units and / or equipment in the embodiment of the present application. The communication interface 63 can also implement data communication with other components such as: external devices, image / data acquisition equipment, databases, external storage, and image / data processing workstations.

[0109] The bus 60 includes hardware, software or both, and couples the components of the computer device to each other. The bus 60 includes but is not limited to at least one of the following: a data bus, an address bus, a control bus, an expansion bus, and a local bus. By way of example and not limitation, bus 60 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses or a combination of two or more of the above. Where appropriate, bus 60 may include one or more buses. Although embodiments of the present application describe and illustrate a particular bus, the present application contemplates any suitable bus or interconnect.

[0110] The computer device can execute the native platform function calling method in the embodiment of the present application based on the acquired program instructions, thereby realizing the combination Figure 1 Describes how to call native platform functions.

[0111] In addition, in combination with the native platform function calling method in the above embodiment, the embodiment of the present application can provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by the processor, any one of the native platform function calling methods in the above embodiment is implemented.

[0112] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0113] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A native platform function calling method, characterized in that: The method comprises: Generate unified interface documents for multiple native platforms using a scripting tool, where the programming languages ​​of the multiple native platforms are different; Calling the functions corresponding to the native platform through the unified interface document of the native platform; The step of using a script tool to generate unified interface documents for multiple native platforms includes: Establishing a repository, the repository is used to describe declarations and annotations of the calling method, as well as models and enumerations required by the calling method; triggering a script tool, analyzing the abstract syntax tree and the annotations in the warehouse by using the script tool, and generating unified interface documents of a plurality of the native platforms respectively through the abstract syntax tree and the annotations; The calling of the function corresponding to the native platform through the unified interface document of the native platform includes: Creating a configuration file in the warehouse, wherein the configuration file is used to record each sub-warehouse of the native platform; Actively push the interface documents of each native platform generated by the script tool to the sub-warehouse of the corresponding native platform; Pull the code of the sub-warehouse respectively and obtain the corresponding interface document; The function corresponding to the native platform is called according to the interface document.

2. The method according to claim 1, characterized in that The native platforms include: iOS platform, Android platform and embedded platform.

3. The method according to claim 1, characterized in that The method further includes updating the warehouse, specifically comprising: Re-edit the code in the repository; The script tool reparses the abstract syntax tree and comments corresponding to the updated code to generate an update repository.

4. The method according to claim 1, characterized in that: After the developer describes the declaration and annotation of the calling method in the warehouse using the domain-specific language, the calling method name and annotation in the warehouse are parsed using the syntax parsing library of the domain-specific language; According to the calling method name and comment, automatically generate interfaces of each native platform language and comments of each native platform through a script tool; Through the hook of gitLab, the interfaces of each native platform language and the annotations of each native platform are pushed to the sub-repository of the corresponding native platform.

5. The method according to claim 1, characterized in that The configuration file includes a general call layer, and according to the interface document, the function of the corresponding native platform is called through the general call layer.

6. A native platform function calling device, comprising: Interface generation module and function call module; wherein: An interface document generation module is used to generate unified interface documents for multiple native platforms using a scripting tool, wherein the programming languages ​​of the multiple native platforms are different; the interface document generation module is also used to establish a warehouse, wherein the warehouse is used to describe the declaration and annotation of the calling method, as well as the model and enumeration required by the calling method; triggering a script tool, analyzing the abstract syntax tree and the annotations in the warehouse by using the script tool, and generating unified interface documents of a plurality of the native platforms respectively through the abstract syntax tree and the annotations; A function calling module, used to call the function corresponding to the native platform through the unified interface document of the native platform; the function calling module is also used to establish a configuration file in the warehouse, and the configuration file is used to record each sub-warehouse of the native platform; Actively push the interface documents of each native platform generated by the script tool to the sub-warehouse of the corresponding native platform; Pull the code of the sub-warehouse respectively and obtain the corresponding interface document; The function corresponding to the native platform is called according to the interface document.

7. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 5 is implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images