WO2024093700A1

WO2024093700A1 - Service hopping method and device, and storage medium

Info

Publication number: WO2024093700A1
Application number: PCT/CN2023/125948
Authority: WO
Inventors: 漆星剑; 王剑锋; 李轩恺; 董伟鑫; 季翔宇
Original assignee: Oppo广东移动通信有限公司
Priority date: 2022-10-31
Filing date: 2023-10-23
Publication date: 2024-05-10
Also published as: CN117956062A

Abstract

Embodiments of the present application disclose a service hopping method and device, and a storage medium. The service hopping device comprises an operation engine module and a service hopping module. The operation engine module is used for operating a target application program. The service hopping module is used for transmitting memory data of the target application program when in operation and operation data other than the memory data.

Description

Service flow method, device and storage medium

This application claims priority to the Chinese patent application filed on October 31, 2022, with application number 202211365990.X and invention name “Service Flow Method, Device and Storage Medium”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of communication technology, and in particular to a service flow method, device and storage medium.

Background technique

As people's living standards improve, portable devices represented by smartphones are the most commonly used smart devices. People can watch videos, listen to music, browse the web or read e-books on them, which is very convenient.

However, due to battery life or user habits, users often have the need to transfer any service on their smartphones, that is, to continue the last user activity on the smartphone on other electronic devices.

Summary of the invention

Embodiments of the present application provide a service flow method, device, and storage medium.

A first aspect of an embodiment of the present application provides a service flow device, the service flow device comprising a running engine module and a service flow module, wherein:

The runtime engine module is used to run the target application;

The service flow module is used to transmit the memory data of the target application when it is in a running state and other running data except the memory data.

A second aspect of an embodiment of the present application provides a service transfer method, which is applicable to a first device and includes:

Obtain memory data and other running data when the target application is in running state;

The memory data and other running data are sent to the second device, so that the second device runs the target application according to the memory data and other running data.

A third aspect of an embodiment of the present application provides a service flow device, including a processor, wherein:

The processor is used to run the target application; and is used to transmit the memory data of the target application when it is in the running state and other running data except the memory data.

A fourth aspect of an embodiment of the present application provides a computer-readable storage medium having executable program code stored thereon. When the executable program code is executed by a processor, the method described in the second aspect of the embodiment of the present application is implemented.

A fifth aspect of an embodiment of the present application discloses a computer program product. When the computer program product runs on a computer, the computer executes the method described in the second aspect of the embodiment of the present application.

A sixth aspect of an embodiment of the present application discloses an application publishing platform, which is used to publish a computer program product. When the computer program product runs on a computer, the computer executes the method described in the second aspect of the embodiment of the present application.

Details of one or more embodiments of the present application are presented in the following drawings and descriptions. Other features and benefits of the present application will be reflected in the specification, drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments and the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can be obtained based on these drawings.

FIG1A is a scene diagram disclosed in an embodiment of the present application;

FIG1B is a diagram of a service flow disclosed in an embodiment of the present application;

FIG1C is another service flow diagram disclosed in an embodiment of the present application;

FIG1D is a structural diagram of a flow module disclosed in an embodiment of the present application;

FIG. 1E is another service flow diagram disclosed in an embodiment of the present application;

FIG2A is a structural diagram of a service flow device disclosed in an embodiment of the present application;

FIG2B is another structural diagram of the service transfer device disclosed in an embodiment of the present application;

FIG2C is another structural diagram of the service transfer device disclosed in the embodiment of the present application;

FIG2D is another structural diagram of the service transfer device disclosed in the embodiment of the present application;

FIG2E is another structural diagram of the service transfer device disclosed in the embodiment of the present application;

FIG2F is another structural diagram of the service transfer device disclosed in the embodiment of the present application;

FIG3 is a flowchart of a service transfer method disclosed in an embodiment of the application;

FIG4 is another flowchart of the service transfer method disclosed in the application embodiment;

FIG. 5 is another schematic diagram of the structure of the service flow device disclosed in the embodiment of the present application.

Detailed ways

The embodiments of the present application provide a service flow method, device and storage medium, which are conducive to improving the comprehensiveness of service flow.

In order to make the technical personnel in the technical field better understand the scheme of the present application, the technical scheme in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, not all of the embodiments. Based on the embodiments in the present application, they should all fall within the scope of protection of the present application.

