Real-time synchronous refreshing system and method for multi-process data of mobile terminal

Abstract

The invention discloses a mobile terminal multi-process data real-time synchronous refreshing system and method, the system comprises a master process and a slave process, and real-time communication between processes is realized through a shared database, IPC-notify, IPC-launch and the like; wherein the host process performs write-in or update operation on the shared database according to modules, and sends broadcast messages according to the modules by using the IPC-notify at the same time; the subordinate process registers and monitors a broadcast message by taking the module as a unit, and reads data corresponding to the module and refreshes a module window when receiving a message that the required module is updated; and when the slave process fails to obtain the data of the required module through the broadcast message, the master process is directly pulled up through the IPC-launch, and the data of the corresponding module is actively obtained. The system can stably and reliably transmit a large amount of data among a plurality of processes, ensures high efficiency, real-time performance and safety of communication, and supports various platforms.

Description

Technical Field

[0001] The present invention relates to the technical field of mobile communications, and particularly to a multi-process data real-time synchronization and refresh system and method for a mobile terminal. Background Art

[0002] With the increasing popularity of mobile operating systems (including iOS / iPad OS and Android), the ease of use, real-time performance, and security of inter-process communication in mobile applications have received more and more attention. Inter-process communication in mobile applications is also a matter that has been criticized by many developers. In particular, applications on iOS / iPad OS and Android systems are sandboxed, which means that each application cannot directly access the data or system resources of other applications. However, communication between them usually needs to be carried out through explicit system interfaces, and inter-process communication between applications can only rely on system mechanisms such as URL Scheme, Keychain in the iOS system, and ContentProvider, Broadcasts (broadcasts) in the Android system. However, these mechanisms have their limitations in use.

[0003] Currently, inter-process communication technologies for mobile terminals are all based on the system mechanisms themselves, and relatively speaking, their usage scenarios have limitations, but they cannot well meet the scenario of real-time sharing of data and refreshing the interface between multiple processes. For example, URL Scheme mainly jumps between processes through links and transmits data through link parameters. This method requires opening and jumping to another communication process and is generally used for one-to-one real-time communication; ContentProvider provides a way of data sharing, but it cannot achieve real-time performance.

[0004] In the face of enterprise mobile security office scenarios, there are often multiple processes that need to share data in real time, such as user authentication information, configuration or policy information, etc. In the face of the scenario of real-time sharing of data and refreshing windows between multiple processes, there is currently no complete solution. Summary of the Invention

[0005] The present disclosure provides a cross-platform technical solution that combines system message mechanisms, launching mechanisms, and shared storage, etc., which can stably and reliably transfer a large amount of data between multiple processes, and ensure the efficiency, real-time performance, and security of communication, realizing real-time sharing of data and refreshing windows between multiple processes in a mobile operating system.

[0006] The multi-process data real-time synchronization and refresh solution for a mobile operating system provided by the present disclosure mainly includes the following key points:

[0007] (1) Divide the communication processes into two categories, including: a main process and multiple subordinate processes belonging to it; the main process has read / write permissions for the shared database, and the subordinate processes only have read permissions for the shared database;

[0008] (2) To solve the functional coupling in inter-process communication, decouple different categories of data by module, identify the modules by module-id, and share data between the main and subordinate processes through the shared database by module-id: all inter-process communication methods are based on module-id as the key; create tables in the shared database with module-id as the key;

[0009] The main process performs write or update operations on the shared database by module according to different services; the subordinate processes also read data from the shared database by module;

[0010] (3) Real-time message communication is carried out between the main and subordinate processes through message listening and broadcasting:

[0011] The subordinate processes register and listen to messages in units of modules as needed, and a process can listen to one or more modules; after the main process performs write or update operations on the shared database by module, it sends broadcast messages by module; when the subordinate processes receive the broadcast messages sent by the main process, they read the data corresponding to the modules and refresh the module windows;

