WO2023216604A1

WO2023216604A1 - Service scheduling method and system, electronic device, and computer readable storage medium

Info

Publication number: WO2023216604A1
Application number: PCT/CN2022/141030
Authority: WO
Inventors: 王剑锋; 李轩恺; 郑爱华; 董伟鑫; 罗升阳; 张晓帆; 杨俊拯
Original assignee: Oppo广东移动通信有限公司
Priority date: 2022-05-07
Filing date: 2022-12-22
Publication date: 2023-11-16
Also published as: CN115150507A

Abstract

A service scheduling method, a service scheduling system (1000), an electronic device (100), and a storage medium (300). The method comprises: determining a current application scene, and determining a service set corresponding to the application scene; under the condition that a trigger event is detected in the application scene, determining a target service, corresponding to the trigger event, in the service set; determining initial calling information of the target service, and determining target calling information according to the initial calling information, the target calling information being matched with an electronic device running the target service; and running the target service according to the target calling information.

Description

Service scheduling method and system, electronic equipment and computer-readable storage medium

priority information

This application requests the priority and rights of the patent application No. 2022104952944, which was submitted to the State Intellectual Property Office of China on May 7, 2022, and the full text of which is incorporated herein by reference.

Technical field

The present application relates to the field of application technology, and more specifically, to a service scheduling method, a service scheduling system, an electronic device and a non-volatile computer-readable storage medium.

Background technique

At present, when an electronic device runs an application or service, the application needs to meet the system requirements of the electronic device. However, the calling methods or upper-layer abstraction methods of processes of different systems or platforms are generally different, and even processes of the same system or platform have different Calling method or upper abstraction method.

Contents of the invention

Embodiments of the present application provide a service scheduling method, service scheduling system, electronic equipment, and non-volatile computer-readable storage media.

The service scheduling method in the embodiment of the present application includes determining the current application scenario and determining the service set corresponding to the application scenario; when a trigger event is detected in the application scenario, determining the service set corresponding to The target service that triggers the event; determines the initial call information of the target service, determines the target call information according to the initial call information, and the target call information matches the electronic device running the target service; according to the target call information to run the target service.

The service scheduling system in the embodiment of this application includes a scene awareness module, a service management module and a service operation module. The scene awareness module is used to determine the current application scenario and determine the service set corresponding to the application scenario; the service governance module is used to determine the trigger event when a trigger event is detected in the application scenario. The target service corresponding to the trigger event in the service set; determining the initial call information of the target service, determining the target call information based on the initial call information, and the target call information matches the electronic device running the target service; The service running module is configured to run the target service according to the target calling information.

The electronic device according to the embodiment of the present application includes a processor. The processor is configured to determine the current application scenario and determine the service set corresponding to the application scenario; when a trigger event is detected in the application scenario, determine the service set corresponding to the trigger event. The target service; determine the initial call information of the target service, determine the target call information according to the initial call information, and the target call information matches the electronic device running the target service; run the described target service according to the target call information target service.

The non-volatile computer-readable storage medium of the embodiment of the present application contains a computer program. When the computer program is executed by one or more processors, it causes the processor to execute the following service scheduling method: determine the current application Scenario, determine the service set corresponding to the application scenario; when a trigger event is detected in the application scenario, determine the target service corresponding to the trigger event in the service set; determine the initialization of the target service Call information: determine target call information according to the initial call information, and the target call information matches the electronic device running the target service; run the target service according to the target call information.

Additional aspects and advantages of embodiments of the application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of embodiments of the application.

Description of the drawings

The above and/or additional aspects and advantages of the present application will become apparent and readily understood from the description of the embodiments in conjunction with the following drawings, in which:

Figure 1 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figure 2 is a schematic diagram of a service scheduling system in some embodiments of the present application;

Figure 3 is a schematic diagram of the connection between an electronic device and a server in some embodiments of the present application;

Figure 4 is a schematic diagram of the relationship between applications and services in certain embodiments of the present application;

Figure 5 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figure 6, Figure 7 and Figure 8 are schematic scenario diagrams of the service scheduling method in some embodiments of the present application;

Figure 9 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figures 10 and 11 are schematic scenario diagrams of the service scheduling method in some embodiments of the present application;

Figure 12 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figure 13 is a schematic structural diagram of an application script in some embodiments of the present application;

Figure 14 is a schematic principle diagram of a service scheduling method in some embodiments of the present application;

Figure 15 is a schematic scenario diagram of a service scheduling method in some embodiments of the present application;

Figure 16 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figures 17 and 18 are schematic diagrams of the principles of the service scheduling method in some embodiments of the present application;

Figures 19 to 22 are schematic flow diagrams of service scheduling methods in certain embodiments of the present application;

Figure 23 is a schematic scenario diagram of a service scheduling method in some embodiments of the present application;

Figure 24 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figure 25 is a schematic principle diagram of a service scheduling method in some embodiments of the present application;

Figure 26 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figure 27 is a schematic flowchart of a service scheduling method in some embodiments of the present application;

Figure 28 is a schematic scenario diagram of a service scheduling method in some embodiments of the present application;

Figure 29 is a schematic scenario diagram of a service scheduling method in some embodiments of the present application;

Figure 30 is a schematic structural diagram of a service scheduling system in some embodiments of the present application;

Figure 31 is a schematic principle diagram of a service scheduling method in some embodiments of the present application;

Figure 32 is a schematic diagram of the connection status of a non-volatile computer-readable storage medium and a processor in some embodiments of the present application.

Detailed ways

The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements with the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the embodiments of the present application and cannot be understood as limiting the embodiments of the present application.

The service scheduling method of this application includes determining the current application scenario and determining the service set corresponding to the application scenario; when a trigger event is detected in the application scenario, determining the target service corresponding to the trigger event in the service set; determining the target The initial call information of the service determines the target call information based on the initial call information, and the target call information matches the electronic device running the target service; the target service is run based on the target call information.

In some implementations, determining the current application scenario includes obtaining interaction information, and determining the current application scenario based on the interaction information.

In some embodiments, the interaction information includes location information, orientation information, and movement information; obtaining the interaction information and determining the current application scenario based on the interaction information includes: determining based on the location information whether the current electronic device is within the preset location range. In this case, the target position corresponding to the preset position range is obtained; when it is determined that the current electronic device is moving toward the target position according to the orientation information and the movement information, the application scenario corresponding to the target position where the current electronic device is currently located is determined.

In some embodiments, obtaining interaction information and determining the current application scenario based on the interaction information includes: when the current electronic device detects a preset operation instruction, collecting interaction information through the electronic device, and determining the current electronic device based on the interaction information. The initial application scenario in which the device is currently located; output prompt information according to the initial application scenario, and obtain input information input according to the prompt information; determine the application scenario in which the current electronic device is currently located based on the input information.

In some embodiments, determining the service set corresponding to the application scenario includes: determining an application script corresponding to the application scenario, where the application script includes at least one service identifier; and a service set corresponding to all service identifiers in the application script. Collections, as service collections.

In some embodiments, determining the application script corresponding to the application scenario includes: determining a service list corresponding to the application scenario; and generating an application script corresponding to the application scenario based on at least one service identifier included in the service list.

In some embodiments, generating an application script corresponding to the application scenario based on at least one service identifier included in the service list includes: generating an initial application script corresponding to the application scenario based on at least one service identifier included in the service list; obtaining the Adjust the initial application script based on the editing data of the initial application script and/or the user portrait data of the current user, and obtain the application script corresponding to the application scenario.

In some embodiments, when a trigger event is detected in an application scenario, determining the target service corresponding to the trigger event in the service set includes: when a trigger event is detected in the application scenario, triggering the trigger event in the application The corresponding target trigger in the script; the corresponding target control logic is called through the target trigger, and the target service corresponding to the triggering event in the service collection is determined according to the target control logic.

In some embodiments, determining the initial call information of the target service and determining the target call information based on the initial call information includes: initiating a target call request for the target service, wherein the target call request contains the initial call information of the target service; according to The initial call information in the target call request calls the corresponding service agent, and the service agent determines the target call information corresponding to the initial call information.

In some embodiments, the initial call information includes service type and registration call information; the corresponding service agent is called according to the initial call information in the target call request, and the target call information corresponding to the initial call information is determined by the service agent, including: calling The service agent corresponding to the service type converts the registration call information into the corresponding target call information according to the predetermined format.

In some embodiments, calling the corresponding service agent according to the initial call information in the target call request, and before determining the target call information corresponding to the initial call information through the service agent, it also includes: validating the target call request through the target service gateway. Verification: When the target service gateway passes the verification of the target call request, the corresponding service agent is called according to the initial call information in the target call request, and the target call information corresponding to the initial call information is determined through the service agent.

In some embodiments, the legality verification of the target call request through the service gateway includes: when the target service gateway is the service gateway of the current electronic device, the legality verification of the target call request through the target service gateway; When the target service gateway is the service gateway of an external electronic device, it sends the target call request to the external electronic device and receives the processing result returned by the external electronic device. The processing result is that the external electronic device responds to the target call request through the target service gateway. If the legality verification passes, the processing result obtained in response to the target call request.

In some embodiments, running the target service according to the target call information includes: when the target service is the first service type, running the target service according to the target call information; when the target service is the second service type, determining The host service corresponding to the target service runs the target service according to the target call information when the host service is in running state.

In some embodiments, the initial call information includes registration call information and/or dynamic call information; determining the initial call information of the target service, and determining the target call information based on the initial call information includes: obtaining the registration of the target service stored in the current electronic device Call information, and/or, obtain dynamic call information generated by other services; among them, the registration call information is used to represent attributes related to the target service, and the dynamic call information is used to represent the input variables required to run the target service; according to the registration call information and Dynamically call information to determine target call information.

In some embodiments, determining the initial call information of the target service includes: receiving the initial call information corresponding to the target service sent by the server; running the target service according to the target call information, including: when the target service is the localization of the current electronic device In the case of service, obtain the target service code set stored in the current electronic device, and run the target service code set according to the target call information; when the target service is a non-localized service of the current electronic device, obtain the target service sent by the server corresponding to the target service The target service code collection runs the target service code collection according to the target call information.

The service scheduling system of this application includes a scene awareness module, a service management module and a service operation module. The scene awareness module is used to determine the current application scenario and determine the service set corresponding to the application scenario; the service governance module is used to determine the target service corresponding to the trigger event in the service set when a trigger event is detected in the application scenario. ; Determine the initial call information of the target service, determine the target call information based on the initial call information, and match the target call information with the electronic device running the target service; and the service running module is used to run the target service according to the target call information.