In order to facilitate those skilled in the art to clearly understand the process of service transfer, the service transfer scenario is described below in conjunction with FIG. 1A, as shown in FIG. 1A, including a first device 10 and a second device 20. The target application is first run on the first device 10, and after running for a certain period of time, based on the power of the first device 10 or other reasons such as user needs, the user wants to transfer the service flow of the target application to the second device 20, so that the second device 20 can continue the user activity of the target application on the first device.

The following are flowcharts illustrating several service flow methods in the prior art.

Example 1: Please refer to Figure 1B. The sending end sends the memory data of the application when it is in the running state to the service process of the sending end through the application, and then the service process of the sending end sends it to the service process of the receiving end. When the application is started at the receiving end, the service process of the receiving end passes the memory data to the application for application parsing and use.

Example 2: Please refer to Figure 1C. The sending end writes activity data describing the user activity status into the memory space through the application, and updates and marks the user activity data written into the memory space through the application. The sending end reads the activity data from the memory space through the operating system, and sends the activity data to the operating system of the receiving end. The operating system of the receiving end invokes the application when receiving the activity data, and passes the activity data to the application for analysis and use by the application.

Example 3: Service flow relies on the flow module to be implemented, and the flow module runs on the sending end and the receiving end. The flow module includes a flow task management service unit and a distributed task scheduling unit (see Figure 1D). See Figure 1E for the specific flow process. At the sending end, the application registers a flow callback on the flow task management service unit. The flow task management service unit determines the receiving end recommended by the system and feeds back the device information of the receiving end to the application. When the application receives the device information, it sends the memory data of the application when it is in the running state to the distributed task scheduling unit, and the distributed task scheduling unit sends the memory data to the receiving end. When the distributed task scheduling unit at the receiving end receives the memory data, it passes the memory data to the application for application parsing and use.

It can be seen that in the prior art, the core of most service flow methods lies in the small-scale memory data when the target application is in running state, that is, the first device transfers the small-scale memory data to the second device, so that the second device can mostly only continue part of the user activities, and the comprehensiveness of the service flow is not enough.

To solve this problem, the present application discloses a service flow device, which can not only The memory data of the target application when it is in operation can be transferred, and other operation data besides the memory data can also be transferred, which is conducive to improving the comprehensiveness of service flow.

It should be noted that the service flow device disclosed in the embodiment of the present application can run on the first device and the second device respectively.

The following is an introduction to the service transfer device disclosed in the embodiment of the present application from the hardware level in conjunction with the following diagram:

Please refer to Figure 2A, which is a structural diagram of a service flow device disclosed in an embodiment of the present application. The service flow device shown in Figure 2A may include a processor 210, a memory 220, a display unit 230, an input unit 240, a sensor 250, an audio circuit 260 and other components.

The processor 210 is the control center of the service flow device, and uses various interfaces and lines to connect various parts of the entire service flow device. By running or executing software programs and/or modules stored in the memory 220, and calling data stored in the memory 220, the processor 210 performs various functions of the service flow device and processes data, thereby monitoring the service flow device as a whole. Optionally, the processor 210 may include one or more processing units; optionally, the processor 210 may integrate an application processor, which mainly processes operating devices, user interfaces, and application programs, etc. Of course, other processors may also be included, which are not listed here one by one.

The memory 220 can be used to store software programs and modules. The processor 210 executes various functional applications and data processing of the service flow device by running the software programs and modules stored in the memory 220. The memory 220 can mainly include a program storage area and a data storage area, wherein the program storage area can store operating devices, at least one application required for a function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the service flow device (such as audio data, a phone book, etc.), etc. In addition, the memory 220 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

The display unit 230 can be used to display information input by the user or information provided to the user and various menus of the service flow device. The display unit 230 may include a display panel. Optionally, the display panel may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch panel may cover the display panel. When the touch panel detects a touch operation on or near it, it is transmitted to the processor 210 to determine the type of touch event, and then the processor 210 provides corresponding visual output on the display panel according to the type of touch event. Among them, the touch panel and the display panel are not shown in Figure 2A. The touch panel and the display panel can be used as two independent components to realize the input and output functions of the service flow device, or the touch panel and the display panel can be integrated to realize the input and output functions of the service flow device.

The input unit 240 can be used to receive input digital or character information, and to generate key signal input related to user settings and function control of the service flow device. Specifically, the input unit 240 may include a touch panel and other input devices. A touch panel, also known as a touch screen, can collect user touch operations on or near it (such as operations performed by a user using a finger, stylus, or any other suitable object or accessory on or near the touch panel), and drive the corresponding connection device according to a pre-set program. In addition, a variety of types such as resistive, capacitive, infrared, and surface acoustic waves can be used to implement the touch panel. In addition to the touch panel, the input unit 240 may also include other input devices. Specifically, other input devices may include, but are not limited to, one or more of function keys (such as volume control keys, switch keys, etc.), trackballs, joysticks, and the like.