[0012] (4) There is also an IPC-launch mechanism for mutual real-time startup between the main and subordinate processes, which is used for the main process and the subordinate processes to directly perform real-time startup jumps and transfer parameters:

[0013] When the subordinate processes do not read the shared data of the relevant modules, they use IPC-launch to start the main process, and transfer the module-id to be read and the launch-id of their own processes through the startup parameters; when the main process is started, it obtains the module-id and the launch-id of the subordinate processes through the startup parameters, the main process writes or updates the data of the corresponding modules in the shared database, and reversely starts the subordinate processes through IPC-launch; after the subordinate processes are reversely started, they read the shared data again according to the module-id and refresh the windows of the corresponding modules;

[0014] (5) Provide it to the docking processes in the form of SDK integration, abstract the external interfaces and use cross-platform C++ language and other means to support cross-platform generality.

[0015] Based on the above solution, a mobile multi-process data real-time synchronization and refresh system is constructed, mainly including:

[0016] Shared database: A database built on a shared storage directory for storing shared data between processes; the shared data is classified into different modules by category;

[0017] The main process, corresponding one-to-one with the shared database, is used to write to or update the shared database by module and notify the subordinate processes by module;

[0018] The subordinate process has only read permission for the shared database and is used to read the data of the corresponding module from the shared database and refresh the window after learning that the required data module has been updated;

[0019] The IPC-notify unit is used to send broadcast messages to the subordinate processes by module when the main process writes to or updates a module in the shared database; the subordinate processes obtain the message that the concerned module has been updated by registering and listening to the broadcast messages in units of modules;

[0020] The IPC-launch unit is used for direct real-time pulling and jumping between the main and subordinate processes and passing parameters, including: the subordinate process pulls up the main process through IPC-launch and passes the module id it needs to read and its own process's launch-id through the pull-up parameters; after the main process writes or updates the data of the corresponding module in the shared database, it pulls up the subordinate process in reverse through IPC-launch to notify it to update the data.

[0021] Furthermore, the shared data in the system classifies different types of data by module, identifies the modules by module-id, creates tables in the shared database with module-id as the key, and all inter-process communication methods are also based on module-id as the key, including: the IPC-notify unit registers and listens to broadcast messages and sends broadcast messages with module-id as the key; the IPC-launch unit also carries module-id information when pulling up the other process for corresponding module data update operations.

[0022] Furthermore, a main process is allowed to have multiple subordinate processes; a subordinate process is allowed to register and listen to messages of multiple modules.

[0023] Furthermore, the shared database uses an sqlite database, is developed with an open-source C language library, and abstracts the upper-layer interface to support cross-platform;

[0024] The IPC-notify unit and the IPC-launch unit are provided with C++ abstract layer interfaces for different systems to integrate and implement the interface functions.

[0025] Furthermore, the system platform includes: iOS / Mac OS, and Android system.

[0026] A real-time data synchronization and refresh method for multiple processes on a mobile device based on the above system, comprising the following steps:

[0027] S1, initialization and configuration of the main process and subordinate processes;

[0028] S2, when the main process writes / updates data in the shared database by module, it broadcasts messages to the subordinate processes by module through IPC-notify;

[0029] The subordinate processes register and listen for the messages broadcast by the main process in units of modules as needed. When receiving the message that the module it is concerned about has been updated, it reads the data of that module from the shared database and refreshes the window of the module;

[0030] S3, when the subordinate process fails to obtain the data of the required module, it directly launches the main process through IPC-launch and informs it of the required data module; after the main process updates the data of the corresponding module in the shared database, it reversely launches the subordinate process through IPC-launch to notify it to update the data.

[0031] Furthermore, in the step S1, the initialization and configuration method of the main process includes:

[0032] When the process starts, it calls the SDK initialization interface and configures the process type as the main process;

[0033] Configure the information of the subordinate processes to which it belongs, including launch-id and package name information;

[0034] Configure the path of the shared database, and create it if there is no shared database;

