Multi-terminal application development system, method, medium and device

Abstract

The present application provides a multi-terminal application development system, method, medium and device for developing applications adapted for multi-terminal reuse. The system includes a terminal service engine, and the terminal service engine includes: a configuration management unit for performing service configuration and function configuration based on local configuration or configurations dynamically published in the cloud; a plugin management unit for pluginizing each atomic function of basic functions or extended functions based on the function configuration to obtain each atomic plugin; an orchestration control unit for performing configuration parsing on the service configurations of each service to determine the plugin set corresponding to each service, and performing process orchestration on each plugin in the plugin set; a service management unit for configuring each service, wherein each service corresponds to a different plugin set based on the service configuration and the process orchestration result, and supports the reuse of the same plugin in different services. The present application can improve the efficiency of multi-terminal application development.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a multi-terminal application development system, method, medium and device. Background Art

[0002] For an application program, in order to meet different operating systems (such as iOS operating system, Android operating system, HarmonyOS), it is usually necessary to develop for different operating systems separately. At present, the R & D team needs to maintain three terminals of iOS, Android and HarmonyOS at the same time, which increases the labor cost and reduces the development efficiency. Therefore, how to improve the development efficiency of multi-terminal application programs is a technical problem that those skilled in the art need to consider and solve. Summary of the Invention

[0003] In view of this, this application provides a multi-terminal application development system, method, medium and electronic device, and the main purpose is to...

[0004] According to one aspect of this application, a multi-terminal application development system is provided for application development adapted to multi-terminal reuse. The system includes a terminal service-oriented engine, and the terminal service-oriented engine includes:

[0005] A configuration management unit for performing service configuration and function configuration based on local configuration or configuration dynamically published in the cloud;

[0006] A plugin management unit, based on the function configuration, performs plugin processing on each atomic function of the basic function or extended function to obtain each atomic plugin;

[0007] An orchestration control unit for performing configuration parsing on the service configuration of each service to determine the plugin set corresponding to each service, and performing process orchestration on each plugin in the plugin set;

[0008] A service management unit for configuring each service, where each service corresponds to a different plugin set based on the service configuration and process orchestration result, and supports reusing the same plugin in different services.

[0009] According to one aspect of this application, a multi-terminal application development method is provided for application development adapted to multi-terminal reuse. The method includes:

[0010] Performing service configuration and function configuration based on local configuration or configuration dynamically published in the cloud;

[0011] Based on the function configuration, performing plugin processing on each atomic function of the basic function or extended function to obtain each atomic plugin;

[0012] Perform configuration parsing on the service configurations for each service to determine the corresponding plugin sets for each service, and perform process orchestration on each plugin in the plugin sets;

[0013] Configure each service, where each service corresponds to a different plugin set based on the service configuration and the process orchestration result, and supports reusing the same plugin in different services.

[0014] According to one aspect of the present application, there is provided a multi-terminal application calling system for calling a target application adapted for multi-terminal reuse. The system includes a terminal service engine, and the terminal service engine includes:

[0015] A configuration management unit for performing service configuration and function configuration based on local configuration or configurations dynamically published in the cloud;

[0016] A plugin management unit that, based on the function configuration, performs plugin processing on each atomic function of the basic function or extended function to obtain each atomic plugin;

[0017] A service routing unit for communicating with the caller, receiving a service call request from the caller for a target service, and completing service callback based on the target service call result;

[0018] A service management unit for configuring multiple services based on the service configuration and driving the target service;

[0019] An orchestration control unit for performing configuration parsing on the driving of the target service to determine the target plugin set corresponding to the target service, performing callback and process orchestration on each plugin in the target plugin set, and returning the orchestration result to the service management unit and the service routing unit to complete service callback, where each service corresponds to a different plugin set based on the service configuration and the process orchestration result, and supports reusing the same plugin in different services.

[0020] According to one aspect of the present application, there is provided a multi-terminal application calling method for calling a target application adapted for multi-terminal reuse. The method includes:

[0021] In response to a service call request from the caller for a target service, perform configuration parsing of the target service based on local configuration or a service configuration dynamically published in the cloud to determine the target plugin set corresponding to the target service;

[0022] Perform callback and process orchestration on each plugin in the target plugin set, and return the orchestration result to the caller to complete service callback,

[0023] Among them, based on the function configuration published locally or dynamically in the cloud, each atomic function of the basic function or extended function is processed into a plug-in to obtain each atomic plug-in;

[0024] Among them, each service corresponds to a different plug-in set based on the service configuration and the process choreography result, and supports the reuse of the same plug-in in different services.

[0025] According to one aspect of the present application, there is provided an application, wherein the application is developed based on the multi-terminal application development system or based on the multi-terminal application development method.

[0026] According to one aspect of the present application, there is provided a storage medium in which a computer program is stored. Among them, the computer program is set to execute the above-mentioned multi-terminal application development and calling method when running.