The electronic device of the present application includes a processor. The processor is used to determine the current application scenario and determine the service set corresponding to the application scenario; when a trigger event is detected in the application scenario, determine the service set corresponding to the trigger event. Target service; determine the initial call information of the target service, determine the target call information based on the initial call information, and match the target call information with the electronic device running the target service; run the target service according to the target call information.

In some implementations, the processor is also configured to obtain interaction information and determine the current application scenario based on the interaction information.

In some embodiments, the interaction information includes location information, orientation information, and movement information; the processor is also configured to determine based on the location information that the current electronic device is within a preset location range, and obtain the target location corresponding to the preset location range. ; When determining that the current electronic device is moving toward the target position based on the orientation information and movement information, determine the application scenario corresponding to the current electronic device currently being at the target position.

The non-volatile computer-readable storage medium of the present application includes a computer program. When the computer program is executed by a processor, it causes the processor to execute the service scheduling method of any of the above embodiments.

With the popularity of mobile terminals, more and more types of applications are running on mobile terminals to meet people's needs in daily life. For example, map applications implement navigation, music applications implement Walkman, etc. In different application scenarios, users actively install and run corresponding applications according to actual needs. As the number of installed applications increases, users often need to spend a lot of time to find applications that meet the current application scenarios, which increases the user's Time cost, and user experience is also poor.

Please refer to Figure 1. An embodiment of the present application provides a service scheduling method. The service scheduling method includes steps:

011: Determine the current application scenario and determine the service set corresponding to the application scenario;

012: When a trigger event is detected in the application scenario, determine the target service corresponding to the trigger event in the service collection;

013: Determine the initial call information of the target service, determine the target call information based on the initial call information, and match the target call information with the electronic device 100 running the target service;

014: Run the target service based on the target call information.

Referring to Figure 2, an embodiment of the present application provides a service scheduling system 10. The service scheduling system 10 includes a scene awareness module 11 , a service management module 12 and a service operation module 13 . The service scheduling method in the embodiment of the present application can be applied to the service scheduling system 10 . Among them, the scene awareness module 11 is used to perform step 011; the service management module 12 is used to perform step 012 and step 013; the service operation module 13 is used to perform step 014.

Referring to Figure 3, an embodiment of the present application also provides an electronic device 100. Electronic device 100 includes processor 20 . The service scheduling method in the embodiment of the present application can be applied to the electronic device 100 . The processor 20 is used to execute step 011, step 012, step 013 and step 014.

Wherein, the electronic device 100 includes a housing 30 . The electronic device 100 may be a mobile phone, a tablet computer, a television, a display device, a laptop computer, a teller machine, a gate, a smart watch, a head-mounted display device, a game console, or a new device supporting VR and AR, etc. As shown in FIG. 3 , the embodiment of the present application is explained by taking the electronic device 100 as a mobile phone as an example. It can be understood that the specific form of the electronic device 100 is not limited to a mobile phone. The casing 30 can also be used to install functional modules such as a display device, imaging device, power supply device, and communication device of the electronic device 100, so that the casing 30 can provide dustproof, anti-fall, waterproof and other protection for the functional modules.

Specifically, the service scheduling system 10 can be set up in the electronic device 100, or the service scheduling system 10 can be set up in the server 200 in the cloud, or the service scheduling system 10 can be set up in both the electronic device 100 and the server 200.

For example, the processor 20 includes a first processor 21 in the electronic device 100 and a second processor 22 in the server 200 . The first processor 21 or the second processor 21 can perform steps 011 to 014; or, the first processor 21 is used to perform step 011, the second processor 22 is used to perform

steps

012 and 013, and the first processor 21 is used to perform step 011. 21 is used to perform step 014, etc.

The scene awareness module 11 can determine the current application scene.

The application scenario may be the usage scenario in which the electronic device 100 is currently located, the interaction information may be obtained, and then the usage scenario may be determined based on the interaction information. For example, the usage scenario can be determined based on the interaction information of the electronic device 100, such as based on the current electronic device 100 or other electronic devices 100 that are communicatively connected to the current electronic device 100 (for example, a mobile phone is the current electronic device 100, and a vehicle is other electronic devices 100). If the usage scene determined by the image recognized by the camera (or the location information detected based on the Global Positioning System (GPS)) is a shopping mall, then the application scene is determined to be a shopping mall scene; if the usage scene is determined to be a subway, then the application scene is determined For the subway scene. Or, if the electronic device 100 receives the user's input to determine the usage scenario, such as when the user's gesture input, touch input, voice input, etc. meet preset conditions, the corresponding usage scenario is determined, such as the gesture is a two-finger tap. Gesture, confirm that the usage scenario is a cross-device screenshot scenario.

For example, the scene sensing module 11 can determine the current application scenario based on the location information of the electronic device 100 (such as GPS information of a mobile phone or GPS information of a vehicle). For example, when the location information indicates that the electronic device 100 is in an underground garage, it can be determined. The application scenario is the garage. It can be understood that different application scenarios correspond to different service sets. For example, in the garage scenario, there are generally services such as "parking space navigation" and "vehicle management". For the subway scenario, there are generally services such as "boarding code" and "arrival reminder". , thereby determining the service collection according to the application scenario.

Service is a technical concept. When a functional entity provides a callable interface to the outside world, it supports passing in parameters, executing functions and returning results. Then this callable interface is a service.

The entity that provides the above interface is called a service provider. A service provider can expose multiple services to the outside world. There is no restriction on the entity type of the service provider.

Services can be Android UI services, perception services, cloud services (such as cloud software as a service (SaaS)), voice services, systemized services (such as Android applications), third-party services (such as Google Chrome plug-ins) )wait.

For example, the plug-in in WPS OFFICE is exposed to the electronic device 100 through the service gateway, and the electronic device 100 calls the plug-in in WPS through the service gateway of WPS to implement corresponding services, such as inserting picture services, inserting text services, etc.

As the smallest unit in the running process of an application, a service is used to implement specific tasks. For example, the parking space navigation service implements the navigation function, the vehicle management service is used to implement vehicle locking/unlocking, the ride code service is used to implement the pop-up ride code function, the arrival reminder service is used to implement the function of prompting the user to arrive at the station, and the screenshot service is used to implement the function of popping up the ride code. It is used to realize the device screenshot function, and the screen projection service is used to realize the display screen projection between devices, etc. For example, map applications include navigation services and arrival reminder services.

The service called during application running may be a service on the current electronic device 100 or a service on other devices. For example, while the application is running, you can obtain device screenshots of other devices by calling the screenshot service on other devices, and display the device screenshots of other devices by calling the image display service.

Referring to Figure 4, an application can be viewed as a collection of services (Application 1 to Application 3 in Figure 4), which are used to implement specific business logic through calls between services. Unlike traditional applications that can only run on a specific operating system, the services of the application of this application (application 3 in Figure 4) can be services on different operating systems, that is, the application supports heterogeneous operating systems and can realize cross-platform operation. .

Different from the traditional application installation process, all services used during operation need to be pre-installed locally. The services in the application of this application support dynamic deployment, that is, based on the business logic executed by the current electronic device 100 during the operation process, The service corresponding to the business logic is dynamically deployed to the current electronic device 100 . Correspondingly, when the functions of the same application are implemented through multiple devices, since the business logic of different devices may be different, the services deployed by different devices may also be different, that is, the services in the application have the characteristics of differential deployment.

It can be understood that the service set corresponding to the application scenario can be preset, or can be determined based on the number of times and usage duration of the services used by the user in different application scenarios daily, or can be dynamically adjusted in any way. For example, if the user uses the ride code service every time he or she enters or exits the subway scene, the ride code service can be used as one of the service sets corresponding to the subway scene.

After determining the application scenario in which the electronic device 100 is located, the triggering event can be detected in the current application scenario, thereby determining the target service corresponding to the triggering event in the service set.

The triggering event is associated with the services in the service collection, and the target service corresponding to the triggering event is quickly determined based on the accessibility of the triggering event.

Trigger events can be events generated by user interaction, such as user clicks on the display, user voice or key input, data collected by sensors meeting preset conditions, etc. Among them, the data collected by the sensor meeting the preset conditions may be that the ambient light brightness collected by the ambient light sensor reaches the preset brightness, or the GPS detects that the current location is at the preset location, etc.

For example, after it is determined that the user has entered the subway scene based on the location information detected by GPS, it can be determined that the user wants to take the subway, thereby determining the trigger event for detecting the "ride code" service. At this time, the service collection of the subway scene is , determine the "ride code" service as the target service. After it is determined that the user has entered the subway based on the location information of the electronic device 100, the voice information of the microphone, etc., it can be determined that the user may need an arrival reminder. Therefore, it can be determined that the trigger event of the "arrival reminder" service has been detected. At this time, From the service collection of the subway scene, determine the "arrival reminder" service as the target service.

After the target service is determined, if the target service has been installed in the electronic device 100, the target service can be run directly. When the target service has not been installed, or in order to save the memory of the electronic device 100, the service can be stored in the server 200 in the cloud. When the electronic device 100 needs it, the target service is obtained from the server 200 in the cloud.

Services of different systems or platforms have different upper-level abstraction methods for processes and different calling methods between processes. Each service needs to have initial calling information preset when registering. The initial calling information can be the information written when the service is registered. . When the system or platform on which the target service runs is different from the current electronic device 100, the electronic device 100 cannot directly run the target service based on the initial call information, but needs to convert the initial call information of the target service into target call information matching the target service. Thus, the target service can run stably under the current electronic device 100 .

In one example, the current electronic device 100 is an Android system, and the target service is a windows service. The current electronic device 100 cannot directly use the windows service. After determining the initial call information of the target service, the initial call information needs to be converted. For example, the initial call information may include Android parameter A, Android parameter B, and Android parameter C. The target service cannot directly handle Android parameter A, Android parameter B, and Android parameter C.

Therefore, the current electronic device 100 (or server 200) can convert the initial call information into target call information, such as converting Android parameter A, Android parameter B and Android parameter C into windows parameter A, windows parameter B and windows parameter C respectively, Then input the windows parameter A, windows parameter B and windows parameter C into the target service to realize the calling of the target service.