The service flow device may also include at least one sensor 250, such as a gyroscope sensor, a motion sensor, and other sensors. Specifically, the gyroscope sensor can be used to determine the motion posture of the service flow device, can be used for anti-shake shooting, and can also be used for navigation and somatosensory game scenes. As a type of motion sensor, the acceleration sensor can detect the magnitude of acceleration in all directions, and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of electronic devices, such as horizontal and vertical screen switching, related games, magnetometer posture calibration, etc.; as for other sensors that electronic devices can also be configured with, such as pressure gauges, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

The audio circuit 260 may include a speaker 261 and a microphone 262, and may provide an audio interface between the user and the service flow device. The audio circuit 260 may transmit the electrical signal converted from the received audio data to the speaker 261, which is converted into a sound signal for output; on the other hand, the microphone 262 converts the collected sound signal into an electrical signal, which is received by the audio circuit 260 and converted into audio data, and then the audio data is output to the processor 210 for processing, and then sent to another electronic device through the video circuit, or the audio data is output to the memory 220 for further processing.

Although not shown, the service flow device may further include a power supply and a camera. Optionally, the camera may be located in the front or rear position on the service flow device, which is not limited in the embodiment of the present application.

The service flow device provided in the embodiments of the present application can be a mobile phone, a tablet computer, a laptop computer, a PDA, a mobile internet device (MID), a wearable device, a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a personal digital assistant (PDA), etc., but the embodiments of the present application are not limited to this.

In addition, the service flow device provided in the embodiment of the present application can communicate with other devices that establish short-range communication connections with it through a short-range transmission module, and can also communicate with other network devices through a communication network. The network device can be a cloud server, and the communication network can be a 5G network, or a long-term evolution (LTE) network. Of course, it can also be a future-oriented communication network, which is not limited here.

It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the service flow device. In other embodiments of the present application, the service flow device may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

FIG2A illustrates the service flow device in the embodiment of the present application from the perspective of hardware structure. The service flow device is described below from the perspective of software level. The operating system of an electronic device is generally divided into four layers, namely, the application layer, the application framework layer, the system runtime layer, and the core layer; wherein the application layer includes various application programs. The application framework layer (Java Frameworks) includes the application programming interface (API) framework used by the core application; the system runtime layer includes the core library, virtual machine runtime environment, and hardware abstraction (HAL) layer required by the system platform; the core layer (Linux Kernel) includes core system services, such as file management, memory management, process management, network stack, driver model, and other basic service capabilities of the operating system. Among them, the service flow device can run in the application framework layer, in the system runtime layer, or across the application framework layer and the system runtime layer, which is not limited in the embodiment of the present application.

The service flow device disclosed in the embodiment of the present application is described in detail below in conjunction with the accompanying drawings.

Please refer to FIG. 2B, which is another structural diagram of the service flow device disclosed in the embodiment of the present application. The service flow device shown in FIG. 2B may include a running engine module 100 and a service flow module 200; wherein:

The running engine module 100 is used to run the target application program;

The service transfer module 200 is used to transmit the memory data of the target application when it is in the running state and other running data except the memory data.

In some embodiments, memory data may include temporary status data and behavior data. Temporary status data is data that disappears after the application exits and is used to indicate the running status; behavior data is used to indicate the activities being performed by the target application. Exemplarily, temporary status data may include: the content of a text message being edited and not yet sent, the Uniform Resource Locator (URL) and playback location of the video being played, the name of the document being edited and the editing location, the input, output and intermediate results of the ongoing calculation, and the video information swiped when swiping the video, etc. Behavior data refers to the activities and calculations being performed by the application.

In some embodiments, other operation data may include application deployment data and non-application deployment data, wherein the application deployment data includes the installation package of the target application and/or the installation packages of other applications that have a collaborative relationship with the target application.

Further, the service flow device shown in FIG2B is optimized to obtain FIG2C. In the service flow device shown in FIG2C, the service flow module 200 may include a running state management unit 210 and a static management unit 220, wherein:

The running state management unit 210 is used to transmit the memory data and non-application deployment data of the target application when it is in the running state;

