WO2023185166A1 - Service call method and apparatus, device and storage medium - Google Patents

Abstract

Embodiments of the present application disclose a service call method and apparatus, a device and a storage medium, relating to the technical field of computers. The method comprises: a first device recognizing a first input instruction, to obtain a first instruction recognition result (201); generating a service call request on the basis of the first instruction recognition result (202), the service call request being used to request that a second device call a target service to execute a target action; sending the service call request to the second device (203), so as to cause the second device to deploy the target service on the basis of a target service installation package, and call the target service to execute the target action (207), the target service installation package being obtained from a server.

Description

Service invocation methods, devices, equipment and storage media

This application claims priority to the Chinese patent application with application number 202210334389.8 and the invention title "Service Invoking Method, Device, Equipment and Storage Medium" submitted on March 30, 2022, the entire content of which is incorporated into this application by reference. .

Technical field

The embodiments of the present application relate to the field of computer technology, and in particular to a service invoking method, device, equipment and storage medium.

Background technique

Command control is a technology that recognizes and analyzes user commands and controls the device to perform corresponding operations based on the recognition and analysis results. Common command controls include gesture control, voice control, etc.

In related technologies, computer equipment needs to have a command recognition function, and corresponding services need to be pre-deployed before the command control function can be realized. For example, only when the vehicle-mounted terminal has speech recognition and is equipped with a video playback function, the video can be played according to the voice instructions issued by the user.

Contents of the invention

Embodiments of the present application provide a service invoking method, device, equipment and storage medium. The technical solutions are as follows:

On the one hand, embodiments of the present application provide a service invoking method, which is executed by a first device. The method includes:

Recognize the first input instruction and obtain the first instruction recognition result;

Generate a service call request based on the first instruction recognition result, the service call request is used to request the second device to call the target service to perform the target action;

Send the service invocation request to the second device, so that the second device deploys the target service based on the target service installation package and calls the target service to perform the target action, and the target service installation package is downloaded from the server get.

On the other hand, embodiments of the present application provide a service invoking method, which is executed by a second device. The method includes:

Receive a service invocation request sent by the first device, the service invocation request is used to request to call a target service to perform a target action, the service invocation request is generated by the first device based on the first instruction recognition result of the first input instruction. ;

Obtain the target service installation package of the target service from the server based on the service invocation request;

Deploy the target service based on the target service installation package;

Call the target service to perform the target action.

On the other hand, embodiments of the present application provide a service invoking device, which includes:

An instruction identification module, used to identify the first input instruction and obtain the first instruction identification result;

A request generation module, configured to generate a service invocation request based on the first instruction recognition result, the service invocation request being used to request the second device to invoke the target service to perform the target action;

A request sending module, configured to send the service invocation request to the second device, so that the second device deploys the target service based on the target service installation package and calls the target service to perform the target action, so The above target service installation package is obtained from the server.

On the other hand, embodiments of the present application provide a service invoking device, which includes:

A request receiving module, configured to receive a service invocation request sent by the first device. The service invocation request is used to request the invocation of a target service to perform a target action. The service invocation request is generated by the first device based on a response to a first input instruction. The first instruction recognition result is generated;

An installation package acquisition module, configured to obtain the target service installation package of the target service from the server based on the service invocation request;

A service deployment module, configured to deploy the target service based on the target service installation package;

An execution module is used to call the target service to execute the target action.

On the other hand, embodiments of the present application provide a computer device. The computer device includes a processor and a memory; the memory stores at least one instruction, and the at least one instruction is used to be executed by the processor to implement the following: The service calling method described in the above aspects.

On the other hand, embodiments of the present application provide a computer-readable storage medium in which at least one program code is stored, and the program code is loaded and executed by a processor to implement the above aspects. service calling method.

On the other hand, embodiments of the present application provide a computer program product or computer program. The computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service invocation method provided in various optional implementations of the above aspect.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative efforts.

Figure 1 shows a system architecture diagram of a service invocation system provided by an exemplary embodiment of the present application;

Figure 2 shows a flow chart of a service invoking method provided by an exemplary embodiment of the present application;

Figure 3 shows a schematic implementation diagram of a service invoking method provided by an exemplary embodiment of the present application;

Figure 4 shows a schematic diagram of the service definition and installation package upload process provided by an exemplary embodiment of the present application;

Figure 5 shows a flow chart of a service invoking method provided by another exemplary embodiment of the present application;

Figure 6 shows a flow chart of a text parsing process provided by an exemplary embodiment of the present application;

Figure 7 shows a schematic diagram of the implementation of the service dynamic deployment process provided by an exemplary embodiment of the present application;

Figure 8 shows an implementation schematic diagram of the service update process provided by an exemplary embodiment of the present application;

Figure 9 shows a flow chart of the service offloading process provided by an exemplary embodiment of the present application;

Figure 10 shows a schematic diagram of the implementation of the service offloading process provided by an exemplary embodiment of the present application;

Figure 11 shows a structural block diagram of a service invoking device provided by an embodiment of the present application;

Figure 12 shows a structural block diagram of a service invoking device provided by another embodiment of the present application;

Figure 13 shows a structural block diagram of a computer device provided by an exemplary embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

To facilitate understanding, the terms involved in the embodiments of this application are described below.

Service: The smallest unit used to implement a specific task. For example, the screen capture service is used to implement the device screen capture function, the video playback service is used for video playback, and so on. Moreover, when making service calls, the device can call services deployed locally or services deployed on other devices (i.e., cross-end calls). For example, the first device can call the local video playback service to play the video, or can call the video playback service of the second device to realize video playback on the second device.

Unlike traditional services that require pre-deployment (if not deployed, corresponding functions cannot be implemented), the services involved in the embodiments of this application support dynamic deployment. When receiving a service invocation request, if the corresponding service is deployed locally, it will be called directly; if the corresponding service is not deployed locally, the service installation package can be obtained dynamically, and the service deployment is completed based on the service installation package. In addition, unlike traditional services that require manual installation or uninstallation, the service in the embodiment of the present application supports automatic uninstallation, which simplifies the service installation and uninstallation operation process.

In some embodiments, services may include static services and dynamic services. Static services refer to services provided by host applications and need to be pre-installed in the device, while dynamic services refer to services that support dynamic deployment and can be used during the calling process. Dynamically deployed in the device. Optionally, the service installation package of the dynamic service is stored in the server, and the device can download the service installation package from the server.

Figure 1 shows a system structure diagram of a service invocation system provided by an exemplary embodiment of the present application. The system includes a first device 110, a second device 120 and a server 130.

The first device 110 is an electronic device with an instruction recognition function. The instruction recognition function may be a voice recognition function, a gesture recognition function, a text recognition function, etc., and the electronic device may be a smartphone, a tablet computer, a wearable device, a personal computer, a vehicle-mounted terminal, etc. This implementation does not limit this .