It is understandable that the Android system needs to run Android applications or services, and the Windows system needs to run Windows applications or services, making it difficult for electronic devices to use applications or services from different platforms at the same time, limiting the usage scenarios of electronic devices. Android parameters and windows parameters may only have different formats but actually contain the same content. For example, if the target service is a navigation service, when entering a destination for navigation, both the Android parameters and the windows parameters include the actual "destination", thus ensuring After the server 200 converts the initial call information into the target call information, it can correctly call the target service, thereby avoiding the situation where incorrect call results may be obtained when running the target service after conversion.

The service scheduling method, service scheduling system 10 and electronic device 100 in the embodiment of the present application determine the service set corresponding to the application scenario by determining the current application scenario. When a trigger event is detected in the application scenario, The target service that responds to the trigger event is determined in the service collection. By determining the application scenario and detecting the trigger event, the corresponding target service is quickly determined and run, which reduces the time cost for users to find the target service and helps improve user experience. And it can be understood that the types of services on different platforms (such as Android platform, server 200 platform, etc.) are different. For example, services on the Android platform cannot run normally on the server 200 platform. Therefore, the implementation of this application will make the initial call of the target service After the information is converted into target call information that matches the target service, the target service can be stably run on the electronic device 100 . In this way, the target service can realize cross-platform operation, which expands the usage scenarios of the electronic device 100 .

Referring to Figure 2, Figure 3 and Figure 5, in some embodiments, step 011 includes:

0111: Obtain interaction information and determine the current application scenario based on the interaction information.

In some implementations, the context awareness module 11 is also used to perform step 0111.

In some embodiments, processor 20 is configured to perform step 0111.

Specifically, interaction information is used to represent information generated by any interaction process of the electronic device 100, and may be information that the electronic device 100 can obtain. For example, the interaction information includes input information, sensor information, status information, location information, and at least one of running information of applications of the electronic device 100 .

The input information may include: voice interaction information, text interaction information, touch interaction information, etc., which are not limited here. The sensor information may be images collected by the camera 40 of the electronic device 100, posture information collected by the posture sensor, ambient light brightness information collected by the ambient light sensor, sound information collected by the microphone, etc. The status information may be the current status of the electronic device 100, such as the electronic device 100 is communicating with other devices, the time and power of the electronic device 100, etc. The location information represents the location of the electronic device 100, such as home, company, shopping mall, or a specific location indoors. The running information of the application includes whether the current application has completed a task (for example, the task of the navigation application may be whether the navigation task is completed), and the task of the shopping application may be whether the current shopping cart is settled, etc.

In this embodiment, application scenarios may include basic application scenarios and advanced application scenarios. Basic application scenarios, such as environment, time, activities, traffic, location, nearby devices, etc., can be perceived through interactive information of the electronic device 100. You can also Determine advanced application scenarios based on basic application scenarios, for example, obtain advanced application scenarios for ordering food through basic application scenario time/location reasoning; obtain advanced application scenarios for shopping through basic application scenario activity reasoning; obtain advanced application scenarios for going to work through basic application scenario transportation reasoning ; Obtain advanced application scenarios for sightseeing attractions through basic application scenario location inference; obtain advanced application scenarios for screen projection through basic application scenario nearby device inference, etc., which are not limited here.

In some embodiments, the application scenario is determined through at least one of position awareness, vehicle awareness, activity state awareness, device state awareness, device attitude awareness, nearby device awareness, environment state awareness, and time awareness, which is not done here. limited.

As an implementable manner, the application scenario is determined according to the perceived position of the electronic device 100 . Location awareness can locate the location of the electronic device 100 through global positioning system (GPS) technology, and can locate the location of the electronic device 100 through Beidou positioning system technology, etc., which are not limited here. For example, when the location information shows that you are currently in a subway station, the application scene is determined to be a subway scene; when the location information shows that you are currently in a garage, the application scene is determined to be a garage scene.

As an implementable method, the application scenario is determined according to the perceived vehicle type. Vehicle sensing can calculate the change speed of the electronic device 100 in the horizontal and vertical directions through the acceleration sensor of the electronic device 100, and combine it with machine learning and other technologies to determine whether the electronic device 100 is in a driving state. When it is determined that the electronic device 100 is in a driving state, The types of vehicles are then distinguished through sound recognition, such as cars, buses, trains, airplanes, etc. Different vehicles have different environmental noises.

As an implementable way, the application scenario is determined based on the perceived activity status. Activity state sensing can calculate the change speed of the electronic device 100 in the horizontal and vertical directions through the acceleration sensor of the electronic device 100, and combine it with machine learning and other technologies to determine whether the user corresponding to the electronic device 100 is in a stationary state, walking state, or in a Running status, etc. are not limited here. For example, when the user is in a stationary state, the application scene can be determined to be a sleeping scene; when the user is in a running state, the application scene can be determined to be a running scene.

As an implementable method, the application scenario is determined based on the perceived device status. Device status awareness can obtain the status of the electronic device 100 through the operating system of the electronic device 100 . For example, whether the electronic device 100 is connected to an audio playback device, whether the wireless module of the electronic device 100 is connected, whether the screen of the electronic device 100 is lit, etc. is not limited here. For example, when the electronic device 100 is connected to an audio playback device, the application scenario is determined to be the audio playback scenario.

As an implementable method, the application scenario is determined based on the perceived device posture. Device attitude sensing can use the acceleration sensor, gyroscope, magnetometer and other sensors of the electronic device 100, combined with machine learning and other technologies, to evaluate whether the electronic device 100 is facing up or down, whether it is resting on the desktop or placed in a pocket, backpack, etc., in This is not limited. For example, when the electronic device 100 is facing down, the application scene is determined to be a silent scene.

As an implementable method, the application scenario is determined based on the perceived nearby devices. Nearby device sensing can identify nearby devices through Bluetooth, WiFi and other broadcasts emitted by nearby devices. The nearby devices may include, for example, smart phones, smart TVs, smart watches, smart headphones, smart cars, etc., which are not limited here. For example, when the nearby device is a smart TV, the application scenario is determined to be a screen projection scenario.

As an implementable method, the application scenario is determined based on the perceived environmental state. Environmental state sensing can identify the current environmental state of the electronic device 100 through sensors such as barometer, thermometer, and ambient light of the electronic device 100 . For example, when the environmental state is nighttime, the application scene is determined to be a night scene shooting scene.

As an implementable method, the application scenario is determined based on the perceived time. Time awareness can be achieved by obtaining the current system time of the electronic device 100, calculating the date, day of the week and other information, and determining whether it is a working day or a weekend, morning, afternoon, night or late night, etc. Then use the country or region to determine whether it is a holiday, etc. For example, when the time is a working day and it is working time, the application scenario is determined to be the working scenario.

As an implementable manner, in addition to obtaining location information when obtaining interaction information, orientation information and movement information can also be obtained to further improve the accuracy of determining the application scenario of the electronic device 100 .

Specifically, referring to FIG. 6 , when it is first determined according to the location information that the current electronic device 100 is within the preset location range, the target location corresponding to the preset location range is obtained.

There are two types of positions: absolute position and relative position. The absolute position of an entity is relative to a fixed point in space. The relative position of one entity is relative to another entity and does not require the existence of a fixed point in space. The current electronic device 100 may first determine one or more preset location ranges F in the map, such as the range where the target entity A is located in the map of the current city (such as a circular range with a preset radius centered on the target entity A). (such as 10 meters, 20 meters, 50 meters, etc.)), such as the location range of the subway station, the location range of the shopping mall, the location range of the parking lot, etc., can be used as the default location range F.

When it is determined that the location L1 corresponding to the location information is located in a preset location range F, the target location L2 corresponding to the preset location range F can be obtained. For example, the location L1 is located in the preset location range F where subway station A is located. The subway The target position L2 corresponding to the preset position range F where station A is located is the absolute position of subway station A (such as the longitude and latitude of subway station A). For example, the target position L2 is the predetermined position of subway station A (such as a subway entrance). Longitude and latitude.

Then, if it is determined that the current electronic device 100 is moving toward the target position L2 based on the orientation information and the movement information, it is determined that the current electronic device 100 is currently in an application scenario corresponding to the target position L2.

Heading describes the direction in which the front face of an entity faces. Therefore, the entity is required to have a "front face", such as the surface on which the user's face is located. Similar to position, there are two types of entity orientation: absolute and relative. Absolute orientation can be described by pitch, yaw, and roll angles, while relative orientation can be described using quantitative descriptions such as "the device is directly in front of the user."

According to the connection and orientation information between the position L1 corresponding to the position information and the target position L2, it can be accurately determined whether the user is facing the target position L2. For example, it can be determined whether the user is facing the target position L2 by judging whether the connection line L3 is within the angle range D corresponding to the orientation information. Toward the target position, for example, if the user's direct front is the yaw angle of 0 degrees, the angle range D corresponding to the orientation information is from the yaw angle -30 degrees to the yaw angle 30 degrees, and the connection line L3 can be determined if it is within the angle range D. The user moves toward the target location.

When the user is moving towards the target position, it is then determined based on the movement information whether the user is moving towards the target position L2. For example, the absolute position of the current electronic device 100 can be determined based on the position information, and the absolute position of the current electronic device 100 and the absolute position of the target position can be determined. , the relative distance between the current electronic device 100 and the target position can be determined.

The movement information may be the change information of the relative distance between the current electronic device 100 and the target location. When the user moves to the target location, the relative distance between the current electronic device 100 and the target location shows a trend of decreasing with the passage of time. It can be understood that , the decrease with the passage of time can be: as time goes by, the user continues to approach the target position; it can also be: due to the twists and turns of the road, as time goes by, the user first moves away from the target position, and finally approaches the target position.

When it is determined that the user is heading towards the target location L2 and moving towards the target location L2, it can be determined that the current electronic device 100 is moving towards the target location L2, thereby determining that the current electronic device 100 is currently in the application scenario corresponding to the target location L2, such as the target location If L2 is the subway entrance of a subway station, the application scene is a subway scene. If the target location L2 is the entrance of a shopping mall, the application scene is a shopping mall scene.

In one embodiment, when the current electronic device 100 detects a preset operation instruction, interaction information is collected through the electronic device 100 (such as the current electronic device or other electronic devices 100 that are communicatively connected to the current electronic device 100). According to the interaction The information determines the initial application scenario in which the current electronic device 100 is currently located; outputs prompt information according to the initial application scenario, and obtains input information input according to the prompt information; and determines the application scenario in which the current electronic device 100 is currently located based on the input information.