The static management unit 220 is used to transmit application deployment data corresponding to the target application.

In some embodiments, the non-application deployment data includes permission data, and the permission data is used to indicate the authorization status of the target application. The authorization status may include the functional authorization status and data authorization status of the target application. Exemplarily, the functional authorization status may include whether the target application can access the SD card, whether it can access the camera, whether it can obtain location information, etc. The data authorization status may refer to the login account required by the target application, etc.

Further, please refer to FIG. 2D . In the service transfer device shown in FIG. 2D , the running state management unit 210 may include a data migration unit 211 and a permission management unit 212 , wherein:

The data migration unit 211 is used to transfer the memory data of the target application when it is in the running state;

The permission management unit 212 is used to transmit permission data of the target application when it is in the running state.

In some embodiments, the non-application deployment data also includes persistent state data, which is data that will not be cleared after the application exits and is used to indicate the running state. Further, referring to FIG. 2E , in the service flow device shown in FIG. 2E , the running state management unit 210 may also include a distributed management unit 213, wherein:

The distributed management unit 213 is used to transmit the persistent state data of the target application when it is in the running state.

In some embodiments, the non-application deployment data also includes application collaboration data, and the application collaboration data includes the program identifier of the target application and the program identifiers of other applications that have a collaborative relationship with the target application. Further, referring to FIG. 2F , in the service flow device shown in FIG. 2F , the running state management unit 210 may also include a flow decision unit 214; wherein:

The flow decision unit 214 is used to transmit the application collaboration data corresponding to the target application program.

The following takes the service transfer device shown in FIG2F running on the first device as an example, and introduces the service transfer method performed by the first device in combination with the structure of the service transfer device shown in FIG2F. Please refer to FIG3, which is a flowchart of the service transfer method disclosed in the embodiment of the application. The service transfer method shown in FIG3 may include the following steps:

301. The first device writes memory data corresponding to the target application into the memory space and writes persistent state data into the distributed storage unit during the process of running the target application by running the engine module.

302. The first device reads memory data from the memory space through a data migration unit, and sends the memory data to the second device.

In some embodiments, the first device sends the memory data to the second device through the data migration unit, which may include: the first device generates a data object for the memory data through the data migration unit, serializes the data object, and sends the serialized data object to the second device.

In some embodiments, the first device encodes internal data through a data migration unit and sends the encoded memory data to the second device.

It should be noted that the serialized data objects and the encoded memory data are both binary byte streams.

In some embodiments, the first device sends the serialized data object or encoded memory data to the second device through the data migration unit, which may include: the first device sends the serialized data object or encoded memory data to the second device through the data migration unit using the short-range communication module of the first device.

The short-range communication module may include but is not limited to any one of the following: a near field communication module (NFC), a Bluetooth module, and an ultra wideband (UWB) communication module.

It is understandable that the first device and the second device can establish a short-range communication link through their respective short-range communication modules, and the first device sends the data object or the encoded memory data to the second device through the short-range communication link.

303. The first device reads the persistent state data from the distributed storage unit through the distributed management unit, and sends the persistent state data to the second device.

In some embodiments, the distributed storage unit may include a distributed database and/or a distributed file.

The distributed storage unit includes a distributed database and a distributed file, and the persistent state data may be database data and/or file data. The first device reads the persistent state data from the distributed storage unit through the distributed management unit, which may include: the first device reads the database data from the distributed database of the first device through the distributed management unit, and reads the file data from the distributed file of the first device.

Furthermore, the first device sends the persistent state data to the cloud server through the distributed management unit, which may include: the first device sends the database data and the file data to the second device through the distributed management unit.

In some embodiments, the first device sending database data to the second device through the distributed management unit may include: the first device sending the database data to the cloud server through the distributed management unit, so that the cloud server receives the first data request reported by the second device for obtaining the database data, and sends the database data to the second device.

In some embodiments, the first device sending file data to the second device through the distributed management unit may include: the first device sending the file data to the second device through the distributed management unit using a designated communication link; wherein the designated communication link is a direct communication channel established between the first device and the second device according to the communication protocols built into their respective distributed file systems.

304. The first device obtains permission data of the target application when it is in a running state from the secure storage space of the first device through the permission management unit, and sends the permission data to the second device.

In some embodiments, the first device sends the permission data to the second device through the permission management unit, which may include but is not limited to the following methods:

Mode 1: The first device serializes the permission data through the permission management unit, and sends the serialized permission data to the second device using the short-distance communication module of the first device;