[0027] According to one aspect of the present application, there is provided an electronic device including a memory and a processor. A computer program is stored in the memory, and the processor is set to run the computer program to execute the above-mentioned multi-terminal application development and calling method.

[0028] By means of the above technical solution, a multi-terminal application development system, method, medium and device provided by the present application first splits each function into atomic plug-ins, and then combines the atomic plug-ins into various functions. The caller can call the target service in the way of url, without caring about whether the plug-ins corresponding to the service are written in C++ language, or the end-specific languages of iOS (OC), Android (JAVA), and HarmonyOS (ArkTs). Through the solution of the embodiments of the present application, there is no need to implement any bridging code. For the plug-in itself, it can be registered as a C++ plug-in independent of the end, or it can be registered as an OC, JAVA, or ArkTs plug-in related to the end, so as to maximize code reuse and utilize end characteristics, thereby improving application development efficiency.

[0029] In addition, the multi-terminal application calling solution provided by the embodiments of the present application splits the code into the smallest atomic plug-ins, combines the plug-ins into various services in the way of DSL choreography, and provides a common URL way for external calls. The caller does not need to implement any bridging code, and can call any service composed of plug-ins implemented in any language through any language and any end. The caller and the callee are completely decoupled, and are also completely decoupled from the end and the language, realizing a simple and clean code reuse ability.

[0030] The above description is only an overview of the technical solution of the present application. In order to better understand the technical means of the present application, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the specific embodiments of the present application are specifically given below. Brief Description of the Drawings

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

[0032] Figure 1 It shows a logical schematic diagram of a multi-terminal application development system provided by an embodiment of the present application;

[0033] Figure 2 It shows a schematic diagram of realizing plug-in assembly service by DSL choreography provided by an embodiment of the present application;

[0034] Figure 3 It shows a schematic diagram of reusing the same plug-in in different services provided by an embodiment of the present application;

[0035] Figure 4 It shows a flowchart of a multi-terminal application development method provided by an embodiment of the present application;

[0036] Figure 5 It shows a schematic diagram of multi-terminal application development and invocation provided by an embodiment of the present application;

[0037] Figure 6 It shows a flowchart of a multi-terminal application invocation method provided by an embodiment of the present application. Detailed Description of the Embodiments

[0038] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present application. It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

[0039] To improve the development efficiency of multi-terminal applications, in the current conventional way of code reuse, the code to be reused is usually implemented in a language common to all terminals, such as C++. This brings a problem that the calling party needs to be aware of this C++ implementation method and make calls through direct or bridging methods. For example, on the HarmonyOS terminal, it is very cumbersome for ArkTS to call C++. A lot of bridging code needs to be written.

[0040] Therefore, in view of the current situation that the R & D team needs to maintain the iOS, Android, and HarmonyOS terminals simultaneously, in order to solve the problems of labor cost and code reuse, and at the same time meet the respective characteristics of the iOS, Android, and HarmonyOS terminals, the embodiments of this application propose a method of functional plug-in and plug-in reuse. Through this method, the common code for all terminals and the characteristic code for each terminal can be run simultaneously, so as to achieve the maximum degree of code reuse, reduce labor costs and maintenance costs, and maintain the consistency of the three terminals.

[0041] The term explanations are as follows.

[0042] XaaS, that is, the XasaService (Everything as a Service) architecture or concept. Various capabilities (such as add-to-cart interface calls, specification panels, pop-ups, Toasts, etc.) are sunk into atomic plug-ins, and then combined into services (such as instant add-to-cart, instant bill of lading) and provided for each scenario to call.

[0043] Plug-inization refers to splitting a service (task) into multiple independent plug-ins (Plugins). Each plug-in can be developed, tested, compiled, released, and upgraded independently. It is equivalent to a module being a program package. Plug-ins can be dynamically loaded and unloaded at runtime to achieve function expansion and improved flexibility.

[0044] DSL orchestration is a method of process orchestration using a Domain Specific Language (DSL). DSL is a programming language for a specific domain. It supports the minimum set of features required for that domain, allowing users to solve problems in a certain aspect of the system without building a complete system. Through DSL orchestration, complex scenario processes can be defined and executed, improving development efficiency and quality, and having a significant effect on enhancing the development efficiency, quality, and robustness of key scenarios.

[0045] See Figure 1 , which shows a logical schematic diagram of a multi-terminal application development system provided by the embodiments of this application. The multi-terminal application development system provided by the embodiments of this application, on the basis of the original development system architecture, includes a terminal service engine. Through this terminal service engine, plug-inization and process orchestration are realized. Thus, atomic plug-ins can be reused for different services, and application development efficiency is improved through plug-in reuse.

[0046] The embodiment of the present application provides a multi-terminal application development system for developing applications adapted for multi-terminal reuse. Here, multi-terminal reuse can be understood as that different operating system clients can use the same set of development systems for application development. The multi-terminals are at least two terminals or more terminals. For example, the iOS terminal, the Android terminal, and the HarmonyOS terminal can all use the development system provided by the embodiment of the present application to develop a certain target application, thereby reducing the development pressure of R & D personnel and saving labor and time costs.