In some embodiments, with the help of the speech recognition function, the first device 110 can convert the input speech into speech text through the speech recognition module 111, and parse the speech text through the text parsing module 112 to obtain a speech recognition result (used to characterize user intent).

Further, when the voice recognition result indicates that the service of the external device is called so that the external device performs a specific action, the first device 110 determines the external device that needs to be called (ie, the second device 120 in the figure) through the device selection module 113, And generate a service call request based on the speech recognition result, thereby sending the service call request to the external device. The number of external devices is at least one.

The second device 120 is an electronic device that supports dynamic deployment services. The electronic device may be a smartphone, a tablet, a wearable device, a personal computer, a vehicle-mounted terminal, etc., which is not limited in this implementation.

In some embodiments, the second device 120 is provided with a service proxy 121. When the service proxy 121 receives the service invocation request sent by the first device 110, it first queries through the service management module 122 whether there is a service invocation request deployed locally. First service as indicated. The service life cycle management module 123 is used to manage the life cycle of each service in the device. If the target service is deployed, the service life cycle management module 123 controls the service execution module 125 to call the target service to perform specific actions. If the target service is not deployed, the service management module 122 downloads the service installation package corresponding to the target service from the server 130 and stores it locally; the service installation module 124, under the control of the service life cycle management module 123, deploys according to the service installation package target service. In addition to controlling service installation and execution, the service life cycle management module 123 also controls the service uninstall module 126 to uninstall deployed services according to policies to avoid deploying too many services on the device.

The server 130 is a server, a service cluster or a cloud computing center composed of several servers. Divided according to the functions implemented, the server 130 includes a service definition management module 131, a service installation package management module 132, a subscription management module 133, a device management module 134 and a service gateway 135.

The service gateway 135 serves as an entrance for interaction between external devices and servers, and is used to dynamically route incoming traffic to designated management modules.

The service definition management module 131 is used to manage the service definition information of the service developed by the developer, and associate the service definition information with the corresponding service installation package, so that the corresponding service installation package can be subsequently obtained based on the service definition information.

The service installation package management module 132 is used to manage service installation packages of services developed by developers, and store the service installation packages in the file warehouse.

The subscription management module 123 is used to manage the subscription relationship between the device and the service, so as to subsequently control the device to perform service updates based on the subscription relationship.

The device management module 134 is used to manage the binding relationship between accounts and devices, as well as the device status of each device, and provide device selection basis for the device selection module 113 on the first device 110 side.

It should be noted that the above embodiment only describes the infrastructure of the service invocation system. The system may also include other computer equipment (such as developer equipment) or servers that implement other functions. This embodiment does not constitute a limitation on this. .

Please refer to Figure 2, which shows a flow chart of a service invocation method provided by an exemplary embodiment of the present application. This embodiment of the present application takes the application of this method to the service invocation system shown in Figure 1 as an example. The method includes :

Step 201: The first device recognizes the first input command and obtains the first command recognition result.

Optionally, the first input instruction may be a voice instruction, a gesture instruction, a text instruction, etc. The embodiment of the present application does not limit the form of the input instruction.

In some embodiments, the first device has a voice collection function. When the first input voice is collected through a voice collection device such as a microphone, the first device performs voice recognition on the first input voice to obtain the first voice recognition result. The first speech recognition result is used to characterize the speech control intention. Regarding the speech recognition process, in a possible implementation, the first device first converts the input speech into speech text, then parses the speech text, and determines the parameters required to generate the service call request as the speech recognition result.

In other embodiments, the first device has an image acquisition function. When the first gesture is acquired through an image acquisition device such as a camera, the first device performs gesture recognition on the first gesture, thereby based on the interaction between the gesture and the control instruction. The mapping relationship is used to obtain a first gesture recognition result, and the first gesture recognition result is used to represent the control intention represented by the gesture.

In other embodiments, the first device has a text input function. When the first input text input by the user is obtained through the text input component, the first device recognizes the first input text and obtains the first text recognition result. The first text recognition result is used to characterize the control intention of the input text.

Optionally, the first instruction recognition result includes parameters required to generate a service invocation request.

Step 202: The first device generates a service invocation request based on the first instruction recognition result.

Wherein, the service invocation request is used to request the second device to invoke the target service to perform the target action.

In a possible implementation, the service invocation request may be a service invocation URL. The embodiment of this application does not limit the specific form of the service invocation request.

Schematically, as shown in Figure 3, the smartphone 31 generates a service call request based on the speech recognition result of "play xxx video on the car machine". The service call request is used to request the car machine to call the video playback service to play the xxx video.

Step 203: The first device sends a service invocation request to the second device.

In a possible implementation, after determining the second device that needs to be called, the first device obtains the device address of the second device, and then sends a service invocation request to the second device based on the device address.

In some embodiments, when the number of second devices is at least two, the first device sends a service invocation request to each second device, where different second devices correspond to different service invocation requests (some parameters in the requests are different, But they are all used to call the same service to perform the same action).

Schematically, as shown in Figure 3, the smart phone 31 sends a service invocation request to the car machine 32.

Step 204: The second device receives the service invocation request sent by the first device.

In a possible implementation, the second device receives the service invocation request through a service proxy.

In some embodiments, the second device verifies the service invocation request, and further responds to the service invocation request after passing the verification. The verification methods include request integrity verification, call requester verification, parameter compliance verification, etc., which are not limited in the embodiments of this application.

Optionally, after receiving the service invocation request, the second device automatically determines whether to accept the request, or determines whether to accept the request based on user instructions. If the request is accepted, step 205 is executed; if the request is not accepted, the process ends (a call rejection notification may be sent to the first device).

Step 205: The second device obtains the target service installation package of the target service from the server based on the service invocation request.

In a possible implementation, the second device detects whether the target service indicated by the service invocation request is deployed. If the target service is deployed, the service call is made; if the target service is not deployed, the target service needs to be dynamically deployed first.

When dynamically deploying the target service, the second device first obtains the target server installation package of the target service from the server. Among them, the server is provided with a file warehouse, which contains service installation packages for dynamic services that implement different functions and support dynamic deployment.

Regarding the source of services in the server, in one possible implementation, the service support is developed by developers and uploaded to the server.

As shown in FIG. 4 , the developer calls the upload interface of the service installation package management module 132 through the service gateway 135 of the server 130 to upload the service installation package to the server 130 . The successfully uploaded service installation package is associated with a unique installation package identification and stored in the file warehouse. The service installation package management module 132 feeds back the installation package identification to the developer.

Further, the developer associates the service definition information of the service with the installation package identifier, and then calls the upload interface of the service definition management module 131 through the service gateway 135 to save the service definition information in the server 130 .