Mode 2: The first device sends the permission data to the cloud server through the permission management unit, so that the cloud server stores the permission data and sends the permission data to the second device in response to the second data request for permission data sent by the second device.

Mode 3: The first device sends the permission data to the data migration unit through the permission management unit, and sends the permission data to the second device through the data migration unit.

Among them, the manner in which the data migration unit sends the permission data to the second device can refer to the manner in which the data migration unit sends the memory data to the second device, which will not be described in detail here.

305. The first device determines the program identifiers of other applications that have a collaborative relationship with the target application through the flow decision unit, and obtains application collaborative data corresponding to the target application based on the program identifier of the target application and the program identifiers of the other applications; and sends the application collaborative data to the second device.

The program identifier is used to uniquely identify the application program. The program identifier may include, but is not limited to, at least one of the following: numbers, letters, and special characters.

In some embodiments, other applications that have a collaborative relationship with the target application may refer to other applications that are currently working in collaboration with the target application, other applications that have worked in collaboration with the target application during the operation of the target application, or other applications that are likely to work in collaboration with the target application in the future.

In some embodiments, the way in which the first device sends the application collaboration data to the second device through the flow decision unit can refer to the way in which the data migration unit sends memory data, which will not be repeated here.

In some embodiments, the first device may also respond to the application data sent by the second device through the static management unit. A deployment request is sent to the second device, and application deployment data corresponding to the target application is sent.

The application data deployment request may carry the target program identifier of the application program to be deployed by the second device. The first device responds to the application data deployment request sent by the second device through the static management unit, and sends the application deployment data corresponding to the target application program to the second device, which may include: the first device receives the application data deployment request sent by the second device through the static management unit, and parses the target program identifier from the data deployment request, and uses the installation package of the application program corresponding to the target program identifier as the application deployment data corresponding to the target application program, and sends the application deployment data to the second device.

In some embodiments, the first device sending the application deployment data to the second device through the static management unit may include: the first device sending the application deployment data to the second device through the static management unit using the short-range communication module of the first device.

In some embodiments, after the first device obtains the application collaboration data corresponding to the target application through the flow decision unit, it can also send the application collaboration data to the static management unit through the flow decision unit, and back up the target application and the installation packages of other applications that have a collaborative relationship with the target application based on the application collaboration data through the static management unit.

Among them, various types of data (including memory data, permission data and persistent status data) sent by the first device through various units (data migration unit, permission management unit, distributed management unit) can be unmerged data or merged data, which is not limited in the embodiments of the present application.

The following is an example of a first device sending memory data to a second device through a data migration unit. If the memory data has not been merged, the first device sends to the second device through the data migration unit all the data written to the memory space for a specified time. If the memory data has been merged, the first device sends to the second device through the data migration unit the merged data after the merge operation is performed on all the data written to the memory space for a specified time. The specified time may refer to the synchronization period of the memory data.

In some embodiments, the data migration unit may perform a merge operation on all data written to the memory space within a specified time period. The data migration unit may obtain the data block corresponding to each data block identifier from all data written to the memory space within a specified time period, and perform a merge operation on the data block corresponding to each data block identifier according to a specified merge algorithm to obtain a target data block corresponding to each data block identifier, and combine the target data blocks corresponding to each data block identifier to obtain the above-mentioned memory data.

The data block identifier is used to uniquely identify a data block, and the data block identifier may include at least one of the following: numbers, letters, and special characters.

In some embodiments, the specified merging algorithm may be a data overwriting algorithm based on write time, a recursive multi-way merging algorithm, or a user-preset merging rule, etc., which is not limited in the embodiments of the present application.

The data overwriting algorithm based on writing time refers to overwriting the old version with the new version. The recursive multi-way merging algorithm refers to taking the most original data block as the benchmark, comparing it with other changed data blocks, obtaining the change data corresponding to each changed data block, combining the change data corresponding to each changed data block, and obtaining the content of the merged data block.

The following example illustrates the data overwriting algorithm based on write time and the recursive multi-way merging algorithm:

Assume that the earliest version of a data block is a (such as a text "Rats are harmful"), and the data block is modified twice based on a, resulting in two different versions b (such as "Rats are useful") and c ("Mice are harmful").

Data overwriting algorithm based on write time: Assuming that b is generated first and c is generated later, the content of the merged data block is the content of c.