[0047] As Figure 1 can be seen, the multi-terminal application development system includes a terminal service engine 11, and the terminal service engine 11 further includes a configuration management unit 1101, a plugin management unit 1102, an orchestration control unit 1103, and a service management unit 1104.

[0048] The configuration management unit 1101 is used to perform service configuration and function configuration based on local configuration or configurations dynamically published in the cloud.

[0049] A service can be understood as an operation task on an APP. Taking a food delivery APP as an example, services can be, for example, "instant add to cart" and "instant bill of lading". Service configuration refers to the configuration information required for configuring the service. These configuration information can be built in locally on the terminal side or configured by a configuration platform in the cloud (server side). Therefore, the configuration information supports dynamic update.

[0050] A function refers to each ability split from the operation task based on the service, which can include basic functions (independent of the scenario) and extended functions (related to the scenario). Correspondingly, function configuration refers to the configuration information used to implement each function. Similar to the aforementioned service configuration, the configuration information for function configuration can be built in locally on the terminal side or configured by a configuration platform in the cloud (server side). Therefore, the configuration information supports dynamic update.

[0051] The plugin management unit 1102, based on the function configuration, performs plugin processing on each atomic function of the basic function or the extended function to obtain each atomic plugin.

[0052] In the embodiment of the present application, each function point is split into independent atomic plugins. For example, functions such as login, pop-up window, add to cart interface call, loading, toast, and specification panel are implemented as atomic plugins through the plugin method.

[0053] There is no limitation on the specific plugin method and the language of the plugin. The terminal service engine provides bridging capabilities in various languages, including but not limited to OC, JAVA, ArkTs, etc.

[0054] The steps for implementing a plugin may include: 1. Inherit from the plugin base class, write a plugin subclass, and implement the interface functions of pluginKey (required), requiredParamTypes (optional), willBeExecuted (optional), onExecuteFinished (optional), and handleWithParams (required); 2. Write a factory subclass to create a plugin object; 3. Register the plugin into the terminal service engine.

[0055] The steps for implementing a service may include: 1. Register the plugins included in the service (public plugins do not need to be registered); 2. Write a service DSL to describe the service process DAG; 3. Register the service into the terminal service engine; 4. Register the dynamic DSL address.

[0056] For the plugins in the embodiments of this application, from the perspective of the implemented functions, the plugin types may include at least one of a login plugin, a pop-up window plugin, an add-to-cart plugin, a loading plugin, a message prompt plugin, and a specification panel plugin. From the perspective of terminal characteristics, the plugins may include public plugins and terminal characteristic plugins. Among them, the public plugins can be written in a first programming language that supports multiple terminals, and the terminal characteristic plugins can be written in a specific programming language supported by the terminal characteristics. For example, the code that is common to iOS, Android, and HarmonyOS can be registered as a C++ plugin, and the code related to the terminal characteristics can be registered as an iOS plugin, an Android plugin, or a HarmonyOS plugin. In addition, from the perspective of functions, the plugins can be divided into scenario plugins (such as add-to-cart, pop-up window, login) and basic plugins (such as toast, alert, loading). Most of the scenario plugins are independent of the terminal and can be implemented in C++, while most of the basic plugins are related to the terminal and can be implemented in the languages supported by their respective terminals (such as OC / JAVA / ArkTs).

[0057] The orchestration control unit 1103 is used to perform configuration parsing on the service configurations of each service to determine the plugin set corresponding to each service and perform process orchestration on each plugin in the plugin set.

[0058] After service configuration parsing, it can be determined which plugin or plugins a service corresponds to. Then, through plugin process orchestration (determining the logical relationship between each plugin), multiple plugins are assembled into the corresponding service. In specific implementation, DSL orchestration can be used to assemble plugins into a service.

[0059] The implementation of DSL orchestration generally involves the following key steps: 1. Define the DSL language: According to the scenario requirements, define a DSL language that covers the required security operations and processes. This includes defining grammar rules, operators, functions, etc., so as to clearly express the scenario process. 2. Build a parsing engine: Build a DSL parsing engine to perform semantic parsing and execution on DSL orchestration expressions. The parsing engine is the core of DSL orchestration, and it is responsible for converting DSL scripts into executable instructions or workflows. 3. Build handling capabilities: For different scenarios, build corresponding atomic security handling capabilities or scenario process steps. These capabilities can be custom functions or operations for handling specific scenario logics. 4. Write DSL scripts: Write scripts for automated handling processes using the defined DSL language. These scripts describe the various steps of the scenario process and the logical relationships between them. 5. The engine loads the DSL: After the engine is loaded, it loads the custom DSL script from the database into the memory of the engine and generates a DAG (Directed Acyclic Graph) workflow diagram by parsing the DSL script. This step is the key to converting the DSL script into an executable workflow. Through DSL orchestration, the R & D team can focus more on writing and managing automated handling processes without having to deeply understand the details of the underlying system, thereby improving efficiency, reducing error rates, and accelerating the speed of security incident response and handling. It can be understood that the substantial problem that DSL needs to solve is "dynamic logic loading". Therefore, it is entirely possible to utilize existing languages (such as JavaScript) or take a part of their structures and achieve this goal by dynamically invoking their interpreters (compilers) without creating a new DSL.