Specifically, the preset operation may be a "shake" operation, which can obtain the change amount of the current acceleration of the electronic device 100. If the change amount of acceleration is greater than the preset change amount, it is determined that the preset operation instruction is detected.

When the current electronic device 100 detects a preset operation instruction, the current electronic device 100 collects interaction information, thereby determining the initial application scenario in which the current electronic device 100 is located based on the interaction information. In this way, the current electronic device 100 can save time and effort. power consumption. The method of determining the initial application scenario is similar to determining the application scenario based on location information, orientation information and movement information in the previous embodiment, and will not be described again here.

Please refer to FIG. 7 . At this time, the initial application scenario determined by the current electronic device 100 may not be accurate. Therefore, the current electronic device 100 will output prompt information on the display screen. For example, the prompt information may include the name of the initial application scenario and the determined button. After seeing the prompt information, the user can click the corresponding OK button to enter the input information according to the prompt information and determine the final application scenario based on the input information. For example, the prompt information is "Is it a subway scene?" and the confirmation button includes "Yes" and "No". If the user clicks "Yes", the input information is that the application scene is a subway scene. If the user clicks "No", the input information is The application scenario is not a subway scenario.

Please refer to Figure 8. Further, the prompt information may also include the input box K. After the user clicks "No", the user can enter the name of the application scenario according to the actual application scenario, so that if there is a deviation in the determination of the application scenario, Accurately determine application scenarios based on input information.

Referring to Figure 2, Figure 3 and Figure 9, in some implementations, step 011 also includes:

0112: Determine the application script corresponding to the application scenario, where the application script includes at least one service identifier;

0113: Use the set of services corresponding to all service identifiers in the application script as a service set.

In some implementations, the scene awareness module 11 is also used to perform step 0112 and step 0113.

In some embodiments, the processor 20 is used to perform

steps

0112 and 0113.

Specifically, the application script may include at least one service identifier. Each service in the application script can be found in the application market of the server 200 through the service identifier. Each service identifier may have a corresponding service; the application script may also include It is used to control the control logic between services in the service collection corresponding to the application scenario. For example, a script language is used to describe a common business logic. Among them, the script language can be xml or javascript. The calling and management relationships between services are implemented through application scripts, and the application script describes a common business logic.

When determining the application script corresponding to the application scenario, the service list corresponding to the application scenario can be determined first. The service list includes at least one service identifier corresponding to the service. Based on the at least one service identifier included in the service list, a service list corresponding to the application scenario can be generated. Application script.

When generating an application script based on the service list, first generate an initial application script corresponding to the application scenario based on the service identifier in the service list. Then, the initial application script can be generated based on the editing data of the initial application script and/or the user portrait data of the current user. The application script is adjusted to obtain an edited application script. The edited application script is the application script corresponding to the application scenario.

The current editing data can be determined based on the user's input information, the interaction information collected in the application scenario, the user's historical editing data of the application script, etc.

That is to say, as users continue to use electronic devices, editing data and user portrait data are constantly updated, and the service set corresponding to each application scenario is also constantly updated, so as to target different users of the same application scenario. Identify personalized service collections to enhance user experience.

In one implementation, the editing data may also be determined based on the user's subscription operation to the service.

The subscription initiator device can obtain the service list of all services by accessing the application store server, and then receives the subscription operation for the services in the service list. Based on the service identifier corresponding to the service subscribed by the user, the application script corresponding to the application can be generated. It can be understood that a service can be used as an application in the application store alone, and multiple services subscribed by users can also be used as an application in the application store.

Schematically, as shown in Figure 10, the user can access the application store and search for all services corresponding to a specific application scenario (such as scenario A) through the search box 72 in the application store interface 71 to form a service list. Each service corresponds to a subscription. Button 73. After the service receives the user's click operation on the subscribe button 73, the subscribe button 73 changes to the unsubscribe button 74, which indicates that the service has been subscribed. Clicking the unsubscribe button 74 can cancel the subscription of the corresponding application. Based on the service identifier corresponding to one or more services that have been subscribed, the application script corresponding to the application scenario can be generated.

Refer to Figure 11. When the device detects that the user's application subscription has changed, it downloads the application script of the user's newly subscribed application from the app store to the device.

For example, after the cloud (such as server 200) detects that the application subscriptions of device A and device B have changed, it will send the service identifiers of the newly subscribed applications of device A and device B to device A and device B respectively through change notifications, and then device A and device B downloads the corresponding application script from the application store according to the corresponding service identifier to complete application deployment.

After the application script is determined, a set formed by services corresponding to at least one service identifier included in the application script can be used as a service set. For example, multiple service identifiers corresponding to the control logic of a trigger can be used as a service set, or multiple service identifiers corresponding to the control logic of all triggers in the application script can be used as a service set.

Referring to Figure 2, Figure 3 and Figure 12, in some embodiments, step 012 includes:

0121: When a trigger event is detected in the application scenario, trigger the target trigger corresponding to the trigger event in the application script;

0122: Call the corresponding target control logic in the application script through the target trigger, and determine the target service corresponding to the trigger event in the service collection according to the target control logic.

In some implementations, the service governance module 12 is used to perform step 0121 and step 0122.

In some implementations, the processor 20 is used to perform step 0121 and step 0122.

Specifically, please refer to Figure 13. The application script can be composed of several triggers (Trigger A, Trigger B, Trigger C and Trigger D in Figure 13), and each trigger is composed of a trigger event, a control Logic and several services controlled by control logic. Among them, the service in the application script is not the service itself, but the service identifier of the service (service 1, service 2 and service 3 in Figure 13).

Among them, trigger events include events generated by interaction (such as reaching a specific location, time, user interaction input, etc.), and the control logic is the business logic corresponding to the trigger, which is usually composed of multiple services according to specified logic. When a trigger event occurs, a specific trigger is triggered to execute the corresponding control logic and call the corresponding service according to the control logic.

Please refer to Figure 14. Multiple triggers in the application script are related in business, and they work together to complete a scenario application. This scenario application needs to respond to multiple different events (i.e. trigger events), and each event corresponds to a behavior (the action in Figure 14). By creating different triggers and combining them together to form a complete application.

For example, scenario applications that meet the user needs of "music on the go". The trigger event is that when the user is in the living room, the action is that the sound flows to the speaker in the living room and is played. The trigger event is that when the user walks to the bedroom, the action is that the sound flows to the speaker in the bedroom and is played. The trigger event is that when the user leaves the room, the action is that the sound is played. Play on mobile phones and Bluetooth headsets.

In the application scenario, when a trigger event is detected, the target trigger corresponding to the trigger event in the application script can be triggered; the target control logic corresponding to the target trigger is called through the target trigger, and the target control logic is used to determine The target service in the service collection that corresponds to the triggering event.

For example, after the trigger event shown in Figure 13 is triggered, the target trigger corresponding to the trigger event in the application script (ie, trigger A) can be determined, and then the target control logic corresponding to trigger A can be called through trigger A. (ie, the control logic in Figure 13), thereby determining the target service (such as service 1, service 2, etc.) in the service set corresponding to the triggering event through the target control logic.

It can be understood that the number of services controlled by the target control logic can be multiple, and the multiple services are executed according to the target control logic. For example, the multiple services controlled by the target control logic are sequenced and can be executed in sequence. In this way, the target service to be executed currently can be determined based on the target control logic.

Optionally, the triggering event can also be an event triggered by the user, such as a tap event, a shake event, etc., or it can be an event output after calling a service, such as an event returned after the service call corresponding to the previous trigger is completed. event, this embodiment does not limit this.

The services in the application of this application are connected in series by control logic, and the device to which it is deployed can be determined at runtime. Therefore, after the current electronic device 100 downloads the application script, the service set called through the control logic will be processed at this time. deploy. After the application is running, according to the requirements of the control service logic, different services can be deployed to the same device, or differentially deployed to different devices, and perform different tasks on different devices. The deployment process is dynamic. If the device deployment service fails on multiple devices, the user will be prompted that the current service is unavailable.

For example, please refer to Figure 15. For a cross-device screenshot application, the services called to realize cross-device screenshot include two-finger tap service, picture display service and screen capture service. When a user account subscribes to a cross-device screenshot application, the mobile phone, tablet, car, and TV under the user account will all download the corresponding application script, and after downloading the application script, two-finger tap will be pre-deployed based on the initial trigger. Serve.

When the user taps the screen of the mobile phone with two fingers, the trigger event is determined to be "cross-end screenshot". Based on the target trigger and target control logic in the application script, the mobile phone determines that the executed business logic is a request to call other devices (such as tablets, cars, etc.) Screen capture service on the computer, TV, etc.).

After receiving the request, other devices determine that the trigger event is "take a screenshot." Based on the target trigger and target control logic in the application script, other devices determine that the business logic to be executed is to deploy the screenshot service, and run the screenshot service to take a screenshot of the current interface. Take a screenshot and send the screenshot to your phone.

After the mobile phone receives the screenshot, it determines that the trigger event is "display image". Based on the target trigger and target control logic in the application script, the mobile phone determines that the business logic to be executed is to deploy the picture display service and run the picture display service to display the screenshot. In this way, cross-end screenshots can be achieved through dynamic deployment of services.

Referring to Figure 2, Figure 3 and Figure 16, in some embodiments, step 013 includes:

0131: Initiate a target call request to the target service, where the target call request contains the initial call information of the target service;

0132: Call the corresponding service agent according to the initial call information in the target call request, and determine the target call information corresponding to the initial call information through the service agent.

In some implementations, the service governance module 12 is also used to perform step 0131 and step 0132.

In some embodiments, the processor 20 is used to perform step 0131 and step 0132.

Specifically, please refer to Figure 17. After the service is registered, the electronic device 100 can directly call the service; or after the user orchestrates the registered services to form an overall application, the application can be called, for example, as shown in Figure 10 By subscribing, one or more application scripts corresponding to different application scenarios are generated. Then, the electronic device 100 quickly determines the target service according to the application scenario and the triggering event.

After determining the target service, the processor 20 may first initiate a target call request for the target service, where the target call request includes initial call information of the target service, and the initial call information may include basic attributes of the service, such as service name, service ID, service description, etc.; the method of calling the service, such as the calling protocol type, some private parameters of the protocol, etc.; the parameter definition of the service: such as the service's input parameter list (such as parameter ID, parameter name, parameter type, etc.), output parameters, etc. List (such as parameter ID, parameter name, parameter type, etc.), conversion rules between service type parameters (such as conversion script, description, service ID, etc.), etc.