Recursive multi-way merging algorithm: take a as the benchmark, use b and c to compare with a respectively, the changed part of b relative to a is "useful" and the changed part of c relative to a is "a little white mouse", combine the changed parts of b and c to get the merged data block ("the little white mouse is useful").

By implementing this method, when each unit of the first device sends corresponding data to the second device, if the merging operation is performed first, the amount of transmitted data can be reduced, which is beneficial to reducing the device power consumption of the first device.

In addition, it should be noted that in the above steps 301 to 305, the specific logical order shall be based on the specific contents of the steps and shall not be limited to the order shown in the diagram.

The following takes the service transfer device shown in FIG2F running on the second device as an example, and combines the structure of the service transfer device shown in FIG2F and the service transfer method shown in FIG3 to introduce the service transfer method performed by the second device. Please refer to FIG4, which is another flow chart of the service transfer method disclosed in the embodiment of the application. The service transfer method shown in FIG4 may include the following steps:

401. A second device receives memory data through a data migration unit.

Corresponding to the content in the above step 302, the second device receives the memory data through the data migration unit, and sends the memory data to the execution engine module in the following ways, including but not limited to:

The second device receives the serialized data object through the data migration unit, performs a deserialization operation on the serialized data object to obtain the data object, and parses the data object to obtain memory data.

The second device receives the encoded memory data through the data migration unit, and performs a decoding operation on the encoded memory data to obtain the memory data.

Correspondingly, the second device receives the serialized data object or the encoded memory data through the data migration unit, which may include: the second device receives the serialized data object or the encoded memory data through the data migration unit using the short-range communication module of the second device.

402. The second device receives persistent state data through a distributed management unit.

Corresponding to the content in the above step 303, the second device receiving the persistent state data through the distributed management unit may include:

The second device sends a first data request for acquiring database data to the cloud server through the distributed management unit, and receives the database data sent by the cloud server in response to the first data request.

The second device receives the file data sent by the second device through the designated communication link through the distributed management unit.

403. The second device receives permission data through the permission management unit.

Corresponding to the above step 204, the second device receives the permission data through the permission management unit, which may include but is not limited to the following methods:

Mode 1: The second device receives serialized permission data through the permission management unit, and performs a deserialization operation on the serialized permission data to obtain the permission data.

Mode 2: The second device sends a second data request for requesting permission data to the cloud server through the permission management unit, and receives the permission data sent by the cloud server in response to the second data request.

Mode 3: The second device receives the permission data sent by the first device through the data migration unit, and sends the permission data to the permission management unit.

404. The second device receives the application collaboration data through the flow decision unit, and sends the application collaboration data to the static management unit.

405. The second device generates a deployment data acquisition request according to the application collaboration data through the static management unit, sends the deployment data acquisition request to the application market of the first device and/or the second device, and receives the application deployment data sent by the application market of the first device and/or the second device in response to the deployment data acquisition request.

In some embodiments, the second device may also deploy a corresponding application program according to the application deployment data through a static management unit.

In some embodiments, the second device generates a deployment data acquisition request according to the application collaboration data through the static management unit, and sends the deployment data acquisition request to the application market of the first device and/or the second device, and receives the application deployment data sent by the application market of the first device and/or the second device in response to the deployment data acquisition request, which may include: The second device determines through the static management unit whether the applications indicated by the application collaboration data have all been deployed on the second device. If there is an undeployed first application, a deployment data acquisition request is generated according to the program identifier of the first application, and the deployment data acquisition request is sent to the application market of the first device or the second device, and the application deployment data sent by the application market of the first device or the second device is received.

In some embodiments, if there is an undeployed first application, the second device can also identify through the static management unit whether the first application can be run on the second device. If so, a deployment data acquisition request is generated according to the program identifier of the first application, and the deployment data acquisition request is sent to the application market of the first device or the second device, and the application deployment data sent by the application market of the first device or the second device is received.

Furthermore, if there is a first application that cannot run on the second device, the second device determines through the static management unit whether an alternative application for the first application that cannot run on the second device has been deployed on the second device; if the alternative application has been deployed, a deployment data acquisition request is generated based on the program identifier of the first application that can run on the second device, and the deployment data acquisition request is sent to the application market of the first device or the second device, and the application deployment data sent by the application market of the first device or the second device is received.

If the alternative application is not deployed, the second device can generate a deployment data acquisition request through a static management unit based on the program identifier of the alternative application and the program identifier of the first application that can run on the second device, and send the deployment data acquisition request to the application market of the second device, and receive the application deployment data sent by the application market of the second device.

or,