[0060] For example, through a DSL orchestration engine, the processes of each plugin in the plugin set are orchestrated to assemble into a service. Among them, the DSL orchestration engine is used to determine one or more of the plugin name, the action after the plugin execution is successful, the action after the plugin execution fails, the input of the plugin, the output of the plugin, global parameters, and / or extension parameters of each plugin. It can be seen that the process of combining atomic plugins into a service can be achieved through the method of DSL orchestration. The core DSLs are action (plugin name), next (what to do after the plugin execution is successful), error (what to do after the plugin execution fails), input (input of the plugin), output (output of the plugin), global (global parameters), extra (extension parameters), etc.

[0061] See Figure 2, which is a schematic diagram of realizing plug-in assembly service by using DSL orchestration. In this example, there are plug-ins A, B, C, D, E, F, and G. Among them, the process logic relationship between each plug-in (the execution order and conditions of plug-ins A, B, C, D, E, F, and G) is determined through DSL orchestration, and thus these plug-ins are assembled into a certain service.

[0062] The service management unit 1104 is used to configure each service. Among them, each service corresponds to a different set of plug-ins based on the service configuration and the process orchestration result, and supports reusing the same plug-in in different services.

[0063] Figure 3 A schematic diagram showing the reuse of the same plug-in in different services is shown. Although Service 1 and Service 2 respectively correspond to different sets of plug-ins (the plug-ins in the set are different or the processes are different), plug-ins A, E, and F are reused in both Service 1 and Service 2, thereby improving the application development efficiency through plug-in reuse.

[0064] So far, after determining which plug-ins a service corresponds to, the plug-ins are assembled into a service through DSL. For example, for the order placement service, it corresponds to plug-ins such as the login plug-in, the loading plug-in, the toast plug-in, the add-to-cart plug-in, and the verification plug-in. By assembling multiple plug-ins into a service, and different services can reuse the same plug-ins, the maximum code reuse is achieved.

[0065] This solution is based on the idea of XaaS. First, each function is split into atomic plug-ins, and then the atomic plug-ins are combined into various services. The caller can call the target service in the way of url, without caring whether the plug-ins corresponding to the service are written in C++ language, or are end-specific languages such as iOS (OC), Android (JAVA), and HarmonyOS (ArkTs). Through the solution of this application embodiment, there is no need to implement any bridging code. For the plug-ins themselves, they can be registered as C++ plug-ins independent of the end, or can be registered as OC, JAVA, and ArkTs plug-ins related to the end, so as to achieve the maximum code reuse and utilize the end characteristics, thereby improving the application development efficiency.

[0066] Next, a specific DSL orchestration example is used to illustrate the plug-in process orchestration in the embodiments of the present application.

[0067] The DSL rules are as follows:

[0068] action: The list of actions to be executed, executed concurrently

[0069] {

[0070] "action": ["A", "B"]

[0071] }

[0072] If there is only one action, it can be "action": ["A"]

[0073] next

[0074] The subsequent process to be executed after the action is completed. Not writing or leaving it empty means there is no subsequent process

[0075] For example:

[0076] {

[0077] "action": ["A", "B"],

[0078] "next": "next1",

[0079] "next": ""

[0080] }

[0081] error

[0082] The process to continue executing after an error occurs during the action execution. Not writing or leaving it empty means there is no subsequent process

[0083] For example:

[0084] {

[0085] "action": ["A", "B"],

[0086] "error": "error1",

[0087] "error": ""

[0088] }

[0089] input

[0090] The parameters that need to be read before the action execution. Input will default to passing the global data and the data of the previous action to the next plugin

[0091] For example:

[0092] {

[0093] "input": [{

[0094] "stop_id": "global.restaurant_id",

[0095] "sku_id": "B.sku_id"

[0096] }],

[0097] "action": ["A"],

[0098] }

[0099] extra

[0100] In some scenarios, there are some fixed parameters that do not need to be passed in the previous step and can be written in the form of extra.

[0101] The container will be merged with the input (if the KEYs are repeated, the input ones will prevail).

[0102] For example:

[0103] {

[0104] "extra": [{

[0105] "scene_name": "wm_sku"

[0106] }],

[0107] "action": ["A"],

[0108] }

[0109] output

[0110] After the action is executed, a data area for this plugin will be created by default. When writing data to other data areas, output can be used to write or overwrite data in other data areas.