Among them, in order to achieve compatibility between services of the same type, the conversion rules between the parameters of the current service and the standard parameters are defined when the service is registered (that is, the conversion rules between service type parameters). For example, the navigation service includes navigation service A and navigation service B. The destination parameter in navigation service A is "destination" and the destination parameter in navigation service B is "final location". By establishing the parameters and standards of navigation service A, Conversion rules between parameters, and service type parameters between parameters of navigation service B and standard parameters, thereby achieving parameter compatibility between services. Navigation service A and navigation service B can be called through standard parameters. For example, through the standard parameter "arrival point", navigation service A and navigation service B can be called for destination navigation.

For example, the parameters of the service are defined in the following table:

参数名称parameter name	数据类型type of data
服务名称service name	字符串string
服务IDService ID	字符串string
服务分类Service classification	整型integer
创建时间creation time	整型integer
服务描述Service description	字符串string
入参列表Input parameter list	数组array
参数IDParameter ID	字符串string
参数类型Parameter Type	字符串string
参数名parameter name	字符串string
出参列表Out parameter list	数组array
参数IDParameter ID	字符串string
参数类型Parameter Type	字符串string
参数名parameter name	字符串string
输入输出转换列表Input and output conversion list	数组array
描述describe	字符串string
转换脚本conversion script	字符串string
服务IDService ID	整型integer

The initial call information may be stored in the electronic device 100, or the initial call information may be stored in the server 200, and the processor 20 may also receive the initial call information corresponding to the target service sent by the server 200.

Then, the processor 20 calls the service agent corresponding to the initial call information according to the initial call information in the target call request, thereby converting the initial call information into the target call information through the service agent.

It can be understood that the service agent can be deployed locally, such as deploying the service agent on the electronic device 100; or, the service agent can be set on the server 200 in the cloud, the processor 20 sends the target call request to the server 200, and the server 200 calls according to the target call request. The corresponding service agent converts the initial call information into target call information.

Please continue to refer to Figure 17. It can be understood that in order for the application to support heterogeneous operating systems to achieve cross-platform operation, a unified format of target call requests needs to be used when making service calls. The service gateway can pass the local (such as the electronic device 100) or The service agent deployed by the server 200 converts the target call request in the same format into a real service call, that is, a service call that conforms to the current platform service specification.

After the service proxy conversion, the initial call information can be directly converted into target call information that can be used by the current electronic device 100 to directly run the target service, so that the target service can comply with the platform service specification of the current electronic device 100 .

If the Messenger service, deeplink service, etc. shown in Figure 17 is called, the interface adaptation is performed according to the service proxy of the service gateway, so that the target call request conforms to the real service call of the Messenger service, deeplink service, etc., and the Messenger service, deeplink service, etc. are correctly called. .

In some embodiments, the initial call information includes service type and registration call information; the service type may include Android system services, windows system services, etc., and the registration call information includes the above-mentioned basic attributes of the service, the calling method of the service, and Service parameter definition.

Based on the service type required to provide services, the electronic device 100 can be deployed with different service agents as needed, where different service agents correspond to different programming development languages (such as java, js, php, C, C++, etc.), or , Different service agents correspond to different deployment forms (such as applets, browser plug-ins, applications, etc.), or different service agents correspond to different operating environments (such as virtual machines, browsers, operating systems, containers, etc.) ).

And because different operating systems have different upper-level abstraction methods for processes, as well as different calling methods between processes, the same call request will be converted into different specific real calls within the service gateway. The conversion of each service type can be completed by the designated service agent. The service agent can be increased and decreased according to the actual deployment situation. For example, the service gateway of Windows only needs to deploy Windows-related service agents, and the service gateway of Android only needs to deploy Android Relevant service agents.

Illustratively, as shown in Figure 18, the service gateway may include at least one of Android Service agent, cloud restful agent, Android dynamic service agent and Web dynamic service agent. For example, for Android Service, the initial call information can be converted into target call information through Android Service, thereby adapting to electronic devices 100 of different systems or platforms. For another example, for cloud restful services, the initial call information can be converted into target call information through the cloud restful proxy, thereby adapting to electronic devices 100 of different systems or platforms. I won’t list them all here.

In some implementations, a service may be invoked through an interface exposed by the service.

For example, define the externally exposed interface of the RestFul service in the cloud in the following format:

Define the externally exposed interface of the Deeplink service on the Android side as follows:

Among them, the type information represents the real interface type of the service. Different types have different attributes that need to be configured. Provider type information refers to which application can support this service. For example, navigation services can be provided by Amap or Baidu. The link information refers to the address to access the cloud. Link standard information refers to the link's calling method.

When calling the interface exposed by the target service, the service gateway will select the corresponding service agent based on the service type in the initial call information (corresponding to the type information in the interface definition), and then the service agent will convert the registered call information into an adapted real Target call information for the service provider's interface type.

Therefore, the service provider does not need to make interface adaptation modifications. He only needs to specify this information when registering the service to quickly determine the accurate service agent, thereby realizing the conversion of the registered call information to the target call information, and finally based on the target call information Run the target service, such as calling the interface exposed by the target service and input the target call information (such as input parameters) to the interface. The target service outputs the output parameters according to the input parameters, thereby realizing the call of the target service.

In this way, the target service can be normally run by the electronic device 100 of any system or platform, realizing cross-platform operation of the target service.

Referring to Figure 2, Figure 3 and Figure 19, in some implementations, legality verification includes the following:

015: Verify the legality of the target call request through the target service gateway;

016: When the target service gateway passes the verification of the target call request, the corresponding service agent is called according to the initial call information in the target call request, and the target call information corresponding to the initial call information is determined through the service agent.

In some implementations, the service governance module 12 is also used to perform

steps

015 and 016.

In some embodiments, the processor 20 is used to perform

steps

015 and 016.

Specifically, before converting the initial call information to the target call information, the target service gateway can first verify the legality of the target call request. If the legality verification passes, the target service gateway can continue to use the service agent corresponding to the initial call information. Conversion of initial call information to target call information. The legality verification may be to verify whether the user of the electronic device 100 is legal. Only the electronic device 100 that passes the legality verification can access the service gateway.

Legality verification can also be done by:

When the target service gateway is the service gateway of the current electronic device 100, the target call request is verified for legality through the target service gateway. For example, the current service gateway of the electronic device 100 is the service gateway that calls the target service.

When the target service gateway is the service gateway of the external electronic device 100, the target call request is sent to the external electronic device 100, and the processing result returned by the external electronic device 100 is received. The processing result is that the external electronic device 100 passes the target service gateway Obtained in response to the target call request when the legality verification of the target call request passes.

That is to say, the service invocation and the legality verification of the gateway are performed in different service gateways respectively. When the service gateway of the external electronic device 100 performs legality verification, the target call request can be sent to the external electronic device 100, thereby according to The processing result is used to determine whether the legality verification is passed. When the legality verification is passed, the processing result is responded to, thereby converting subsequent initial call information to target call information.

Referring to Figure 2, Figure 3 and Figure 20, in some embodiments, step 014 includes:

0141: When the target service is the first service type, run the target service according to the target call information;

0142: When the target service is the second service type, determine the host service corresponding to the target service, and when the host service is in a running state, run the target service according to the target call information.

In some implementations, the service running module 13 is also used to perform step 0141 and step 0142.

In some embodiments, the processor 20 is configured to perform

steps

0141 and 0142.

Specifically, the service includes different service types. For example, the service includes a first service type and a second service type. The first service type may be a dynamic service and the second service type may be a static service.

As a pre-installed service, the static service depends on the host application and needs to be installed and the host service in the host application is running before the static service can be called.

Dynamic services refer to services that support dynamic deployment and can be dynamically deployed in the device while the application is running. As a service that supports dynamic deployment, dynamic services do not rely on pre-installed applications for invocation, and the dynamic services available for invocation are uniformly stored in the server 200 in the cloud. When the target service is of the first service type, the target service can be directly obtained from the server 200 and dynamically deployed, thereby directly running the target service according to the target call information.

In a possible implementation, the target service is a static service, that is, a pre-installed service. The pre-installed service defines a host application and an access path. The service governance module 12 is used to manage static services provided by the host application in the local device. After obtaining the target call information, the service governance module 12 queries the target service in the local device, and then determines the host service corresponding to the target service, and runs the target service. Before, you need to run the host service first to ensure that the target service can run normally according to the target call information.

Optionally, if the target service is successfully started, the electronic device 100 can determine the target service agent corresponding to the target service according to the initial call information of the target service (the service type in the initial call information), and perform the processing through the target service agent. Parameter conversion, thereby obtaining the target service code set corresponding to the target service stored in the current electronic device 100 based on the host application and access path corresponding to the target service (the interface exposed by the target service), thereby calling the target by running the target service code set Serve.

Optionally, if the target service fails to start, or the target service does not meet the pre-installation conditions (for example, the host application is not installed, the host service is not running, etc., causing the target service to be unavailable), the electronic device 100 will issue a failure prompt.

In an illustrative example, the calling process of static services is shown in Figure 21.

Step 1801: Initiate a target call request for the target service to the service gateway.

Step 1802: The service gateway verifies whether the request is legal; if it is legal, step 1803 is executed; if not, step 1809 is executed.

Step 1803, detect whether the host service is started; then start the target service, and perform step 1804; if it is not started, it will prompt that the target service failed to start.

Step 1804: Check whether there is a target service agent corresponding to the target service; if it exists, perform step 1805; if it does not exist, perform step 1809.

Step 1805: Convert the initial call information in the target call request into target call information through the target service proxy.

Step 1806: Call the target service based on the converted target call information to obtain output parameters.

Step 1807: Convert the output parameters through the target service proxy to generate the calling result.

Step 1808, return the call result.

Step 1809, return call failure.

In another possible implementation, the target service is a dynamic service, and the service governance module 12 obtains the target service code set corresponding to the target service sent by the server 200, thereby running the target service code set according to the target call information, To achieve the call of the target service.

Optionally, the electronic device 100 needs to determine the target service agent corresponding to the target service based on the initial call information of the target service, and perform parameter conversion through the target service agent, thereby outputting the converted target call information, so that based on the target call information Call the target service.

In an illustrative example, the calling process of dynamic services is shown in Figure 22.

Step 1901: Initiate a target call request to the service gateway.