In a possible implementation, the second device sends an installation package acquisition request to the server. After receiving the request, the service gateway of the server routes the request to the service installation package management module and obtains the target service installation package from the file warehouse. , thereby feeding back the target service installation package to the second device.

Schematically, as shown in FIG. 3 , when the video playback service is not deployed, the car machine 32 downloads the video playback service installation package from the server 33 .

Step 206: The second device deploys the target service based on the target service installation package.

In a possible implementation, the second device verifies the obtained target service installation package, and after passing the verification, dynamically deploys the target service based on the target service installation package.

Step 207: The second device calls the target service to perform the target action.

Further, the second device determines the target action indicated by the service invocation request, and thereby calls the target service to perform the target action.

Schematically, as shown in Figure 3, the vehicle computer 32 determines that the target action is "play xxx video", thereby calling the video playback service to play the xxx video.

It can be clearly seen from the embodiment shown in Figure 3 that when the vehicle machine does not have a voice control function, a smartphone with a voice recognition function can also be used as a dispatch center to realize voice calls to in-car services; in When the car machine has a voice control function, it can avoid the impact on other services when the car machine frequently performs voice recognition (the performance of the car machine is usually lower than that of a smartphone, and the car machine needs to call important functions related to vehicle driving in real time. Serve). In addition, the vehicle machine can dynamically deploy services after receiving a service call request, which can avoid content occupation caused by pre-deployment of services (especially some services with low frequency of use).

To sum up, in the embodiment of the present application, the first device with the command recognition function recognizes the input command, and sends a service invocation request to the second device based on the command recognition result, instructing the second device to call the target service to execute the target. The action enables the second device to obtain the target service installation package from the server and deploy the target service based on the service invocation request, thereby calling the target service to perform the target action. Using the solution provided by the embodiments of this application, even if the second device does not have the command recognition function, service invocation based on instructions can be realized, and the second device can dynamically deploy the target service based on the service invocation request, avoiding the problem of pre-deployment of a large number of services. memory usage.

Optionally, generate a service invocation request based on the first instruction recognition result, including:

Based on the target device name included in the first instruction recognition result, obtain the device address of at least one candidate device from the server, and the candidate device matches the target device name;

determining a second device from at least one candidate device;

Generate a service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction recognition result;

Send a service call request to the second device, including:

Based on the device address of the second device, a service invocation request is sent to the second device.

Optionally, generate a service invocation request based on the first instruction recognition result, including:

Based on the target device name included in the first instruction recognition result, obtain the device address of at least one candidate device from the server, and the candidate device matches the target device name;

determining a second device from at least one candidate device;

Generate a service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction recognition result;

Send a service call request to the second device, including:

Based on the device address of the second device, a service invocation request is sent to the second device.

Optionally, this method also includes:

Recognize the second input instruction and obtain the second instruction recognition result;

Generate a service uninstallation request based on the second instruction recognition result, and the service uninstallation request is used to request the second device to uninstall the target service;

Send a service uninstallation request to the second device, so that the second device uninstalls the target service.

Optionally, generate a service uninstallation request based on the second instruction recognition result, including:

Based on the target device name and the target service name included in the second instruction recognition result, obtain the device address of at least one candidate device from the server, the candidate device matches the target device name and is deployed with the target service;

determining a second device from at least one candidate device;

Generate a service uninstallation request based on the device address of the second device and the target service name;

Send a service uninstallation request to the second device, including:

Based on the device address of the second device, a service uninstallation request is sent to the second device.

Optionally, obtain the target service installation package of the target service from the server based on the service call request, including:

Based on the target service name included in the service call request, obtain the target service definition information of the target service from the server;

When it is determined that the target service installation package does not exist locally based on the target service definition information, the target service installation package is obtained from the server based on the target service definition information. The server stores the correspondence between the service definition information and the service installation package.

Optionally, this method also includes:

A subscription message is sent to the server, and the server is used to maintain the subscription relationship between the second device and the target service based on the subscription message.

Optionally, this method also includes:

Receive service update messages sent by the server. The service update messages are pushed by the server based on the subscription relationship when the target service installation package is updated;

Obtain the updated target service installation package from the server based on the service update message.

Optionally, this method also includes:

When the target service is uninstalled, a subscription cancellation message is sent to the server, and the server is used to delete the subscription relationship based on the subscription cancellation message.

Optionally, this method also includes:

Receive a service uninstallation request sent by the first device, the service uninstallation request is used to request the second device to uninstall the target service, and the service uninstallation request is generated by the first device based on the second instruction recognition result of the second input instruction;

Uninstall the target service based on the service uninstallation request.

Optional, uninstall target services based on service uninstallation requests, including:

Based on the target service name included in the service uninstallation request, obtain the target service definition information of the target service from the server;

Uninstall the target service based on the target service definition information, and delete the locally stored target service installation package.

Optionally, this method also includes:

The target service is uninstalled when the automatic uninstallation conditions are met. The automatic uninstallation conditions include at least one of the following: the number of calls to the target service reaches the number threshold, the target service is not called within the target duration, and the deployment duration of the target service reaches the duration threshold.

Please refer to Figure 5, which shows a flow chart of a service invocation method provided by another exemplary embodiment of the present application. This embodiment of the present application takes the application of this method to the service invocation system shown in Figure 1 as an example to illustrate the method. include:

Step 501: The first device recognizes the first input command and obtains the first command recognition result.

Optionally, the first instruction identification result includes the target device name of the device to be called, the target service name of the target service to be called, and the target action name of the target action.

In a possible implementation, as shown in FIG. 6 , text parsing is first pre-configured in the first device, so that text parsing is performed based on the pre-configured content during the application process.

Among them, the content configured during the text parsing preconfiguration process includes intent dictionary, intent slot, intent corpus, and intent reply.

Among them, the intent dictionary contains key-value pairs with the subject word as the key and a set of synonym lists as the value. For example, there are three intent dictionaries configured. The key of intent dictionary 1 is the device name, and the value is the synonym list of the device name (for example, the key is the car machine, the valve is the vehicle terminal, the driving computer, etc.); the key of intent dictionary 2 is the device name. The service name of the service that needs to be called, and the value is the synonym list of the service name (for example, the key is the video playback service, and the value is open, show, etc.); the key of the intent dictionary 3 is the action name of the required action, and the value is the action name. Corresponding synonym list.

Intent slots are preconfigured placeholder variables, and each intent slot corresponds to a unique intent dictionary. For example, if there are three intent slots configured, the variable in intent slot 1 is var1, which corresponds to intent dictionary 1; the variable in intent slot 2 is var2, which corresponds to intent dictionary 2; the variable in intent slot 3 is var3, which corresponds to intent dictionary 3. .