[0035] Initialize the shared database module and create a table with module-id as the key.

[0036] Furthermore, the initialization and configuration method of the subordinate process includes:

[0037] [[ID=3,6]]When the process starts, it calls the SDK initialization interface and configures the process type as the subordinate process;

[0038] Configure the information of its main process, including launch-id and package name information;

[0039] Configure the path of the shared database.

[0040] Furthermore, the step S2 specifically includes:

[0041] The subordinate process registers message monitoring by module - id through the IPC - notify unit;

[0042] The main process writes / updates the data of the corresponding module in the shared database by module - id;

[0043] After the main process successfully writes / updates the shared data, it sends a broadcast message by module - id through IPC - notify;

[0044] The subordinate process receives the broadcast message sent by the main process with the module - id as the message name;

[0045] The subordinate process reads the shared database according to the module - id and refreshes the corresponding module window.

[0046] Further, step S3 specifically includes:

[0047] When the subordinate process cannot read the data of the relevant module, it launches the main process through IPC - launch and passes the module - id to be read and the launch - id of its own process through the launch parameters;

[0048] The main process is launched and obtains the moudle - id and launch - id parameters, updates the shared data of the corresponding module according to the module - id, and then reversely launches the subordinate process according to the obtained launch - id of the subordinate process, carrying the module - id parameter;

[0049] The subordinate process is reversely launched and obtains the module - id, reads the shared data according to the module - id and refreshes the window of the corresponding module.

[0050] The present disclosure divides multiple processes into a main process and multiple subordinate processes belonging to it, and through the shared database, IPC - notify and IPC - launch, realizes the real - time update and sharing of data between processes and the real - time refresh of windows. Compared with the prior art, the beneficial effects of the present disclosure are:

[0051] ① By combining the mechanisms of shared storage, pull-up mechanism, and system broadcast message for inter-process communication, a relatively complete solution is achieved in the scenario of real-time, secure communication and refreshing among multiple processes / windows by module in the mobile system; ② By differentiating different categories of data by module, the functional coupling in inter-process communication is effectively solved; ③ It supports cross-platform use: it can be used on mobile systems (iOS / iPad OS, Android). Additionally, since the message mechanism, pull-up mechanism framework used in the iOS system is exactly the same as that of Mac OS, it can also be used on the Mac OS system; To ensure the generality of different systems, sqlite database is used for shared storage, and the upper-layer interfaces are abstracted, and the C / C++ language is used to support cross-platform. Brief Description of the Drawings

[0052] The above and other objects, features, and advantages of the present disclosure will become more apparent by describing the exemplary embodiments of the present disclosure in more detail with reference to the accompanying drawings, wherein, in the exemplary embodiments of the present disclosure, the same reference numerals generally represent the same components.

[0053] Figure 1 It is the overall flowchart of the method for real-time synchronization and refreshing of multi-process data on the mobile terminal according to the present disclosure;

[0054] Figure 2 It is the flowchart of the main process notifying the subordinate process to refresh the module window through message broadcast;

[0055] Figure 3 It is the flowchart of the subordinate process actively obtaining shared data to update the window. Detailed Description of the Embodiments

[0056] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0057] Since in the enterprise mobile security office scenario, there are often multiple applications that need to share user login information, configurations, policy information, etc., the present disclosure provides an inter-process communication solution for real-time sharing of data and refreshing windows among multiple processes in the mobile system. This solution divides the processes into two categories: the main process and the subordinate process, and the main process and the subordinate process achieve real-time communication between processes through shared encrypted databases, IPC-notify, IPC-launch, etc.

[0058] In an exemplary embodiment, a system for real-time sharing of data and refreshing windows among multiple processes on the mobile terminal mainly consists of the following:

[0059] (1) Main process: The process mainly responsible for the operations related to writing / updating the shared database, having read / write permissions for the shared database. The main process and the shared database are uniquely corresponding, and only one main process can be configured for one shared database. The shared database is created during initialization. When performing write or update operations on the shared database, broadcast messages are sent to the listening subordinate processes through the IPC communication message module to notify them to update the data.