[0111] For example:

[0112] {

[0113] {

[0114] "action": ["A"],

[0115] "output": [{

[0116] "stop_id": "global.restaurant_id", / / Write or overwrite

[0117] }]

[0118] }

[0119] global

[0120] Global data, which is defaulted to the parameters passed in the scheme and can be written or overwritten through output.

[0121] For example, replacing the store ID, etc.

[0122] {

[0123] "output": [{"

[0124] "stop_id": "global.restaurant_id",

[0125] }],

[0126] "action": ["A"],

[0127] }

[0128] Other DSL

[0129] version version number

[0130] root The first process to be executed

[0131] DEMO:

[0132] Services A and B are executed simultaneously. If one execution fails, execute D; if both executions succeed, execute C.

[0133] {

[0134] "version": "1",

[0135] "root": {

[0136] "action": ["A", "B"],

[0137] "error": "error1",

[0138] "next": "next1"

[0139] },

[0140] "error1": {

[0141] "input": [{"

[0142] "key": "KeyA"

[0143] }],

[0144] "action": ["D"],

[0145] "error": ""

[0146] },

[0147] "next1": {

[0148] "input": [{"

[0149] "key": "KeyA"

[0150] }],

[0151] "action":["C"]

[0152] }

[0153] }

[0154] The following DSLs are the scheduling tasks for "Add to Cart and Place Order" and "Instant Add to Cart" respectively.

[0155] The configuration of the "Add to Cart and Place Order" scheduling task is as follows:

[0156] {"version":"7","root":{"action":["login"],……"action":["toast","remind"],”””””“”“”””……"action":["deletefoods"]},……"action":["adddelete"],……"next":"flow_add_invalidfoods"},……"flow_checkout":{"action":["checkout"],"error":"flow_catering"},"flow_catering":{"action":["catering"],"error":"flow_catering_error"}}

[0157] The configuration of the "Instant Add to Cart" scheduling task is as follows:

[0158] {"version":"3","root":{"action":["multispecs"],……"flow_add":{"action":["adddelete"],"next":"flow_invalidfoods","error":"flow_toast"},"flow_toast":{"action":["toast"],"next":"flow_deletefoods"},"flow_invalidfoods":{"input":[{"theme_color":"adddelete.theme_color",……"flow_add_finish":{"input":[{"records":"adddelete.records"}],"action":["addfinish"]}}

[0159] The above two DSLs represent different tasks. Among them, plugins such as adddelete, toast, invalidfoods, and deletefoods are reused. Thus, through the DSL orchestration method, some plugins are directly reused, achieving the maximum code reuse.

[0160] See Figure 4 , an embodiment of the present application provides a multi-terminal application development method for developing applications adapted to multi-terminal reuse. The method includes:

[0161] S401: Based on the local configuration or the configuration dynamically published in the cloud, perform service configuration and function configuration;

[0162] S402: Based on the function configuration, perform plugin processing on each atomic function of the basic function or extended function to obtain each atomic plugin;

[0163] S403: Perform configuration parsing on the service configuration of each service to determine the plugin set corresponding to each service, and perform process orchestration on each plugin in the plugin set;

[0164] S404: Configure each service, where each service corresponds to a different plugin set based on the service configuration and the process orchestration result, and supports reusing the same plugin in different services.

[0165] In one implementation, the plugins managed by the plugin management unit include basic plugins or extended plugins. Among them, the basic plugins are written in a first programming language related to the terminal characteristics, and the extended plugins are written in a second programming language independent of the terminal characteristics.

[0166] In one implementation, the plugin includes at least one of a login plugin, a pop-up window plugin, an add-to-cart plugin, a loading plugin, a message prompt plugin, and a specification panel plugin.

[0167] In one implementation, the process orchestration of each plugin in the plugin set includes: Based on the DSL orchestration engine, perform process orchestration on each plugin in the plugin set to assemble into a service, where the DSL orchestration engine is used to determine one or more of the plugin name, the action after the plugin execution is successful, the action after the plugin execution fails, the input of the plugin, the output of the plugin, global parameters, and / or extended parameters of each plugin.

[0168] See Figure 5, which shows a schematic diagram of multi - terminal application development and invocation in an embodiment of the present application. Among them, the invoker can be various invokers in various scenarios, such as invokers in scenarios like conference venues and large promotions. Through an invocation protocol (such as JSAPI, Mist - Action, scheme), a service invocation request is sent to the terminal service - oriented engine, and this request is routed to the service management unit by the service routing unit. The service management unit maintains multiple services: Service 1, Service 2, and so on. Each service is completed according to the service configuration in the configuration management unit. Various services can be invoked in the form of a common url provided externally. For example, the url provided by Service 1 is cart / add, and the url provided by Service 2 is cart / quickbuy, and so on. The service routing unit routes out the target service (such as Service i) according to the invocation request, and then the service management unit drives the orchestration control unit for the target service. The orchestration control unit performs configuration parsing, data flow, and service orchestration. That is, through the service configuration of the target service, the corresponding target plugin set is determined, each plugin is called from the plugin management unit, and process orchestration is performed on each plugin. Then the orchestration control unit makes a service callback to the service management unit, thereby completing the callback to the invoker. In addition, the registration management unit responds to an external function registration request, completes basic function registration and extended function registration, and performs plugin - based processing on the registered functions to obtain atomic plugins one by one, which are managed by the plugin management unit relying on a container for function runtime (such as Native, etc.); in addition, the configuration management unit is used to perform service configuration for the service management unit and function configuration for the plugin management unit. Among them, both service configuration and function configuration can obtain configuration information through local built - in or server - side dynamic publishing.

[0169] Corresponding to the above - mentioned multi - terminal application development system, an embodiment of the present application further provides a multi - terminal application invocation system for invoking a target application adapted to multi - terminal reuse. The system includes a terminal service - oriented engine, and the terminal service - oriented engine includes:

[0170] A configuration management unit, which is used to perform service configuration and function configuration based on local configuration or cloud - dynamically published configuration;

[0171] A plugin management unit, which, based on the function configuration, performs plugin - based processing on each atomic function of the basic function or extended function to obtain each atomic plugin;

[0172] A service routing unit, which is used to communicate with the invoker, receive the service invocation request of the invoker for the target service, and complete the service callback based on the target service invocation result;

[0173] A service management unit, which is used to configure multiple services based on the service configuration and drive for the target service;

[0174] An orchestration control unit is used to perform configuration parsing for the driving of a target service to determine a target plugin set corresponding to the target service, perform callbacks and process orchestration on each plugin in the target plugin set, and return the orchestration result to the service management unit and the service routing unit to complete service callbacks. Each service corresponds to a different plugin set based on the service configuration and the process orchestration result, and supports the reuse of the same plugin in different services.

[0175] See Figure 6 , an embodiment of the present application provides a multi-terminal application calling method for calling a target application adapted to multi-terminal reuse. The method includes:

[0176] S601: In response to a service call request from a caller for a target service, perform configuration parsing of the target service based on a local configuration or a service configuration dynamically published in the cloud to determine a target plugin set corresponding to the target service;

[0177] S602: Perform callbacks and process orchestration on each plugin in the target plugin set, and return the orchestration result to the caller to complete service callbacks;

[0178] Among them, based on a local configuration or a function configuration dynamically published in the cloud, each atomic function of a basic function or an extended function is pluginized to obtain each atomic plugin;

[0179] Among them, each service corresponds to a different plugin set based on the service configuration and the process orchestration result, and supports the reuse of the same plugin in different services.

[0180] An embodiment of the present application also provides an application. Among them, the application is developed based on the foregoing multi-terminal application development method or the foregoing multi-terminal application development system. The specific implementation principle and process can refer to the foregoing description and will not be elaborated here.

[0181] It can be seen that the multi-terminal application development and calling solution provided by the embodiment of the present application splits the code into the smallest atomic plugins, combines the plugins into various services in the form of DSL orchestration, and provides a general URL method for external calls. The caller does not need to implement any bridging code and can call any service composed of plugins implemented in any language through any language and any terminal. The caller and the callee are completely decoupled, and are also completely decoupled from the terminal and the language, realizing a simple and clean code reuse ability.

[0182] An embodiment of the present application also provides a storage medium in which a computer program is stored. Among them, the computer program is set to execute the steps in any one of the foregoing method embodiments when running.

[0183] Optionally, in this embodiment, the above storage medium may be configured to store a computer program for performing the following steps:

[0184] Perform service configuration and function configuration based on local configuration or cloud-dynamically published configuration;

[0185] Based on the function configuration, pluginize each atomic function of the basic function or extended function to obtain each atomic plugin;

[0186] Perform configuration parsing on the service configuration of each service to determine the plugin set corresponding to each service, and perform process orchestration on each plugin in the plugin set;

[0187] Configure each service, where each service corresponds to a different plugin set based on the service configuration and process orchestration result, and supports reusing the same plugin in different services; or,

[0188] In response to a service call request from a caller for a target service, perform configuration parsing of the target service based on local configuration or cloud-dynamically published service configuration to determine the target plugin set corresponding to the target service;

[0189] Perform callback and process orchestration on each plugin in the target plugin set, and return the orchestration result to the caller to complete the service callback,

[0190] Wherein, based on local configuration or cloud-dynamically published function configuration, pluginize each atomic function of the basic function or extended function to obtain each atomic plugin;

[0191] Where each service corresponds to a different plugin set based on the service configuration and process orchestration result, and supports reusing the same plugin in different services.

[0192] Optionally, in this embodiment, the above storage medium may include but is not limited to: various media that can store computer programs such as USB flash drives, read-only memory (ROM for short), random access memory (RAM for short), mobile hard disks, magnetic disks, or optical discs.

[0193] An embodiment of the present application further provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0194] Optionally, the above electronic device may further include a transmission device and an input / output device, where the transmission device is connected to the above processor, and the input / output device is connected to the above processor.

[0195] Optionally, in this embodiment, the above-mentioned processor may be configured to execute the following steps through a computer program:

[0196] Based on the local configuration or the configuration dynamically published by the cloud, perform service configuration and function configuration;

[0197] Based on the function configuration, perform plug-in processing on each atomic function of the basic function or the extended function to obtain each atomic plug-in;

[0198] Perform configuration parsing on the service configuration of each service to determine the plug-in set corresponding to each service, and perform process orchestration on each plug-in in the plug-in set;

[0199] Configure each service, where each service corresponds to a different plug-in set based on the service configuration and the process orchestration result, and supports the reuse of the same plug-in in different services; or,

[0200] In response to a service call request from a caller for a target service, based on the local configuration or the service configuration dynamically published by the cloud, perform configuration parsing on the target service to determine the target plug-in set corresponding to the target service;

[0201] Perform callback and process orchestration on each plug-in in the target plug-in set, and return the orchestration result to the caller to complete the service callback.

[0202] Among them, based on the function configuration locally configured or dynamically published by the cloud, perform plug-in processing on each atomic function of the basic function or the extended function to obtain each atomic plug-in;

[0203] Among them, each service corresponds to a different plug-in set based on the service configuration and the process orchestration result, and supports the reuse of the same plug-in in different services.

[0204] Optionally, specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and will not be elaborated here.

[0205] The serial numbers of the embodiments of the present application above are only for description and do not represent the advantages or disadvantages of the embodiments.

[0206] In the above embodiments of the present application, the descriptions of each embodiment have their own focuses. For the parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0207] In several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections between each other can be through some interfaces. The indirect couplings or communication connections of units or modules can be in electrical or other forms.

[0208] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place, or they can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0209] In addition, in each embodiment of this application, each functional unit can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0210] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of this application. The foregoing storage medium includes: various media such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs that can store program codes.