If the alternative application is not deployed, the second device can generate a first deployment data acquisition request based on the program identifier of the alternative application through the static management unit, send the first deployment data acquisition request to the application market of the second device, and receive the first application deployment data sent by the application market of the second device in response to the first deployment data acquisition request; and generate a second deployment data acquisition request based on the program identifier of the first application that can be run on the second device, send the second deployment data acquisition request to the first device, and receive the second application deployment data sent by the first device in response to the second deployment data acquisition request.

In some embodiments, the second device receives the application deployment data sent by the first device through the static management unit using the short-range communication module of the second device.

By implementing the above method, the second device can use the short-range communication module of the second device through the static management unit to receive the second application deployment data sent by the first device in response to the second deployment data acquisition request, which can effectively reduce the situation where the second device occupies network resources.

In some embodiments, each unit (data migration unit, permission management unit and distributed management unit) on the second device receives corresponding data periodically, and each unit can periodically perform a merge operation after receiving the corresponding data, so that when the running engine module obtains corresponding data from each unit, the corresponding data obtained are merged. By implementing this method, the data storage pressure of the second device can be effectively reduced.

406. When the deployment of the corresponding application is completed and the memory data, permission data and persistent status data are received, the second device starts the target application by running the engine module, and obtains the memory data, permission data and persistent status data from the data migration unit, the permission management unit and the distributed management unit respectively, and runs the target application according to the memory data, permission data and persistent status data.

Among them, after starting the target application, the running engine module can send data requests to the data migration unit, the permission management unit and the distributed management unit respectively to obtain memory data, permission data and persistent status data from the data migration unit, the permission management unit and the distributed management unit respectively.

In some embodiments, if each unit (data migration unit, permission management unit and distributed management unit) on the second device does not perform a periodic merge operation on the corresponding data, then each unit, when receiving a data request sent by the runtime engine module, can respond to the data request, perform a merge operation on the corresponding data received by each unit, and The merged corresponding data is sent to the runtime engine module, and the runtime engine module can run the target application according to the merged memory data, permission data and persistent state data.

It should be noted that, for the specific content of executing the merge operation, please refer to the above description of the merge operation, which will not be repeated here.

In addition, it should be noted that in the above steps 401 to 406, the specific logical order shall be based on the specific contents of the steps and shall not be limited to the order shown in the diagram.

Please refer to FIG5, which is another structural diagram of the service flow device disclosed in the embodiment of the present application. As shown in FIG5, the service flow device 500 includes: a processor 501 and a memory 502, a communication interface 503 and a bus 504. Among them, the memory 502 is used to store instructions, and the processor 501 is used to execute the instructions stored in the memory 502. The processor 501, the memory 502 and the communication interface 503 are connected to each other through the bus 504.

The processor 501 is used to: run the target application; and to transmit the memory data of the target application when it is in the running state and other running data other than the memory data. It should be understood that the service flow device 500 can be specifically the service flow device shown in Figure 2A, Figure 2B or Figure 2C to execute the method in any of the embodiments in Figures 3-4 above.

Optionally, the memory 502 may include a read-only memory and a random access memory, and provide instructions and data to the processor 501. A portion of the memory 502 may also include a non-volatile random access memory. For example, the memory 502 may also store information about the device type. The processor 501 may be used to execute the instructions stored in the memory, and when the processor executes the instructions, the processor 501 may execute the various steps and/or processes corresponding to the service flow device in the above method embodiment.

It should be understood that in the embodiments of the present application, the processor may be a central processing unit, or other general-purpose processors, digital signal processors, application-specific integrated circuits, field programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

The embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes any method in any of the above embodiments.

The above-mentioned computer-readable storage medium may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device.

Computer-readable signal media may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

The program code embodied on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.

Computer program code for performing the operations of this specification may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is enabled to execute part or all of the steps in the above method embodiment.

Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

A service flow device, characterized in that the service flow device comprises a running engine module and a service flow module, wherein:

The runtime engine module is used to run the target application;

The service flow module is used to transmit the memory data of the target application when it is in a running state and other running data except the memory data.
The service flow device according to claim 1 is characterized in that the other operation data includes application deployment data and non-application deployment data, the application deployment data includes the installation package of the target application and/or the installation packages of other applications that have a collaborative relationship with the target application; the service flow module includes a running state management unit and a static management unit, wherein:

The running state management unit is used to transmit the memory data of the target application when it is in the running state and the non-application deployment data;