Intent corpus is generally modal prefix + subject or synonym in the intent dictionary + modal suffix or its grammatical variant. It can support regular corpus and irregular corpus. For example, configure a regular corpus and multiple irregular corpus:

Rule corpus (regular matching):

(please|please help me|help me|...)? (Car machine | Car machine | Car machine | Car | On the car | In the car) (Play | Open |...)? (XXX video) (OK | OK | OK | OK |...)?

Irregular corpus:

The XXX video is opened on the car machine.

Open the XXX video on the car machine.

Can you turn on the XXX video on the car machine?

The intent reply is an operation performed when the output text matches the intent corpus. In this embodiment, it refers to obtaining the target device address information, assembling it with the variable value of the intent slot into a service call request, and initiating the call.

Optionally, when performing text parsing, the first device matches the speech text with the above-mentioned intention corpus, and obtains the parameter value in the intention slot if the matching is successful.

In an illustrative example, when the voice text is "Play xxx videos on the car machine", the matched parameter values are var1 = "Car machine", var2 = "Video playback service", var3 = "Play xxx videos" .

Step 502: The first device obtains the device address of at least one candidate device from the server based on the target device name included in the first instruction recognition result, and the candidate device matches the target device name.

When the first instruction recognition result contains the name of the target device, there may be multiple candidate devices that match the name of the target device. In order to facilitate subsequent determination of the target device, the first device obtains the name of at least one candidate device from the server. Device address.

Optionally, the device address can be the address of the service agent in each candidate device, such as the gateway address of the service agent.

Optionally, the candidate device is a device that matches the target device name and is associated with the first device. The association relationship may include at least one of the following: logging in to the same user account, being in the same device group, or having a friend relationship, etc. This is not limited in the embodiment of the present application.

In a possible implementation, the device management module of the server stores the device address of each device under the user account (reported regularly by each device). The device selection module of the first device obtains the device address of each candidate device under the current user account that matches the target device name by calling the device management module of the server.

For example, when the target device name is "car machine" and the current user account includes tablet 1, smart TV 1, car machine 1, car machine 2, and car machine 3, the server will use car machine 1, car machine 2, and car machine 3. Car machine 3 is determined as a candidate device, and the device addresses of car machine 1, car machine 2 and car machine 3 are sent to the smartphone.

Step 503: The first device determines the second device from at least one candidate device.

In order to ensure correct device service scheduling, the first device needs to determine the second device from at least one candidate device. The first device may automatically determine the second device, or determine the second device based on user instructions (that is, manually determine).

In a possible implementation, the second device determines the second device from at least one candidate device based on the target selection strategy.

Optionally, the target selection strategy includes at least one of the following: a distance-based selection strategy (such as determining the candidate device closest to the first device as the second device), a priority-based selection strategy (such as based on a preset Device priority, determine the candidate device with the highest priority as the second device), status-based selection strategy (for example, determine the candidate device currently in use as the second device).

Illustratively, the server periodically obtains the device status of each device, and feeds the device status together with the device address to the first device. The first device determines the candidate device in use among the candidate devices as the target device.

In another possible implementation, the second device displays a candidate device list, and the candidate device list includes a device identifier of at least one candidate device, so that the second device is determined based on a selection operation on the device identifier in the candidate device list.

In order to further improve the accuracy of determining the second device, the first device provides a list of candidate devices for the user to select, and determines at least one candidate device selected by the user as the target device.

Of course, in addition to the above two ways of determining the second device, the first device can also use other solutions (such as an automatic and manual combination solution) to determine the second device, and the embodiments of the present application are not limited to this.

Step 504: The first device generates a service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction recognition result.

Further, the first device generates corresponding service invocation requests for each of the determined second devices.

In a possible implementation, the first device uses the device address, target service name, and target action as parameters to form a service invocation link.

Combining the examples in the above steps, the smartphone generates a service call request based on "car machine 1 address", "video playback service" and "play xxx video".

Step 505: The first device sends a service invocation request to the second device.

Further, the first device sends a service invocation request to the second device based on the device address of the second device.

Step 506: The second device receives the service invocation request sent by the first device.

Step 507: The second device obtains the target service definition information of the target service from the server based on the target service name included in the service invocation request. The server stores the correspondence between the service definition information and the service installation package.

In order to determine whether dynamic deployment of the service is required, the second device obtains the target service name contained in the service invocation request, and thereby obtains the target service definition information of the target service from the server based on the target service name.

In a possible implementation, the service management module of the second device calls the server definition management module to obtain the target service definition information of the target service through the service gateway of the server.

Illustratively, as shown in FIG. 7 , the service management module 122 of the second device 120 calls the service definition management module 131 of the server 130 through the service gateway 135 to obtain the target service definition information.

Step 508: If it is determined based on the target service definition information that the target service installation package does not exist locally, the second device obtains the target service installation package from the server based on the target service definition information.

In a possible implementation, the service definition information of the service is associated with the installation package identification of the service installation package. After obtaining the target service definition information, the second device detects whether the local storage contains the target service installation package based on the target installation package identifier associated with the target service definition information. If the target service installation package exists, the second device determines that dynamic deployment is not required; if the target service installation package does not exist, the second device further obtains the target service installation package from the server based on the target service definition information.

Optionally, the second device calls the service installation package management module of the server to obtain the target service installation package through the service gateway of the server.

Illustratively, as shown in FIG. 7 , the service management module 122 of the second device 120 calls the service installation package management module 132 of the server 130 through the service gateway 135 to obtain the target service installation package.

Step 509: The second device deploys the target service based on the target service installation package.

Step 510: The second device calls the target service to perform the target action.

For the implementation of the above-mentioned steps 509 to 510, reference can be made to steps 206 to 207, which will not be described in detail here in the embodiment of the present application.

Illustratively, as shown in Figure 7, after obtaining the target service installation package, the service life cycle management module 123 calls the service installation module 124 to deploy the target service, and then calls the service execution module 125 to execute the target action indicated by the request.

Step 511: The second device sends a subscription message to the server, and the server is used to maintain the subscription relationship between the second device and the target service based on the subscription message.

In some possible scenarios, developers may update the developed services. In order to ensure the availability and timeliness of services deployed on the device side, the server maintains the subscription relationship between each device and the service, so that when the service is updated based on the subscription relationship, the relevant device is promptly notified for service updates. Therefore, after obtaining the target installation package, the second device sends a subscription message to the server, instructing the server to update the service subscription information of the second device, that is, to add the target service to the service subscription information of the second device.

Illustratively, as shown in Figure 7, after obtaining the target service installation package, the second device 120 sends a subscription message to the service gateway 135, and the service gateway 135 calls the subscription management module 133 to update the subscription relationship of the second device.