[0211] The above is only the preferred embodiment of this application. It should be noted that for those of ordinary skill in the art, without departing from the principle of this application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of this application.

Claims

1. A multi-terminal application development system, characterized in that: Used for application development adapted to multi-terminal reuse, the system includes a terminal service engine, the terminal service engine provides bridging capabilities of various languages ​​of different operating systems to support different operating system clients to develop applications in the same development system, the languages ​​include OC, JAVA or ArkTs, and the terminal service engine includes: The service routing unit is used to receive service call requests initiated by the call protocol based on JSAPI, Mist-Action or scheme from the caller, where various services can be called by providing a common URL to the outside world; Configuration management unit, used to configure services and functions based on local configuration or configuration dynamically published in the cloud; A registration management unit is used to respond to external function registration requests, complete basic function registration and extended function registration, and process the registered functions into plug-ins to obtain atomic plug-ins, wherein the atomic plug-ins are registered as different end-feature plug-ins according to their function types: the scene plug-in is registered as an end-independent public plug-in, and the basic plug-in is registered as an end-related end-feature plug-in, wherein the public plug-in is implemented in C++, and the end-feature plug-in is implemented in OC, JAVA or ArkTs to provide the bridging capability; A plug-in management unit manages the atomic plug-in based on the function configuration and relying on the Native container or Weex container during function runtime; The orchestration control unit is used to perform configuration analysis on the service configuration of each service to determine the plug-in set corresponding to each service and perform process orchestration on each plug-in in the plug-in set; The service management unit is used to configure each service, where each service corresponds to a different set of plug-ins based on the service configuration and process orchestration results, and supports reusing the same plug-in in different services.

2. The system according to claim 1, characterized in that The scenario plug-ins include purchase plug-ins, pop-up plug-ins, and login plug-ins; the basic plug-ins include loading plug-ins, message prompt plug-ins, or specification panel plug-ins.

3. The system according to any one of claims 1 to 2, characterized in that: The orchestration control unit is specifically used to perform process orchestration on each plug-in in the plug-in set based on the DSL orchestration engine to assemble into a service, wherein the DSL orchestration engine is used to determine one or more of the plug-in name, action after successful execution of the plug-in, action after failed execution of the plug-in, plug-in input, plug-in output, global parameters and / or extended parameters of each plug-in.