The static management unit is used to transmit the application deployment data corresponding to the target application.
The service flow device according to claim 2 is characterized in that the non-application deployment data includes permission data, and the permission data is used to indicate the authorization status of the target application; the running state management unit includes a data migration unit and a permission management unit, wherein:

The data migration unit is used to transfer the memory data of the target application when it is in a running state;

The permission management unit is used to transmit the permission data of the target application when it is in a running state.
The service flow device according to claim 3, characterized in that the running engine module is specifically used for:

During the running of the target application, writing the memory data corresponding to the target application into the memory space;

The data migration unit is specifically used for:

The memory data is read from the memory space, and the memory data is sent.
The service flow device according to claim 3 or 4, characterized in that the data migration unit is specifically used to:

Generate a data object of memory data of the target application when it is in a running state;

Serializing the data object;

Send the serialized data object.
The service flow device according to claim 3 is characterized in that the permission management unit is specifically used to:

The permission data of the target application when it is in a running state is read from the secure storage space, and the permission data is sent.
The service flow device according to claim 3 is characterized in that the non-application deployment data also includes persistent state data, and the persistent state data is data that will not be cleared after the application program exits operation and is used to indicate the operation state; the operation state management unit also includes a distributed management unit, wherein:

The distributed management unit is used to transmit the persistent state data of the target application when it is in a running state.
The service flow device according to claim 7, characterized in that the running engine module is specifically used for:

During the running of the target application, writing the persistent state data into a distributed storage unit;

The distributed management unit is specifically used for:

The persistent state data is read from the distributed storage unit, and the persistent state data is sent.
The service flow device according to claim 8 is characterized in that the persistent state data includes database data and file data, the distributed storage unit includes a distributed database and a distributed file; and the distributed management unit is specifically used to:

Reading database data from the distributed database;

File data is read from the distributed file.
The service flow device according to claim 3 is characterized in that the non-application deployment data also includes application collaboration data, the application collaboration data includes the program identifier of the target application and the program identifiers of other applications that have a collaborative relationship with the target application; the running state management unit also includes a flow decision unit; wherein:

The flow decision unit is used to transmit the application collaboration data corresponding to the target application.
The service flow device according to claim 10, characterized in that the flow decision unit is specifically used to:

Determining program identifiers of other applications that have a collaborative relationship with the target application;

Obtaining application collaboration data corresponding to the target application according to the program identifier of the target application and the program identifiers of the other applications;

The application collaboration data is sent.
The service flow device according to claim 11, characterized in that the static management unit is specifically used to:

In response to the deployment data acquisition request, the application deployment data corresponding to the target application is sent.
The service flow device according to claim 10, characterized in that the flow decision unit is specifically used to:

Receiving the application collaboration data when the target application is in a running state;

Sending the application collaboration data to the static management unit;

The static management unit is specifically used for:

A deployment data acquisition request is generated according to the application collaboration data, and the deployment data acquisition request is sent to obtain the application deployment data.
The service flow device according to any one of claims 1-13 is characterized in that the memory data includes temporary status data and behavior data, the temporary status data is data that disappears after the application program exits and is used to indicate the running status; the behavior data is used to indicate the ongoing activities of the target application.
A service transfer method, characterized in that the method is applicable to a first device and includes:

Obtain memory data and other running data when the target application is in running state;

The memory data and other running data are sent to the second device, so that the second device runs the target application according to the memory data and other running data.
The method according to claim 15 is characterized in that the other operating data includes persistent state data, permission data and application deployment data.
The method according to claim 16, wherein sending the application deployment data to the second device comprises:

In response to the deployment data acquisition request sent by the second device, application deployment data is sent to the second device.
The method according to claim 17, characterized in that the method further comprises:

Determining program identifiers of other applications that have a collaborative relationship with the target application;

Obtaining application collaboration data corresponding to the target application according to the program identifier of the target application and the program identifiers of the other applications;

The application collaboration data is sent to the second device, so that the second device generates a deployment data acquisition request according to the application collaboration data, and sends the deployment data acquisition request to the first device.
A service flow device, characterized in that it includes a processor, wherein:

The processor is used to run the target application; and is used to transmit the memory data of the target application when it is in the running state and other running data except the memory data.
A computer-readable storage medium having executable program code stored thereon, characterized in that when the executable program code is executed by a processor, the method according to any one of claims 13 to 16 is implemented.
A computer program product, comprising a computer program code, wherein when the computer program code is run on a computer, the computer implements any one of claims 13 to 16 The method described in item.