[0060] (2) Subordinate process: Only has read permissions for the shared database. The subordinate process is uniquely corresponding to the shared database and the main process through configuration. Preferably, multiple subordinate processes can be configured for one main process. During the initialization process, relevant modules need to be registered and listened to. When receiving a message from the main process, the window is refreshed. Preferably, one process can listen to one or more modules.

[0061] (3) System message center (IPC - notify): A message mechanism for inter - process communication, including a receiver and a sender. The receiving process registers for message listening to the system message center, and the sending process broadcasts to the receiving process. The registration and sending of messages require configuring the message name. The message name registered by the receiving process needs to be the same as the message name sent by the sending process to receive this message. Preferably, in this embodiment, the module - id is directly used as the message name. Different systems have their own system message mechanisms, such as the Darwin message center (DarwinNotify) for iOS / MacOS systems and the Broadcast Receivers for Android systems.

[0062] (4) IPC - launch: A launching mechanism for inter - process communication, including a launching party and a launched party. The launched party process configures its own launch - id, and the launching party process launches the launched party process in real - time through the launch - id. Here, the launch - id has different configurations according to the launching mechanisms of different systems. For example, for iOS / MacOS systems, it is through configuring the URLScheme, and for Android systems, it can be through Intent to configure the component to be launched.

[0063] (5) Shared database: A database established on the basis of a shared storage directory, used for sharing data among multiple processes. Since the processes of the mobile system are all sandboxed and cannot directly access the common directory, the shared storage mechanism of its system needs to be used. For example, AppGroup for iOS / Mac OS systems and ContentProviders for Android systems are both shared storage mechanisms for cross - process communication.

[0064] In this embodiment, to solve the functional coupling of inter-process communication, different categories of data are decoupled by module, the modules are identified by module-id, and all inter-process communication methods are carried out with module-id as the key. A table is created in the shared database with module-id as the key. The IPC-notify unit registers listening and sends messages with module-id as the key, and the IPC-launch unit carries module-id information when launching the other process to perform data update operations for the corresponding module.

[0065] In this embodiment, when the main process writes or updates the data of the corresponding module id in the shared database, the IPC-notify unit broadcasts a message with the module id as the key to the subordinate process;

[0066] The subordinate process registers and listens for messages with the module id as the key. When receiving the broadcast message sent by the main process through the IPC-notify unit, the subordinate process reads the data of the corresponding module id and refreshes the window of the corresponding module;

[0067] The subordinate process can also launch the main process through IPC-launch to request an update of the data of the module id to which it belongs; when launching the other party through IPC-launch, the launch-id is used as the unique identifier of the other process.

[0068] In this embodiment, preferably, the cross-platform and cross-system middleware is developed using the C / C++ language, and the shared database module is developed using the sqlite3 open-source c language library; the IPC-notify unit and the IPC-launch unit establish a C++ abstract layer interface for different systems to integrate and implement the interface functions. The platforms include iOS / Mac OS and Android systems.

[0069] Based on the above composition, the overall process of real-time data sharing and window refreshing among multiple processes of a mobile system is as shown in the appendix Figure 1 and mainly includes the following steps:

[0070] S100, initialization and configuration of the main process and the subordinate process.

[0071] The initialization and configuration of the main process include the following steps:

[0072] Step 1: When the process starts, it calls the SDK initialization interface and configures the process type as the main process.

[0073] Step 2: Configure the information of the subordinate process to which it belongs, including launch-id, package name information, etc.

[0074] Step 3: Configure the shared database path. If there is no shared database, create one.

[0075] Step 4: Initialize the shared database module and create a table with module-id as the key.

[0076] Step 5: Write to or update the shared database by module.

[0077] The initialization and configuration of the subordinate process include the following steps:

[0078] Step 1: When the process starts, call the SDK initialization interface and configure the process type as a subordinate process.

[0079] Step 2: Configure the information of its main process, including launch-id, package name information, etc.

[0080] Step 3: Configure the shared database path.

[0081] Step 4: Read the shared database data by module.

[0082] S200, when the main process writes to or updates the data of the corresponding module id in the shared database, it broadcasts a message with the module id as the key to the subordinate process through IPC-notify;

[0083] The subordinate process registers and listens for messages with the module id as the key as needed. When it receives the broadcast message sent by the main process through IPC-notify, the subordinate process reads the data of the corresponding module id and refreshes the window of the corresponding module.

[0084] Figure 2 It shows the principle and flowchart of the main process notifying the subordinate process to read and refresh the module data in real time by broadcast message after writing / updating the shared database, specifically including the following steps:

[0085] Step 1: The subordinate process registers a message listener with the module-id as the key.

[0086] Step 2: The main process performs a write or update operation on the shared database with the module-id as the key.

[0087] Step 3: The main process sends a broadcast message with the module-id as the key.

[0088] Step 4: The subordinate process receives the broadcast message, reads the data of the corresponding module of the shared data with the module-id as the key, and refreshes the window of the corresponding module.

[0089] In S300, when the subordinate process fails to obtain the data of the required module, the main process is directly launched through IPC-launch, and the required data module is informed; after the main process updates the data of the corresponding module in the shared database, the subordinate process is reversely launched through IPC-launch to notify it to update the data.

[0090] Figure 3 The process of the subordinate process actively reading the shared database and refreshing the window is shown, and the process includes the following steps:

[0091] Step 1: The user opens the subordinate process, and the subordinate process reads the shared database according to the module-id.

[0092] Step 2: If the shared data is successfully read, the corresponding window of the module is directly refreshed.

[0093] Step 3: If the shared data reading fails, the IPC-launch unit is triggered to launch the main process according to the main process launch-id, and parameters such as the module-id and the subordinate process launch-id are carried.

[0094] Step 4: After the main process is launched, corresponding module business operations are performed according to the module-id carried in Step 3, and the shared database is written or updated by module.

[0095] Step 5: The main process reversely launches the subordinate process through the IPC-launch unit according to the subordinate process launch-id carried in Step 3.

[0096] Step 6: The subordinate process is reversely launched and obtains the module-id, reads the shared data according to the module-id and refreshes the window of the corresponding module.

[0097] In this embodiment, the read / write operation of the shared database creates a table with the module-id as the key, decouples between modules, and different subordinate processes only need to listen to the modules they are concerned about. When the main process updates the corresponding module, a broadcast message with the corresponding module-id as the key is sent through the IPC-notify unit.

[0098] As a method for supporting cross-platform and general communication among multiple processes, this embodiment is provided to the docking processes in the form of SDK integration, abstracts the external interface and uses cross-platform C++ language.

[0099] This embodiment can be one or more processors and a memory; it contains one or more programs, where the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include instructions for executing the above method.

[0100] This embodiment may be a computer-readable storage medium storing one or more programs, the one or more programs including instructions which, when executed by a computing device, cause the computing device to execute the above method.

[0101] The above technical solutions are only exemplary embodiments of the present invention. For those skilled in the art, based on the disclosed application methods and principles of the present invention, it is easy to make various types of improvements or deformations, not limited to the methods described in the above specific embodiments of the present invention. Therefore, the foregoing description is only preferred and does not have a restrictive meaning.

Claims