4. A multi-terminal application development method, characterized in that: Used to develop applications suitable for multi-terminal reuse, providing bridging capabilities of various languages ​​of different operating systems through a terminal service engine to support different operating system clients to develop applications in the same development system, wherein the languages ​​include OC, JAVA or ArkTs, and the method includes: Receive service call requests from the caller based on JSAPI, Mist-Action or scheme-based call protocols, where various services can be called by providing a common URL to the outside world; Perform service and function configuration based on local configuration or configuration dynamically published in the cloud; Respond to external function registration requests, complete basic function registration and extended function registration, and process the registered functions into plug-ins to obtain atomic plug-ins, wherein the atomic plug-ins are registered as different end-feature plug-ins according to their function types: the scene plug-in is registered as an end-independent public plug-in, and the basic plug-in is registered as an end-related end-feature plug-in, wherein the public plug-in is implemented in C++, and the end-feature plug-in is implemented in OC, JAVA or ArkTs to provide the bridging capability; Based on the function configuration, the atomic plug-in is managed by relying on the Native container or Weex container during function runtime; Perform configuration analysis on the service configuration of each service to determine the plug-in set corresponding to each service, and perform process orchestration on each plug-in in the plug-in set; Each service is configured, wherein each service corresponds to a different plug-in set based on the service configuration and process orchestration result, and supports reusing the same plug-in in different services.

5. The method according to claim 4, characterized in that The scenario plug-ins include purchase plug-ins, pop-up plug-ins, and login plug-ins; the basic plug-ins include loading plug-ins, message prompt plug-ins, or specification panel plug-ins.

6. The method according to any one of claims 4-5, characterized in that: The process arrangement of each plug-in in the plug-in set includes: Based on the DSL orchestration engine, the processes of the plug-ins in the plug-in set are orchestrated to assemble into services, wherein the DSL orchestration engine is used to determine one or more of the plug-in name, the action after the plug-in is successfully executed, the action after the plug-in fails to execute, the input of the plug-in, the output of the plug-in, the global parameters and / or the extended parameters of each plug-in.

7. A multi-terminal application calling system, characterized in that: The system is used to call a target application adapted to multi-terminal multiplexing. The system includes a terminal service engine, which provides a bridging capability for various languages ​​of different operating systems to support different operating system clients to develop applications in the same development system. The languages ​​include OC, JAVA or ArkTs. The terminal service engine includes: The service routing unit is used to receive service call requests initiated by the call protocol based on JSAPI, Mist-Action or scheme from the caller, where various services can be called by providing a common URL to the outside world; Configuration management unit, used to configure services and functions based on local configuration or configuration dynamically published in the cloud; A registration management unit is used to respond to external function registration requests, complete basic function registration and extended function registration, and process the registered functions into plug-ins to obtain atomic plug-ins, wherein the atomic plug-ins are registered as different end-feature plug-ins according to their function types: the scene plug-in is registered as an end-independent public plug-in, and the basic plug-in is registered as an end-related end-feature plug-in, wherein the public plug-in is implemented in C++, and the end-feature plug-in is implemented in OC, JAVA or ArkTs to provide the bridging capability; A plug-in management unit manages the atomic plug-in based on the function configuration and relying on the Native container or Weex container during function runtime; The service routing unit is used to communicate with the caller, receive the service call request of the caller for the target service, and complete the service callback based on the target service call result; A service management unit, configured to complete multiple services based on the service configuration, and drive a target service; The orchestration control unit is used to perform configuration analysis on the driver of the target service to determine the target plug-in set corresponding to the target service, and to call back and orchestrate the processes of each plug-in in the target plug-in set, and return the orchestration results to the service management unit and the service routing unit to complete the service callback. Each service corresponds to a different plug-in set based on the service configuration and process orchestration results, and supports the reuse of the same plug-in in different services.

8. A multi-terminal application calling method, characterized in that: It is used to call the target application adapted to multi-terminal multiplexing, and provide the bridging capability of different operating systems and various languages ​​through the terminal service engine to support different operating system clients to develop applications in the same development system, wherein the languages ​​include OC, JAVA or ArkTs, and the method includes: In response to a service call request initiated by the caller for the target service based on the JSAPI, Mist-Action or scheme call protocol, where various services can provide a common URL for external calls, the configuration of the target service is parsed based on the local configuration or the service configuration dynamically published in the cloud to determine the target plug-in set corresponding to the target service; Call back and orchestrate the processes of each plug-in in the target plug-in set, and return the orchestration results to the caller to complete the service callback; Among them, respond to external function registration requests, complete basic function registration and extended function registration, and process the registered functions into plug-ins to obtain atomic plug-ins, wherein different end-feature plug-ins are registered according to the function type of the atomic plug-in: the scene plug-in is registered as an end-independent public plug-in, and the basic plug-in is registered as an end-related end-feature plug-in, wherein the public plug-in is implemented in C++, and the end-feature plug-in is implemented in OC, JAVA or ArkTs to provide the bridging capability; based on local configuration or configuration dynamically published in the cloud, service configuration and function configuration are performed, and based on the function configuration, the atomic plug-in is managed by relying on the Native container or Weex container at the function runtime; Each service corresponds to a different set of plug-ins based on service configuration and process orchestration results, supporting the reuse of the same plug-in in different services.

9. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 4-6 and 8 when running.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method described in any one of claims 4-6 and 8.

Images