Of course, in other possible implementations, the server can also automatically update the subscription relationship between the device and the service after providing the service installation package, which is not limited in this embodiment.

Step 512: The second device receives the service update message sent by the server. The service update message is pushed by the server based on the subscription relationship when the target service installation package is updated.

When a service is updated, the server pushes a service update message to each device that subscribes to the service based on the subscription relationship between the device and the service. Optionally, the service update message includes the service name.

In an illustrative example, the subscription relationship maintained in the server is shown in Table 1.

Table I

Serve	equipment
Video playback service	Car machine 1, smart TV 1
Screen capture service	Car machine 1, smartphone 1, tablet 1, smart watch
Screen casting service	Car machine 2, smart TV 1, tablet 1

When the video playback service is updated, the server pushes service update messages to the car machine 1 and the smart TV 1 respectively based on the subscription relationship shown in Table 1.

Schematically, as shown in Figure 8, the developer calls the upload interface of the service definition management module 131 through the service gateway 135, uploads the updated service definition information to the server 130, and calls the service installation package management module 131 through the service gateway 135. The upload interface is used to upload the updated service installation package to the server 130. After completing the update of the service definition information and the service installation package, the subscription management module 133 of the server 130 sends a service update message to the service agent 121 of the second device 120 through the service gateway 135 .

Step 513: The second device obtains the updated target service installation package from the server based on the service update message.

Further, based on the service name in the service update message, the second device obtains the updated target server installation package from the server, downloads the originally deployed target service, and deletes the originally stored target service installation package.

Illustratively, as shown in FIG. 8 , the service management module 122 of the second device 120 obtains the updated service installation package from the server 120 and stores it in local storage.

Optionally, the second device may further redeploy the target service based on the updated target service installation package, or perform service deployment in real time when subsequently receiving a service invocation request, which is not limited in this embodiment.

In this embodiment, the first device obtains the service definition information and determines whether the service installation package is stored locally based on the service definition information to avoid wasting traffic caused by repeated downloading when the service installation package is stored.

In addition, in this embodiment, the server maintains the subscription relationship between the device and the service, and when the service is updated, pushes the service update message to the relevant device based on the subscription relationship to ensure the availability and timeliness of the service deployed on the device side. .

In order to prevent the service from occupying memory for a long time, the second device can automatically uninstall the service according to the policy, or the user can control the second device to uninstall the service through instructions. As shown in Figure 9, it shows a flow chart of a service uninstallation process according to an exemplary embodiment of the present application.

Step 901: The first device recognizes the second input command and obtains the second command recognition result.

Optionally, the second input instruction may be a voice instruction, a gesture instruction, a text instruction, etc. The embodiment of the present application does not limit the form of the input instruction.

In a possible implementation, when the input instruction is recognized and the control intention represented by the instruction identification result is to delete the deployed service, the first device obtains the second instruction identification result, wherein the second instruction identification result contains: Contains the parameters required to generate a service uninstall request.

Optionally, the second instruction identification result includes the device name of the service to be uninstalled and the service name of the service to be uninstalled.

For the specific manner in which the first device recognizes the instruction, reference may be made to the above embodiment, which will not be described in detail here.

In an illustrative example, the smartphone performs speech recognition on "Delete the video playback service on the car machine", and the obtained speech recognition result includes the device name "car machine" and the service name "video playback service".

Step 902: The first device generates a service uninstallation request based on the second instruction recognition result. The service uninstallation request is used to request the second device to uninstall the target service.

In the case where the device name is included in the second command recognition result, there may be multiple candidate devices that match the device name. In order to ensure the accuracy of subsequent service uninstallation, the first device needs to determine the actual need for service from the candidate devices. The target device for downloading.

In a possible implementation, this step may include the following steps:

1. Based on the target device name and target service name included in the second instruction recognition result, obtain the device address of at least one candidate device from the server. The candidate device matches the target device name and is deployed with the target service.

In order to facilitate subsequent determination of the target device, the first device obtains the device address of at least one candidate device from the server. Optionally, the device address can be the address of the service agent in each candidate device, such as the gateway address of the service agent.

Optionally, the candidate device is a device that matches the target device name, is associated with the first device, and is deployed with the target service. The association relationship may include at least one of the following: logging in to the same user account, being in the same device group, or having a friend relationship, etc. This is not limited in the embodiment of the present application.

In a possible implementation, the device management module of the server stores the device address of each device under the user account (reported regularly by each device), and the subscription management module stores the subscription relationship between the service and the device. The device selection module of a device obtains the device address of each candidate device under the current user account that matches the target device name and is deployed with the target service by calling the device management module and subscription management module of the server.

For example, the name of the target device is "car machine", and the current user account includes tablet 1, smart TV 1, car machine 1, car machine 2, and car machine 3, and the subscription relationship between car machine 1 and the video playback service is stored. Therefore, the server determines the vehicle computer 1 as a candidate device and sends the device address of the vehicle computer 1 to the smartphone.

2. Determine the second device from at least one candidate device.

In order to ensure correct service offloading, the first device needs to determine the second device from at least one candidate device. The first device may automatically determine the second device, or determine the second device based on user instructions (that is, manually determine).

In a possible implementation, the second device determines the second device from at least one candidate device based on the target selection strategy.

Optionally, the target selection strategy includes at least one of the following: a distance-based selection strategy (such as determining the candidate device closest to the first device as the second device), a priority-based selection strategy (such as based on a preset Device priority, determine the candidate device with the highest priority as the second device), status-based selection strategy (for example, determine the candidate device currently in use as the second device).

For example, the server periodically obtains the device status of each device and feeds back the device status together with the device address to the first device. The first device determines the candidate device in use among the candidate devices as the target device.

In another possible implementation, the second device displays a candidate device list, and the candidate device list includes a device identifier of at least one candidate device, so that the second device is determined based on a selection operation on the device identifier in the candidate device list.

In order to further improve the accuracy of the determined second device, the first device provides a list of candidate devices for the user to select, and determines at least one candidate device selected by the user as the target device.

Of course, in addition to the above two ways of determining the second device, the first device can also use other solutions (such as an automatic and manual combination solution) to determine the second device, and the embodiments of the present application are not limited to this.

3. Generate a service uninstallation request based on the device address of the second device and the target service name.

Further, the first device generates corresponding service uninstallation requests for each of the determined second devices.

In a possible implementation, the first device combines the device address and the target service name as parameters to form a service uninstallation link.

Combining the examples in the above steps, the smartphone generates a service uninstallation request based on the "car machine 1 address" and "video playback service".

Step 903: The first device sends a service uninstallation request to the second device.

In a possible implementation, the first device sends a service uninstallation request to the second device based on the device address of the second device.

Step 904: The second device receives the service uninstallation request sent by the first device.