Step 1902: The service gateway verifies whether the request is legal; if it is legal, step 1903 is executed; if not, step 1910 is executed.

Step 1903: Check whether there is a target service agent corresponding to the target service; if it exists, perform step 1904; if it does not exist, perform step 1910.

Step 1904: Convert the initial call information in the target call request into target call information through the target service agent.

Step 1905: Check whether the target service is deployed; if it is deployed, perform step 1906; if it is not deployed, perform step 1907.

Step 1906: Call the target service based on the converted target call information to obtain output parameters.

Step 1907: Download and deploy the target service from the application warehouse, and call the target service based on the converted target call information to obtain output parameters.

Step 1908: Convert the output parameters through the target service proxy to generate the calling result.

Step 1909, return the call result.

Step 1910, return call failure.

For different service invocation types, subsequent steps after the electronic device 100 completes the service invocation are also different. In a possible implementation, when the target service is a synchronous call service, the electronic device 100 obtains the call result of the target service, and then calls the next service based on the call result (until the call of all services under the trigger is completed) ; When the target service is an asynchronous calling service, the electronic device 100 obtains the service output event of the target service, thereby triggering the trigger in the target application script through the service output event.

Among them, the service return value can be data, files, instructions, etc. For example, the return value of the screenshot service can be the captured picture; the trigger triggered by the service output event can be a trigger other than the target trigger, or it can be the target Trigger, this embodiment does not limit this.

Please refer to Figure 23 and Figure 24. In some implementations, the main process of service operation is as follows:

Step 2101: The trigger event triggers a specific trigger in device A.

Step 2102: Device A executes the control logic of the trigger.

Step 2103: Device A executes business logic according to the control logic, changes status information and synchronizes it. The state information on one or more devices is peer-to-peer and can maintain all the state information required for the application to run. When the state information on one device changes, the state information of all devices is synchronized to the latest state through data synchronization. .

In an example, as shown in Figure 25, when different devices under the same user account are running the same application, device A deploys service 1 and service 2, device B deploys service 1 and service 3, and device C deploys service 4 and service 5. When service 3 in device B is called, the output event of service 3 changes the status information. Device B synchronizes the status information to device A and device C through data synchronization so that device A and device C can update their own status information. When service 5 in device C is called, the output event of service 5 changes the status information. Device C synchronizes the status information to device A and device B through data synchronization so that device A and device B can update their own status information.

Through the above synchronization mechanism, each device under the user account is equal, and the disconnection of a single device will not affect the operation of the application. For example, when a screen image of another device is intercepted by tapping with two fingers and sent to the current electronic device 100, the user can complete this operation by tapping on any device, and any device goes offline without affecting other devices. Take a normal screenshot.

Step 2104: The service management module calls the target service according to the control logic, and the target service can be called through the service gateway. For example, the service management module calls service 2 of device C through the service gateway. The target service can be one or more, displayed in a list. If there is only one service in the service list, the service is called directly. If there are multiple services, the appropriate service is selected according to the policy.

Currently, two strategies are provided. Strategy 1 is to pop up a service list for users to choose; Strategy 2 is to assist users to automatically determine the target service based on user information, device information, user behavior, service information and other data, such as running the target service based on the user. Historical usage information over time to determine target services.

Step 2105. For synchronous calls, the application directly obtains the return value of the service when it is running, and uses this return value as an input parameter as the input value of subsequent services. If there is subsequent business logic, return to step 1003, otherwise the execution ends. .

Step 2106: For asynchronous calls, the called service sends a trigger event to device A after completing the service. Device A responds to the trigger event and triggers a specific trigger, and returns to step 1001 again.

Please refer to Figure 2, Figure 3 and Figure 26. In some embodiments, the initial call information includes registration call information and/or dynamic call information; step 013 includes:

0133: Obtain the registration call information of the target service currently stored in the electronic device 100, and/or obtain the dynamic call information generated by other services; wherein the registration call information is used to represent attributes related to the target service, and the dynamic call information is used to represent the operation Input variables required by the target service;

0134: Determine the target call information based on the registered call information and dynamic call information.

In some implementations, the service governance module 12 is also used to perform step 0133 and step 0134.

In some embodiments, the processor 20 is configured to perform

steps

0133 and 0134.

Specifically, the initial call information includes registration call information and/or dynamic call information; the registration call information is used to represent attributes related to the target service. Please refer to the foregoing description for its specific content, which will not be described again here. The dynamic call information includes other services or input variables generated by the electronic device 100. For example, the input variables of the target service are related parameters generated by other services in the target service set except the target service.

When running the target service according to the target call information, input the input variables into the target service to obtain the output variables, thereby realizing the operation of the target service.

The specific calling process can be: The interface exposed by the target service is: POST http://xxx.x.x.x:8888/service/call. The interface needs to obtain the following information:

{A:String,//Type information

B: String, //The device that calls the service. If the device that calls the target service is the current electronic device 100, set it to "local" or set it to empty. If it is determined that the target service is called for other devices, you need to specify the ID of the other device. For example, when a watch connected to a mobile phone calls the target service, enter the ID of the watch to directly control the watch to call the target service through the mobile phone.

C:[],//Input parameter list for service call (i.e. input variable)}

It can be seen that when calling the target service through the interface, you need to specify the service type, the device where the service is located (you can specify a device to call the target service or filter out a device), and the input parameter list, where the input parameter list can include Enter variables.

The target service can output output parameters based on the above information. For example, if the current electronic device 100 calls the cloud map service for navigation, then among the input parameters, the type information is cloud restful, the device calling the service is "local", and the input variable includes the destination address. , the target service outputs the navigation route and surrounding maps as output parameters to achieve navigation.

In one example, for the subway scenario, after the user takes the subway, the target service is determined to be the arrival reminder service. When the user arrives at each station, the arrival reminder is performed. That is to say, when the arrival reminder service is called , the arrival reminder service will output site information according to the location information input by the electronic device 100 (that is, as an input variable). When the output site information is the destination site, the ride code service will be called based on the destination site (that is, as an input variable). , thereby outputting the ride code information.

In another example, for a cross-end screenshot scenario, if a cross-end screenshot triggering event is detected (such as the current electronic device 100 receiving a screenshot gesture), the screenshot gesture service is run, and the screenshot gesture is used as an input variable to request the call to other electronic devices. Screen capture service of device 100 (such as a device logged in with the same account as the current electronic device 100). The screen capture service will send the screenshot to the current electronic device 100 after taking a screenshot according to the screenshot gesture.

For ease of understanding, please refer to Figure 27. The following describes the overall operation process of the service scheduling method of this application.

As shown in steps S1 and S2 in the figure, the service of this application is developed by the service developer and uploaded to the server 200. In the narrow sense, it refers to the services developed by developers according to the preset service framework; in the broad sense, it refers to services developed by general service developers, that is, services that are not developed according to the preset service framework.

Step S3: The scene sensing module 11 senses the application scene.

In step S4, the electronic device 100 detects a trigger event based on the interaction information.

Step S5: After detecting the triggering event, the service management module 12 can determine the trigger corresponding to the triggering event, thereby determining one or more target services corresponding to the control logic in the trigger.

Step S6: If the electronic device 100 does not have the target service locally, download the target service from the server 200 and deploy it to the electronic device 100.

Step S7: If there are multiple target services, determine the target service according to user selection, or automatically assist the user to automatically determine the target service based on user information, device information, user behavior, service information and other data.

Step S8: Deploy the target service to the electronic device 100 and call it. The target service can be deployed on the current electronic device 100 or on other devices on different systems or platforms to achieve cross-platform operation.

Step S9: When invoking the target service, the service management module 12 may send a target invocation request to the service gateway.

Step S10 , the service gateway determines the service agent corresponding to the service type in the target call request, the service agent converts the registered call information into target call information, and sends the target call information to the service running module 13 .

Step S11: The service running module 13 runs the target service according to the target calling information.

Please combine Figure 28 and Figure 29. In one example, the scene sensing module 11 of the electronic device 100 determines that the vehicle has arrived at the shopping mall based on the location information, thereby determining that the application scene is a shopping scene. When the user arrives at the entrance of the parking lot, the service management Module 12 detects that the trigger event is "parking space navigation", and the service management module 12 determines the trigger corresponding to "parking space navigation" and determines one or more target services (such as navigation services) corresponding to the control logic in the trigger. If the electronic If the navigation service is not deployed locally on the device 100, the navigation service is downloaded from the server 200 and deployed.

After the navigation service deployment is completed, the service governance module 12 calls the navigation service. The service governance module 12 sends a target call request to the service gateway. The service gateway determines that the service type in the target call request corresponds to the service agent. The service agent converts the registered call information into the target. Call the information and send the target call information to the service operation module 13. The service operation module 13 runs the navigation service to guide the user to park to an empty parking space.

After parking is completed, the service management module 12 detects that the trigger event is "shopping" (for example, the location corresponding to the location information of the electronic device 100 is located at the entrance of the mall), the service management module 12 determines the trigger corresponding to "shopping", and determines the trigger One or more target services (such as shopping services) corresponding to the control logic in , if the shopping service is not deployed locally on the electronic device 100, the shopping service is downloaded from the server 200 and deployed.

Finally, the service governance module 12 calls the shopping service. The service governance module 12 sends the target call request to the service gateway. The service gateway determines that the service type in the target call request corresponds to the service agent. The service agent converts the registered call information into the target call information and sends The target calls the information to the service running module 13, and the service running module 13 runs the shopping service to guide the user to shop.

When the shopping service is running, the shopping guide interface will be displayed. The shopping guide interface displays the partitions of different products in the current mall. After the user clicks on any partition, it is determined that the trigger event of "navigation in the mall" is detected, and the shopping service will perform navigation in the mall. To navigate the user to the corresponding section, if the user clicks on the daily necessities area, the shopping service will automatically navigate the user to the daily necessities area.

After arriving at the daily user's department store area, the shopping service will recommend hot-selling products and display the product recommendation page, such as hot-selling product 1, product 2, and product 3 in Figure 29. Similarly, after the user clicks on any product, After confirming that the trigger event of "navigation in the mall" is detected, the shopping service can also perform product navigation and navigate the user to the location of the corresponding product.

Then after the user reaches the location of the product, if the electronic device 100 (such as a watch, mobile phone, etc.) is close to the electronic label of the product, it is determined that the trigger event of "add to shopping cart" is detected, so that the product can be automatically added to the shopping cart. After all the required products are added to the shopping cart, if it is detected that the electronic device 100 is located in the preset checkout area of the mall, it is determined that the trigger event of "payment" is detected, and the electronic device 100 automatically displays Payment code to make payment.

After making payment, users only need to walk to the designated receiving area to get all purchased items without having to carry them in the mall themselves. After the user reaches the receiving area, the receiving code can be displayed, such as 05814 in Figure 29. By showing the receiving code, all the purchased goods can be obtained. The receiving area can be a preset area of the mall, or It can be delivered to the user's home by mall employees. In this way, a light and simple shopping experience can be achieved

In some implementations, this application provides a new development model, a layered development model, by turning applications into services.

Specifically, the system provides a common mechanism to shield application-related complex details. Service developers only need to provide services with a single function, which can be used by multiple applications. Service developers can be ordinary developers. Application developers focus on business logic, and the system provides code/low-code development methods. Application developers can be ordinary developers or ordinary users, which lowers the development threshold and expands the developer base.

Application development is divided into three roles. For external developers, they are mainly divided into service developers and application developers.

As a component of the application, the main processes of services are:

1. Development services.

The application store of this application can theoretically access the services of any operating system and platform. Therefore, developers can maintain the original development methods. Developers of different platforms such as Windows, Android, Cloud, etc. can use the technologies they are familiar with to develop related Serve.

2. The dynamic service is submitted to the server 200.

The system provides some dynamic service mechanisms. If the developer develops the dynamic service provided by the system, after the developer completes the development of the service, he needs to package the service and submit it to the server 200.

3. Application store access service.

The main sub-processes of service development are as follows:

1. The third-party service provider publishes services in the app store, specifying the name of the service, description of the service and other relevant information.

2. The method of calling third-party services, including the calling path, input parameters, output parameters, conversion rules between input parameters and output parameters, etc.

3. There are two types of third-party service installation information. One is a pre-installed service. For example, the service of playing a video is obtained with the installation of the iQiyi application. You need to specify the host application information and supported versions; One is a dynamic service. The code of the dynamic service is in the server 200 and can be dynamically deployed to a designated device. It is necessary to specify the type of the dynamic service and the address of the dynamic service in the application store.

4. After submitting the service, the service will be reviewed by the app store. If it passes, the service can be seen in the application development tool.

Development process for application developers:

Application development tools at different levels, including code, low-code, and no-code, will be provided so that both professional developers and ordinary users can develop applications.

In some implementations, users can share applications.

Applications run based on users. Among different users, the system provides a unified framework to support sharing of applications among different users. Application developers only need to specify relevant sharing interactions (such as Pengpeng, QR code, SMS, WeChat, etc.) when packaging the application. No additional code development is required to realize the sharing of applications among different users. , and provide a set of mechanisms to authorize and withdraw sharing to ensure the safety of the behavior.

This mechanism will greatly improve the application experience: for example, the application shares the clipboard, allowing devices under the user's name to share complex pastes. If you touch a friend's phone, you can copy the content on your phone and use it on your friend's phone. You can paste it directly on your mobile phone. The multi-camera camera application allows you to select the cameras of all devices under your name when taking pictures. If you touch a friend's phone, you can choose the camera of his phone; such as a batch photo processing application on the phone, and a friend's phone When the mobile phone is touched, the processing speed is doubled; when it is touched with the computer, the processing speed is increased by 3 times.

Or, like the collaborative drawing board, multiple devices of the user can collaboratively doodle, which can run on any device and system, and can be transferred among the user's devices; if it touches other users' mobile phones, or sends links to other users, Then you can doodle together. For example, Super Games distributes the audio, video, and control capabilities of the host device running the game to different target devices, realizing the ability to share a game process among multiple target devices; if it collides with other users' mobile phones, With just one touch, you can transfer the current game's graphics, sounds, controls and other capabilities to other users' phones.

Based on the above implementation, the application of this application has the following characteristics:

1. Compared with traditional applications that follow devices, the applications of this application follow people. Users obtain applications bound to themselves through subscription services. Applications are only bound to users, not to specific devices.

2. The application of this application is naturally distributed. Different services of the application can be deployed to the same device, or differentially deployed to different devices, and perform different tasks on different devices, and can support the operation of multiple devices.

3. The application of this application supports heterogeneous operating systems, and realizes the conversion of initial call information to target call information through the service gateway, so that the services of the application (application 3 in Figure 4) can be services on different operating systems, so that Runs across multiple platforms.

4. The services in the application of this application can support dynamic deployment, that is, users can download them from the application store only when they need to use the service, thereby supporting a click-and-run user experience.

5. The definition of the application in this application is consistent on different devices, ensuring consistent user experience; and when the functions of the same application are implemented through multiple devices, since the business logic of different devices may be different, different device deployments There may also be differences in the services. The service set of the application is different on different devices, which has the characteristics of differential deployment, so that the characteristics of different devices can be utilized.

6. The application of this application is a service assembly application. The service can be used by multiple applications. The application is composed of multiple services. The service is highly reusable, which reduces the difficulty of development.

7. The visual development tool of this application lowers the development threshold, allowing ordinary users to develop micro-applications, especially micro-applications related to device characteristics, to improve the device usage experience.

8. This application provides an entrance for third-party application developers to access. Third-party services only need to specify the service name and description, as well as the service calling method and other information, so that third-party applications can be used without modifying the original application. , very convenient to access the system.

9. The user subscription system of this application makes it possible to personalize the device experience. Since applications are bound to users, the same device will have different applications after switching to different users, so that users can subscribe to different applications. Let the same device have different characteristics in the hands of different users.

10. The unique sharing system of this application, such as application sharing clipboard, can allow micro-applications to produce effects among different users, increasing the interactive experience.

Please refer to Figure 30, which shows an architectural diagram of a service scheduling system 1000 provided by an exemplary embodiment of the present application. The system includes at least one electronic device 100 and a server 200 .

In a possible implementation, the electronic device 100 is provided with a service management module 12. As the core of controlling application operation, the service management module 12 includes a script management module 1211, an event bus module 1212, an application scheduling module 1213, and a runtime module. 1214 and service scheduling module 1215.

The script management module 1211 is used to manage the application scripts of each application stored in the electronic device 100, and is responsible for parsing the application scripts to determine the triggers in the application scripts and the services under the triggers. Optionally, the script management module 1211 is also configured to download the corresponding application script when receiving a subscription operation for the application, and delete the application script corresponding to the application when receiving a subscription cancellation operation for the application.

The event bus module 1212 is used to cooperate with the application scheduling module 1213 to implement application scheduling based on trigger events.

In some embodiments, the event bus module 1212 is mounted with triggers corresponding to multiple applications. Since the same trigger event may trigger multiple subscribed applications, after the event bus module 1212 receives the trigger event, it is handed over to the application for scheduling. Module 1213 determines the application that needs to be run from several applications. Among them, the application scheduling module 1213 can automatically determine the application based on the scheduling policy, or it can also let the user manually select the application.

The runtime module 1214 is used to execute the control logic in the application script, thereby interacting with the service scheduling module 1215 based on the control logic, and the service scheduling module 1215 makes service calls.

In addition to the service management module 12 , the electronic device 100 is also provided with a data synchronization module 14 and a service gateway 15 .

Among them, the data synchronization module 14 is used to synchronize the status of other devices when the status of the service management module 12 changes (for example, an event generated by the service causes a status change) to ensure the consistency of status information of different devices.

The service gateway 15 is used to perform service invocation based on the target invocation request of the service scheduling module 1215, and specifically includes an agent management module 151 and a life cycle management module 152. The agent management module 151 is provided with different service agents. The service agents are used to convert the initial call information of the target call request in a unified format to obtain target call information that conforms to the electronic device 100 .

The life cycle management module 152 is used to manage the life cycle of services.

During the application running process, the electronic device 100 can not only make service calls through its own service gateway 15, but also make service calls through the service gateways 15 of other devices or servers 200 (determined by the business logic of the application), that is, cross-device implementation can be achieved. service call.

For services in different deployment modes, as shown in Figure 31, the electronic device 100 is also provided with a static service module 16 and a dynamic service module 17. The static service module 16 is used to manage pre-installed static services, and the dynamic service module 17 is used to manage dynamically deployed dynamic services.

In some embodiments, the services included in the dynamic service module 17 can correspond to different running environments, different deployment forms, or different programming development languages. In FIG. 30 , the dynamic service module 17 includes an Android dynamic service 1251, a Web dynamic service 1252, and a container dynamic service 1253 as an example for schematic illustration, but this is not a limitation.

The server 200 is a server, a service cluster or a cloud computing center composed of several servers. The server cluster is divided according to the functions implemented by each server. As shown in Figure 30, the server cluster includes a user resource management server 212, an application store server 222, a service market server 223, and a cloud service library 224.

The user resource management server 212 is used to manage user accounts using applications, manage applications subscribed under different user accounts, manage called services, manage the binding relationship between user accounts and devices, and manage the interaction between user accounts and devices. Security verification is performed during the process.

The application store server 222 is used to provide application subscription services. When the user needs to use an application, he or she can search for the application through the application search engine provided by the application store server 222, and then select and subscribe to the application from the search results.

In some embodiments, after receiving the subscription operation for the application, the application store server 222 sends the user account and the service identification of the subscribed application to the user resource management server 212, and the user resource management server 212 updates the user account and the subscription of the application. relation. Further, the user resource management server 212 is also used to determine other devices under the user account and push subscription notifications to other devices so that other devices can download the application script of the application from the application store server 222. Illustratively, for example, after the user "Zhang San" subscribes to the application through a smartphone, the car and tablet computer logged in to the user account "Zhang San" receive the subscription notification pushed by the user resource management server 221, thereby based on the service in the notification Identifies the application script that downloads the application.

The service market server 223 is a developer-oriented server used to provide service query services. Developers can search for services through the service search engine provided by the service market server 223, apply the searched services to developed applications, and then upload the developed applications to the application store server 222 for other users to download and use.

In addition, developers can also develop dynamic services and upload the developed dynamic services to the application store server 222.

Subsequently, the electronic device 100 can download and deploy the dynamic service from the application store server 222.

It should be noted that the above embodiment only describes the basic architecture of the system. The system may also include other computer equipment (such as developer equipment) or servers that implement other functions. This embodiment does not limit this. The following explanation is based on the above-mentioned service scheduling system 1000 and combined with specific examples. Specifically, the user implements a cross-terminal screenshot application as an example to illustrate:

Specifically, please refer to Figure 30 and Figure 31. Users subscribe to cross-device screenshot applications through the application market. The user resource management server 221 pushes a subscription notification containing the service identifier of the cross-end screenshot application to all devices under the user account to facilitate subsequent service deployment.

Among them, cross-terminal screenshot applications include two-finger tapping service, picture display service and screenshot service. Among them, the script management module 1211 of all devices under the user account parses the application script, and determines that the two-finger tapping service needs to be deployed first based on the parsed content.

The user can perform a two-finger tapping action on any device (mobile phone 101 as shown in Figure 31), thereby triggering a screenshot event. The event bus module 1212 and the application scheduling module 1213 determine the service that needs to be run based on the screenshot event, and then schedule it by the service Module 1215 schedules the two-finger tap service. After running the two-finger tap service, the target call request to obtain the screenshot image of other devices is sent to other devices (computer 102 as shown in Figure 31), and the service gateway 15 of computer 102 The agent management module 151 determines the service agent of the target call request, and then converts the initial call information in the target call request to generate the target call information. The event bus module 1212 and the application scheduling module 1213 in the computer 102 cooperate to determine the need for deployment For services running in parallel (such as screen capture service), the service scheduling module 1215 schedules the screen capture service according to the target call information to obtain the screen capture image, and sends the call request containing the screen capture image to the mobile phone 101 again.

The agent management module 151 in the service gateway 15 of the mobile phone determines the service agent corresponding to the target call request sent by the computer, and then converts the initial call information in the target call request to generate the target call information, the event bus module 1212 and the application scheduling module 1213 In conjunction with determining the services that need to be deployed and run (such as image display services), the service scheduling module 1215 schedules the image display service according to the target call information. The image display service displays the screenshot image of the computer 102 according to the screenshot image contained in the target call information and can save it. , thereby achieving cross-end screenshots.

Then according to the control logic in the application script, call the screenshot service of other devices except the tapped device, determine that the executed business logic should be to take a screenshot and send it, thereby downloading and dynamically deploying the screenshot service, and calling the screenshot service to the current The electronic device 100 takes a screenshot and feeds it back to the mobile phone. After the mobile phone receives the screenshot image feedback from other devices, it calls the image display service to realize the screenshot display.

Referring to Figure 32, an embodiment of the present application also provides a non-volatile computer-readable storage medium 300 containing a computer program 301. When the computer program 301 is executed by one or more processors 20, the one or more processors 20 are caused to execute the service scheduling method of any of the above embodiments.

Please refer to Figure 1, for example, when the computer program 301 is executed by one or more processors 20, the processor 20 performs the following service scheduling method:

014: Run the target service based on the target call information.

Please refer to FIG. 6 for another example. When the computer program 301 is executed by one or more processors 20, the processor 20 performs the following service scheduling method:

In the description of this specification, reference to the terms "certain embodiments," "in an example," "exemplarily," etc., means that a specific feature, structure, material, or characteristic described in connection with the embodiment or example is included herein. In at least one embodiment or example. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

Any process or method descriptions in flowcharts or otherwise described herein may be understood to represent modules, segments, or portions of code that include one or more executable instructions for implementing the specified logical functions or steps of the process. , and the scope of the preferred embodiments of the present application includes additional implementations in which functions may be performed out of the order shown or discussed, including in a substantially simultaneous manner or in the reverse order, depending on the functionality involved, which shall It should be understood by those skilled in the technical field to which the embodiments of this application belong.

Although the embodiments of the present application have been shown and described above, it can be understood that the above-mentioned embodiments are exemplary and cannot be construed as limitations of the present application. Those of ordinary skill in the art can make modifications to the above-mentioned embodiments within the scope of the present application. The embodiments are subject to changes, modifications, substitutions and variations.

Claims

A service scheduling method, characterized by including:

Determine the current application scenario and determine the service set corresponding to the application scenario;

When a triggering event is detected in the application scenario, determine the target service corresponding to the triggering event in the service set;

Determine the initial call information of the target service, determine the target call information based on the initial call information, and the target call information matches the electronic device running the target service;

Run the target service according to the target call information.
The service scheduling method according to claim 1, wherein determining the current application scenario includes:

Obtain interaction information, and determine the current application scenario based on the interaction information.
The service scheduling method according to claim 2, wherein the interaction information includes location information, orientation information and movement information; the obtaining the interaction information and determining the current application scenario according to the interaction information includes:

When it is determined based on the location information that the current electronic device is within the preset location range, obtain the target location corresponding to the preset location range;

When it is determined that the current electronic device moves toward the target position according to the orientation information and movement information, it is determined that the current electronic device is currently in an application scenario corresponding to the target position.
The service scheduling method according to claim 2, characterized in that said obtaining interaction information and determining the current application scenario according to the interaction information include:

When the current electronic device detects a preset operation instruction, collect interaction information through the electronic device, and determine the initial application scenario in which the current electronic device is currently located based on the interaction information;

Output prompt information according to the initial application scenario, and obtain input information input according to the prompt information;

The application scenario in which the current electronic device is currently located is determined based on the input information.
The service scheduling method according to claim 1, wherein determining the service set corresponding to the application scenario includes:

Determine the application script corresponding to the application scenario, wherein the application script includes at least one service identifier;

A set composed of all services corresponding to the service identifiers in the application script is used as the service set.
The service scheduling method according to claim 5, wherein determining the application script corresponding to the application scenario includes:

Determine the service list corresponding to the application scenario;

Generate an application script corresponding to the application scenario according to at least one service identifier included in the service list.
The service scheduling method according to claim 6, characterized in that generating an application script corresponding to the application scenario according to at least one service identifier included in the service list includes:

Generate an initial application script corresponding to the application scenario according to at least one service identifier included in the service list;

Obtain the editing data of the initial application script and/or the user portrait data of the current user, adjust the initial application script based on the editing data and/or the user portrait data of the current user, and obtain the corresponding application scenario. Application script.
The service scheduling method according to claim 5, characterized in that, when a trigger event is detected in the application scenario, determining the target service corresponding to the trigger event in the service set includes:

When a trigger event is detected in the application scenario, trigger the target trigger corresponding to the trigger event in the application script;

The corresponding target control logic is called through the target trigger, and the target service corresponding to the trigger event in the service set is determined according to the target control logic.
The service scheduling method according to claim 1, characterized in that determining the initial call information of the target service and determining the target call information according to the initial call information includes:

Initiate a target call request for the target service, wherein the target call request contains initial call information of the target service;

The corresponding service agent is called according to the initial call information in the target call request, and the target call information corresponding to the initial call information is determined through the service agent.
The service scheduling method according to claim 9, characterized in that the initial call information includes service type and registration call information; the corresponding service agent is called according to the initial call information in the target call request, through the The service agent determines the target calling information corresponding to the initial calling information, including:

Call the service agent corresponding to the service type, and convert the registration call information into corresponding target call information according to a predetermined format.
The service scheduling method according to claim 9, characterized in that the corresponding service agent is called according to the initial call information in the target call request, and the target call information corresponding to the initial call information is determined by the service agent. Previously, this also included:

Verify the legality of the target call request through the target service gateway;

When the target service gateway passes the verification of the target call request, the corresponding service agent is called according to the initial call information in the target call request, and the target corresponding to the initial call information is determined by the service agent. Call information.
The service scheduling method according to claim 11, characterized in that the legality verification of the target call request through the service gateway includes:

When the target service gateway is the service gateway of the current electronic device, perform legality verification on the target call request through the target service gateway;

In the case where the target service gateway is the service gateway of an external electronic device, the target call request is sent to the external electronic device, and a processing result returned by the external electronic device is received, where the processing result is the If the external electronic device passes the legality verification of the target call request through the target service gateway, the external electronic device responds to the processing result obtained by the target call request.
The service scheduling method according to any one of claims 1 to 12, characterized in that said running the target service according to the target call information includes:

When the target service is the first service type, run the target service according to the target call information;

When the target service is the second service type, a host service corresponding to the target service is determined, and when the host service is in a running state, the target service is run according to the target call information.
The service scheduling method according to any one of claims 1 to 12, characterized in that the initial call information includes registration call information and/or dynamic call information; the initial call information for determining the target service is determined according to The initial call information determines the target call information, including:

Obtain registration call information of the target service currently stored in the electronic device, and/or obtain dynamic call information generated by other services; wherein the registration call information is used to represent attributes related to the target service, and the dynamic call information Information used to represent the input variables required to run the target service;

Target calling information is determined according to the registered calling information and the dynamic calling information.
The service scheduling method according to any one of claims 1 to 12, wherein the determining the initial call information of the target service includes:

Receive initial call information corresponding to the target service sent by the server;

Running the target service according to the target call information includes:

When the target service is a localized service of the current electronic device, obtain the target service code set stored in the current electronic device, and run the target service code set according to the target call information;

When the target service is a non-localized service of the current electronic device, a target service code set corresponding to the target service sent by the server is obtained, and the target service code set is run according to the target call information.
A service scheduling system, characterized by including:

A scene awareness module, used to determine the current application scenario and determine the service set corresponding to the application scenario;

A service governance module, configured to determine the target service corresponding to the trigger event in the service set when a trigger event is detected in the application scenario; determine the initial call information of the target service, and determine the initial call information of the target service according to the initial The call information determines target call information that matches the electronic device running the target service; and

A service running module is used to run the target service according to the target calling information.
An electronic device, characterized in that the electronic device includes a processor, the processor is used to determine the current application scenario and determine the service set corresponding to the application scenario; detecting a trigger in the application scenario In the case of an event, determine the target service corresponding to the triggering event in the service set; determine the initial call information of the target service, determine the target call information based on the initial call information, and the target call information is consistent with the operation location. The electronic device matches the target service; and runs the target service according to the target call information.
The electronic device according to claim 17, wherein the processor is further configured to obtain interaction information, and determine the current application scenario based on the interaction information.
The electronic device according to claim 18, wherein the interaction information includes location information, orientation information and movement information; the processor is further configured to determine based on the location information that the current electronic device is within a preset location range. In the case of, obtain the target position corresponding to the preset position range; when it is determined that the current electronic device moves toward the target position according to the orientation information and movement information, determine that the current electronic device is currently in the The application scenario corresponding to the target location.
A non-volatile computer-readable storage medium including a computer program. When the computer program is executed by a processor, it causes the processor to execute the service scheduling method described in any one of claims 1-15.