1. A real-time data synchronization and refresh system for multiple processes on a mobile device, characterized in that Including: Shared database: A database established on the basis of a shared storage directory, used to store shared data between processes; the shared data is classified into different modules by category; Main process, corresponding one-to-one with the shared database, used to write to or update the shared database by module and notify subordinate processes by module; Subordinate process, which only has read permission for the shared database, used to read the data of the corresponding module from the shared database and refresh the window after learning that the required data module has been updated; IPC-notify unit, used to send broadcast messages to subordinate processes by module when the main process writes to or updates the module of the shared database; the subordinate process obtains the message that the concerned module has been updated by registering and listening to the broadcast message by module; IPC-launch unit, used for direct real-time pulling and jumping between the main and subordinate processes and passing parameters, including: the subordinate process pulls up the main process through IPC-launch and passes the module id it needs to read and the launch-id of its own process through the pull-up parameters; after writing or updating the data of the corresponding module in the shared database, the main process pulls up the subordinate process in reverse through IPC-launch to notify it to update the data.

2. The system according to claim 1, characterized in that, The shared data in the system classifies different types of data by module, identifies the module by module-id, creates a table with module-id as the key in the shared database, and all inter-process communication methods are also based on module-id as the key, including: the IPC-notify unit registers and listens to broadcast messages and sends broadcast messages with module-id as the key; the IPC-launch unit also carries module-id information when pulling up the other process to perform data update operations for the corresponding module.

3. The system according to claim 1, wherein One main process is allowed to have multiple subordinate processes; one subordinate process is allowed to register and listen to messages of multiple modules.

4. The system according to claim 1, characterized in that The shared database uses an sqlite database, is developed with an open-source C language library, and abstracts the upper-layer interface to support cross-platform; The IPC-notify unit and the IPC-launch unit are provided with C++ abstract layer interfaces for different systems to integrate and implement interface functions.

5. The system according to claim 1, wherein The platforms of the system include: iOS / MacOS and Android systems.

6. A method for real-time synchronization and refreshing of multi-process data on a mobile terminal using the system according to any one of claims 1-5, including the following steps: S1, Initialization and configuration of the main process and the subordinate process; S2, When the main process writes / updates the data in the shared database by module, it broadcasts messages to the subordinate process by module through IPC-notify; The subordinate process registers and listens to the messages broadcast by the main process by module as needed. When it receives the message that the concerned module has been updated, it reads the data of the module from the shared database and refreshes the window of the module; S3, When the subordinate process fails to obtain the data of the required module, it directly pulls up the main process through IPC-launch and tells it the required data module; After the main process updates the data of the corresponding module in the shared database, it reversely launches the subordinate process through IPC-launch to notify it to update the data.

7. The method according to claim 6, wherein In the step S1, the initialization and configuration method of the main process includes: When the process starts, it calls the SDK initialization interface and configures the process type as the main process; Configure the information of the subordinate processes to which it belongs, including the launch-id and package name information; Configure the path of the shared database, and create it if there is no shared database; Initialize the shared database module and create a table with the module-id as the key.

8. The method according to claim 6, characterized in that, The initialization and configuration method of the subordinate process includes: When the process starts, it calls the SDK initialization interface and configures the process type as the subordinate process; Configure the information of its main process, including the launch-id and package name information; Configure the path of the shared database.

9. The method according to claim 6, wherein The step S2 specifically includes: The subordinate process registers a message listener by module-id through the IPC-notify unit; The main process writes / updates the data of the corresponding module in the shared database by module-id; After the main process successfully writes / updates the shared data, it sends a broadcast message by module-id through IPC-notify; The subordinate process receives the broadcast message with the module-id as the message name sent by the main process; The subordinate process reads the shared database according to the module-id and refreshes the corresponding module window.

10. The method according to claim 5, characterized in that The step S3 specifically includes: When the subordinate process fails to read the data of the relevant module, it launches the main process through IPC-launch and passes the module-id to be read and its own process launch-id through the launch parameters; The main process is launched and obtains the moudle-id and launch-id parameters, updates the shared data of the corresponding module according to the module-id, and then reversely launches the subordinate process according to the obtained launch-id of the subordinate process, carrying the module-id parameter; The subordinate process is reversely launched and obtains the module-id, reads the shared data according to the module-id and refreshes the window of the corresponding module.

Images