In a possible implementation, the second device receives the service uninstallation request through a service proxy.

In some embodiments, the second device verifies the service uninstallation request, and further responds to the service uninstallation request after passing the verification. The verification methods include request integrity verification, offload requester verification, parameter compliance verification, etc., which are not limited in the embodiments of this application.

Optionally, after receiving the service uninstallation request, the second device automatically determines whether to accept the request, or determines whether to accept the request based on user instructions. If the request is accepted, step 905 is executed; if the request is not accepted, the process ends (an uninstallation rejection notification may be sent to the first device).

Step 905: The second device uninstalls the target service based on the service uninstallation request.

In order to ensure the accuracy of service uninstallation, in a possible implementation, the second device first obtains the target service definition information of the target service from the server based on the target service name included in the service uninstallation request, and then based on the target service definition information Uninstall the target service and delete the locally stored target service installation package.

In addition, in order to prevent the device from still receiving the service update message after the service is uninstalled, in a possible implementation, when the target service is uninstalled (whether under command control or automatic uninstallation), the second device sends a subscription to the server The cancellation message instructs the server to update the subscription relationship. Correspondingly, the server is used to delete the subscription relationship between the second device and the target service based on the subscription cancellation message.

Optionally, the subscription cancellation message includes the device identification of the second device and the target service name of the target service.

Illustratively, as shown in Figure 10, after the second device 120 receives the service uninstallation request through the service proxy 121, the service management module 122 calls the service definition management module 131 through the service gateway 135 to obtain the target service definition information corresponding to the target service name. , and then call the service uninstall module 126 through the service life cycle management module 123 to uninstall the target service and delete the target service installation package. After completing the service uninstallation, the second device 120 further sends a subscription cancellation message to the server 130 so that the subscription management module 133 of the server 130 deletes the subscription relationship between the target service and the second device.

In this embodiment, the user can instruct the second device to uninstall the service by inputting instructions without requiring the user to manually uninstall, thereby simplifying the service uninstallation process and preventing too many services deployed in the second device from affecting the device's operating performance.

In another possible implementation, the second device uninstalls the target service when the automatic uninstallation conditions are met, wherein the automatic uninstallation conditions include at least one of the following: the number of calls to the target service reaches a threshold, the target service is in the target service It has not been called within the duration and the deployment duration of the target service reaches the duration threshold.

Optionally, the automatic uninstallation condition is set in the service life cycle management module and supports customization.

For example, when the number of calls to the target service reaches 2 times, the service life cycle management module in the second device automatically calls the service uninstall module to uninstall the target service; when the target service has not been called within 2 hours, the service in the second device The life cycle management module automatically calls the service uninstall module to uninstall the target service; when the deployment time of the target service reaches 24 hours, the service life cycle management module in the second device automatically calls the service uninstall module to uninstall the target service.

In the above embodiment, the interaction process is taken as an example for schematic explanation, wherein the steps with the first device as the execution subject can be independently implemented as a service invocation method on the first device side, and the steps with the second device as the execution subject can be implemented independently. To become a service invocation method on the second device side, the steps with the server as the execution subject can be independently implemented as a service invocation method on the server side. The embodiments of this application will not be described in detail here.

The following are device embodiments of the present application, which can be used to execute method embodiments of the present application. For details not disclosed in the device embodiments of this application, please refer to the method embodiments of this application.

Please refer to Figure 11, which shows a structural block diagram of a service invoking device provided by an embodiment of the present application. The device may include:

The instruction identification module 1101 is used to identify the first input instruction and obtain the first instruction identification result;

Request generation module 1102, configured to generate a service invocation request based on the first instruction recognition result, where the service invocation request is used to request the second device to invoke a target service to perform a target action;

Request sending module 1103, configured to send the service invocation request to the second device, so that the second device deploys the target service based on the target service installation package and calls the target service to perform the target action, The target service installation package is obtained from the server.

Optionally, the request generation module 1102 is used for:

Based on the target device name included in the first instruction recognition result, obtain the device address of at least one candidate device from the server, and the candidate device matches the target device name;

determining the second device from at least one of the candidate devices;

Generate the service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction recognition result;

The request sending module 1103 is used for:

The service invocation request is sent to the second device based on the device address of the second device.

Optionally, in the process of determining the second device from at least one of the candidate devices, the request generation module 1102 is used to:

Determine the second device from at least one of the candidate devices based on a target selection strategy;

or,

Display a candidate device list, the candidate device list includes at least one device identifier of the candidate device; and determine the second device based on a selection operation on the device identifier in the candidate device list.

Optionally, the instruction identification module 1101 is also used to identify the second input instruction to obtain the second instruction identification result;

The request generation module 1102 is further configured to generate a service uninstallation request based on the second instruction identification result, where the service uninstallation request is used to request the second device to uninstall the target service;

The request sending module 1103 is also configured to send the service uninstallation request to the second device, so that the second device uninstalls the target service.

Optionally, in the process of generating a service uninstallation request based on the second instruction recognition result, the request generation module 1102 is used to:

Based on the target device name and target service name included in the second instruction identification result, obtain the device address of at least one candidate device from the server, the candidate device matches the target device name and is deployed with the target Serve;

determining the second device from at least one of the candidate devices;

Generate the service uninstallation request based on the device address of the second device and the target service name;

The request sending module 1103 is used for:

The service offloading request is sent to the second device based on the device address of the second device.

Please refer to Figure 12, which shows a structural block diagram of a service invoking device provided by another embodiment of the present application. The device may include:

Request receiving module 1201, configured to receive a service invocation request sent by the first device. The service invocation request is used to request to invoke a target service to perform a target action. The service invocation request is generated by the first device based on a first input instruction. The first instruction recognition result is generated;

The installation package acquisition module 1202 is configured to obtain the target service installation package of the target service from the server based on the service invocation request;

Service deployment module 1203, configured to deploy the target service based on the target service installation package;

Execution module 1204 is used to call the target service to execute the target action.

Optionally, the installation package acquisition module 1202 is used for:

Based on the target service name included in the service invocation request, obtain the target service definition information of the target service from the server;

When it is determined that the target service installation package does not exist locally based on the target service definition information, the target service installation package is obtained from the server based on the target service definition information, and the server stores service definition information. and the corresponding relationship between service installation packages.

Optionally, the device also includes:

A message sending module is configured to send a subscription message to the server, and the server is configured to maintain a subscription relationship between the second device and the target service based on the subscription message.

Optionally, the device also includes:

A message receiving module, configured to receive a service update message sent by the server, which is pushed by the server based on the subscription relationship when the target service installation package is updated;

An update module, configured to obtain the updated target service installation package from the server based on the service update message.

Optionally, the device also includes:

A message sending module, configured to send a subscription cancellation message to the server when the target service is uninstalled, and the server is configured to delete the subscription relationship based on the subscription cancellation message.

Optionally, the device also includes:

The request receiving module 1201 is also configured to receive a service uninstallation request sent by the first device. The service uninstallation request is used to request the second device to uninstall the target service. The service uninstallation request is sent by the third device. A device is generated based on a second instruction recognition result for the second input instruction;

An uninstallation module, configured to uninstall the target service based on the service uninstallation request.

Optional, the uninstall module is used for:

Based on the target service name included in the service uninstallation request, obtain the target service definition information of the target service from the server;

Uninstall the target service based on the target service definition information, and delete the locally stored target service installation package.

Optionally, the uninstall module is also used for:

The target service is uninstalled when the automatic uninstallation conditions are met. The automatic uninstallation conditions include at least one of the following: the number of calls to the target service reaches a threshold, the target service has not been called within the target duration, and the target service has not been called within the target duration. The deployment duration of the target service reaches the duration threshold.

Please refer to Figure 13, which shows a structural block diagram of a computer device provided by an exemplary embodiment of the present application. The computer device 1300 can be implemented as the first device or the second device in each of the above embodiments. Computer device 1300 may include one or more of the following components: processor 1310 and memory 1320.

Processor 1310 may include one or more processing cores. The processor 1310 uses various interfaces and lines to connect various parts of the entire computer device 1300, and executes by running or executing instructions, programs, code sets or instruction sets stored in the memory 1320, and calling data stored in the memory 1320. Various functions of computer device 1300 and processing data. Optionally, the processor 1310 can use at least one of digital signal processing (Digital Signal Processing, DSP), field-programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). implemented in hardware form. The processor 1310 can integrate one or more of a central processing unit (Central Processing Unit, CPU), a graphics processor (Graphics Processing Unit, GPU), a neural network processor (Neural-network Processing Unit, NPU), a modem, etc. The combination. Among them, the CPU mainly handles the operating system, user interface and applications; the GPU is used to render and draw the content that needs to be displayed on the touch screen; the NPU is used to implement artificial intelligence (Artificial Intelligence, AI) functions; the modem is used to process Wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 1310 and may be implemented by a separate chip.

The memory 1320 may include random access memory (RAM) or read-only memory (Read-Only Memory, ROM). Optionally, the memory 1320 includes non-transitory computer-readable storage medium. Memory 1320 may be used to store instructions, programs, codes, sets of codes, or sets of instructions. The memory 1320 may include a program storage area and a data storage area, where the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), Instructions, etc., used to implement each method embodiment described below; the storage data area may store data created according to the use of the computer device 1300 (such as audio data, phone book), etc.

In some embodiments, when the computer device 1300 is implemented as the first device, the computer device 1300 is also provided with a voice collection component, which may be a built-in microphone or an external microphone.

In addition, those skilled in the art can understand that the structure of the computer device 1300 shown in the above figures does not constitute a limitation on the computer device. The computer device may include more or less components than those shown in the figures, or a combination thereof. Certain parts, or different arrangements of parts. For example, the computer device 1300 also includes components such as a display screen, camera components, speakers, radio frequency circuits, input units, sensors (such as acceleration sensors, angular velocity sensors, light sensors, etc.), audio circuits, WiFi modules, power supplies, Bluetooth modules, etc. I won’t go into details here.

Embodiments of the present application also provide a computer-readable storage medium that stores at least one program code. The program code is loaded and executed by a processor to implement the service invocation method described in the above embodiments. .

Embodiments of the present application provide a computer program product or computer program. The computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service invocation method provided in various optional implementations of the above aspect.

It should be understood that "plurality" mentioned in this article means two or more. "And/or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and/or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the related objects are in an "or" relationship. In addition, the step numbers described in this article only illustrate a possible execution sequence between the steps. In some other embodiments, the above steps may not be executed in the numbering sequence, such as two different numbers. The steps are executed simultaneously, or two steps with different numbers are executed in the reverse order as shown in the figure, which is not limited in the embodiments of the present application.

The above are only optional embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection of the present application. within the range.

Claims (29)

1. A service invoking method, the method is executed by a first device, the method includes:

   Recognize the first input instruction and obtain the first instruction recognition result;

   Generate a service call request based on the first instruction recognition result, the service call request is used to request the second device to call the target service to perform the target action;

   Send the service invocation request to the second device, so that the second device deploys the target service based on the target service installation package and calls the target service to perform the target action, and the target service installation package is downloaded from the server get.
2. The method according to claim 1, wherein generating a service invocation request based on the first instruction recognition result includes:

   Based on the target device name included in the first instruction recognition result, obtain the device address of at least one candidate device from the server, and the candidate device matches the target device name;

   determining the second device from at least one of the candidate devices;

   Generate the service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction identification result;

   Sending the service invocation request to the second device includes:

   The service invocation request is sent to the second device based on the device address of the second device.
3. The method of claim 2, wherein determining the second device from at least one of the candidate devices includes:

   Determine the second device from at least one of the candidate devices based on a target selection strategy;

   or,

   Display a candidate device list, the candidate device list includes at least one device identifier of the candidate device; and determine the second device based on a selection operation on the device identifier in the candidate device list.
4. The method according to any one of claims 1 to 3, wherein the method further includes:

   Recognize the second input instruction and obtain the second instruction recognition result;

   Generate a service uninstallation request based on the second instruction identification result, where the service uninstallation request is used to request the second device to uninstall the target service;

   Send the service uninstallation request to the second device, so that the second device uninstalls the target service.
5. The method of claim 4, wherein generating a service uninstallation request based on the second instruction identification result includes:

   Based on the target device name and target service name included in the second instruction identification result, obtain the device address of at least one candidate device from the server, the candidate device matches the target device name and is deployed with the target Serve;

   determining the second device from at least one of the candidate devices;

   Generate the service uninstallation request based on the device address of the second device and the target service name;

   Sending the service uninstallation request to the second device includes:

   The service offloading request is sent to the second device based on the device address of the second device.
6. A service invoking method, the method is executed by a second device, the method includes:

   Receive a service invocation request sent by the first device, the service invocation request is used to request to call a target service to perform a target action, the service invocation request is generated by the first device based on the first instruction recognition result of the first input instruction. ;

   Obtain the target service installation package of the target service from the server based on the service invocation request;

   Deploy the target service based on the target service installation package;

   Call the target service to perform the target action.
7. The method according to claim 6, wherein said obtaining the target service installation package of the target service from the server based on the service invocation request includes:

   Based on the target service name included in the service invocation request, obtain the target service definition information of the target service from the server;

   When it is determined that the target service installation package does not exist locally based on the target service definition information, the target service installation package is obtained from the server based on the target service definition information, and the server stores service definition information. and the corresponding relationship between service installation packages.
8. The method of claim 6, further comprising:

   Send a subscription message to the server, and the server is configured to maintain a subscription relationship between the second device and the target service based on the subscription message.
9. The method of claim 8, further comprising:

   Receive a service update message sent by the server, which is pushed by the server based on the subscription relationship when the target service installation package is updated;

   Obtain the updated target service installation package from the server based on the service update message.
10. The method of claim 8, further comprising:

    When the target service is uninstalled, a subscription cancellation message is sent to the server, and the server is configured to delete the subscription relationship based on the subscription cancellation message.
11. The method according to any one of claims 6 to 10, wherein the method further includes:

    Receive a service uninstallation request sent by the first device, the service uninstallation request is used to request the second device to uninstall the target service, the service uninstallation request is generated by the first device based on a second input instruction. 2. Instruction recognition result generation;

    The target service is uninstalled based on the service uninstallation request.
12. The method according to claim 11, wherein the uninstalling the target service based on the service uninstallation request includes:

    Based on the target service name included in the service uninstallation request, obtain the target service definition information of the target service from the server;

    Uninstall the target service based on the target service definition information, and delete the locally stored target service installation package.
13. The method according to any one of claims 6 to 10, wherein the method further includes:

    The target service is uninstalled when the automatic uninstallation conditions are met. The automatic uninstallation conditions include at least one of the following: the number of calls to the target service reaches a threshold, the target service has not been called within the target duration, and the target service has not been called within the target duration. The deployment duration of the target service reaches the duration threshold.
14. A service invoking device, the device includes:

    An instruction identification module, used to identify the first input instruction and obtain the first instruction identification result;

    A request generation module, configured to generate a service invocation request based on the first instruction recognition result, the service invocation request being used to request the second device to invoke the target service to perform the target action;

    A request sending module, configured to send the service invocation request to the second device, so that the second device deploys the target service based on the target service installation package and calls the target service to perform the target action, so The above target service installation package is obtained from the server.
15. The device according to claim 14, wherein the request generation module is used for:

    Based on the target device name included in the first instruction recognition result, obtain the device address of at least one candidate device from the server, and the candidate device matches the target device name;

    determining the second device from at least one of the candidate devices;

    Generate the service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction identification result;

    The request sending module is used for:

    The service invocation request is sent to the second device based on the device address of the second device.
16. The apparatus according to claim 15, wherein in the process of determining the second device from at least one of the candidate devices, the request generation module is configured to:

    Determine the second device from at least one of the candidate devices based on a target selection strategy;

    or,

    Display a candidate device list, the candidate device list includes at least one device identifier of the candidate device; and determine the second device based on a selection operation on the device identifier in the candidate device list.
17. The device according to any one of claims 14 to 16, wherein the instruction identification module is also used to identify the second input instruction to obtain the second instruction identification result;

    The request generation module is further configured to generate a service uninstallation request based on the second instruction identification result, where the service uninstallation request is used to request the second device to uninstall the target service;

    The request sending module is also configured to send the service uninstallation request to the second device, so that the second device uninstalls the target service.
18. The device according to claim 17, wherein in the process of generating a service uninstallation request based on the second instruction identification result, the request generation module is configured to:

    Based on the target device name and target service name included in the second instruction identification result, obtain the device address of at least one candidate device from the server, the candidate device matches the target device name and is deployed with the target Serve;

    determining the second device from at least one of the candidate devices;

    Generate the service uninstallation request based on the device address of the second device and the target service name;

    The request sending module is used for:

    The service offloading request is sent to the second device based on the device address of the second device.
19. A service invoking device, the device includes:

    A request receiving module, configured to receive a service invocation request sent by the first device. The service invocation request is used to request the invocation of a target service to perform a target action. The service invocation request is generated by the first device based on a response to a first input instruction. The first instruction recognition result is generated;

    An installation package acquisition module, configured to obtain the target service installation package of the target service from the server based on the service invocation request;

    A service deployment module, configured to deploy the target service based on the target service installation package;

    An execution module is used to call the target service to execute the target action.
20. The device according to claim 19, wherein the installation package acquisition module is used for:

    Based on the target service name included in the service invocation request, obtain the target service definition information of the target service from the server;

    When it is determined that the target service installation package does not exist locally based on the target service definition information, the target service installation package is obtained from the server based on the target service definition information, and the server stores service definition information. and the corresponding relationship between service installation packages.
21. The device of claim 19, wherein the device further comprises:

    A message sending module is configured to send a subscription message to the server, and the server is configured to maintain a subscription relationship between the second device and the target service based on the subscription message.
22. The device of claim 21, wherein the device further comprises:

    A message receiving module, configured to receive a service update message sent by the server, which is pushed by the server based on the subscription relationship when the target service installation package is updated;

    An update module, configured to obtain the updated target service installation package from the server based on the service update message.
23. The device of claim 21, wherein the device further comprises:

    A sending module, configured to send a subscription cancellation message to the server when the target service is uninstalled, and the server is configured to delete the subscription relationship based on the subscription cancellation message.
24. The device of claims 19 to 23, wherein the device further comprises:

    The request receiving module is also configured to receive a service uninstallation request sent by the first device. The service uninstallation request is used to request the second device to uninstall the target service. The service uninstallation request is sent by the first device. The device generates based on the second instruction recognition result for the second input instruction;

    An uninstallation module, configured to uninstall the target service based on the service uninstallation request.
25. The device according to claim 24, wherein the unloading module is used for:

    Based on the target service name included in the service uninstallation request, obtain the target service definition information of the target service from the server;

    Uninstall the target service based on the target service definition information, and delete the locally stored target service installation package.
26. The device according to claims 19 to 23, wherein the unloading module is also used for:

    The target service is uninstalled when the automatic uninstallation conditions are met. The automatic uninstallation conditions include at least one of the following: the number of calls to the target service reaches a threshold, the target service has not been called within the target duration, and the target service has not been called within the target duration. The deployment duration of the target service reaches the duration threshold.
27. A computer device, the computer device includes a processor and a memory; the memory stores at least one instruction, and the at least one instruction is used to be executed by the processor to implement the method described in any one of claims 1 to 5 Service invocation method, or implement the service invocation method as described in any one of claims 6 to 13.
28. A computer-readable storage medium in which at least one program code is stored, and the program code is loaded and executed by a processor to implement the service calling method as described in any one of claims 1 to 5, Or, implement the service invoking method as described in any one of claims 6 to 13.
29. A computer program product, the computer program product includes computer instructions, the computer instructions are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, the The processor executes the computer instructions, so that the computer device executes the service invocation method as described in any one of claims 1 to 5, or implements the service invocation method as described in any one of claims 6 to 13.

Images