Cross-process communication method, system and vehicle-mounted terminal

Abstract

The present application provides a cross-process communication method, system and vehicle-mounted terminal. Among them, the method includes: constructing a listening component through a cross-process event bus framework, where the listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver; if it is detected that a target event changes in the first process, then using the first listening object, broadcasting the event information of the target event to the broadcast receiver, so that the broadcast receiver determines whether the target event is subscribed by the second process according to the event information; when the target event is subscribed by the second process, using the broadcast receiver to send the event information to the second listening object to complete the cross-process transmission of the event information. Combining the event bus framework and the broadcast mechanism, creating a listening object and a broadcast receiver for cross-process communication through the cross-process event bus framework, and realizing simple and efficient cross-process communication without introducing a third-party library.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a cross-process communication method, system, and vehicle-mounted terminal. Background Art

[0002] With the rapid development of mobile applications, the functions of Android applications have become increasingly rich, and modular design has become a commonly adopted architecture strategy. In this architecture, communication between different components or processes becomes crucial. Especially for applications that need to share data or events among multiple components, a cross-component and even cross-process communication mechanism is indispensable. In the face of this demand, developers usually choose to integrate a cross-process event bus framework to achieve it.

[0003] In the related art, the implementation of a cross-process event bus framework usually depends on a third-party library. Although the third-party library has powerful functions, due to the introduction of the third-party library, cross-process communication also faces the following problems. 1. Dependency complexity: The introduced third-party library increases the dependency complexity of the project; 2. Increase in project size: The introduction of the third-party library may increase the size of the project and affect the loading speed; 3. Compatibility issues: The third-party library may have compatibility issues, affecting the stability of the project; 4. Complex implementation of sticky events and cross-process events: When implementing sticky events and cross-process events in the third-party library, additional dependencies usually need to be introduced or relatively complex logic needs to be implemented. Therefore, there is an urgent need to propose an event bus framework to simplify the cross-process event transmission process through a lighter, more efficient, and easier-to-integrate cross-process event bus mechanism. Summary of the Invention

[0004] In view of the above-mentioned disadvantages of the prior art, this application discloses a cross-process communication method, system, and vehicle-mounted terminal, which are used to solve the technical problem of the complex and inefficient cross-process communication mechanism in the prior art.

[0005] In a first aspect, this application provides a cross-process communication method, where the method includes: constructing a listening component through a cross-process event bus framework, where the listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process, and cross-process communication is performed between the first process and the second process; if it is monitored that a target event changes in the first process, then using the first listening object, broadcasting event information of the target event to the broadcast receiver, so that the broadcast receiver determines whether the target event is subscribed to by the second process according to the event information; when the target event is subscribed to by the second process, using the broadcast receiver to send the event information to the second listening object to complete the cross-process transmission of the event information.

[0006] In an embodiment of the present application, the construction method of the cross-process event bus framework includes: creating a listener object generation class, and setting the listener object script, the first attribute, and the first function of the listener object generation class. The first attribute includes the sticky subscription attribute and the identification attribute of the event, and the first function includes the observer registration function; creating a listener object management class, and setting the second attribute and the second function of the listener object management class. The second attribute includes a listener object set for storing listener objects, and the second function includes an initialization function and a listener object creation function; creating a broadcast event processing class, and setting the third function of the broadcast event processing class. The third function includes a broadcast reception function to implement broadcast reception according to the broadcast event processing class.

[0007] In an embodiment of the present application, constructing a listening component through the cross-process event bus framework includes: obtaining the process name of the first process, the business scenario and event identifier of the target event, the first observer identifier of the observer in the first process who is concerned about the target event, and the second observer identifier of the observer in the second process who is concerned about the target event; calling the listener object management class, registering the broadcast receiver through the initialization function, and generating the first listening instance and the second listening instance of the target event through the listener object creation function; in response to the first listening instance, running the listener object script and executing the observer registration function to set the sticky subscription attribute and the identification attribute of the first listening instance according to the business scenario and the event identifier, and registering the first observer on the first listening instance according to the first observer identifier to generate the first listening object; in response to the second listening instance, running the listener object script and executing the observer registration function to set the sticky subscription attribute and the identification attribute of the second listening instance according to the business scenario and the event identifier, setting the process name on the second listening instance, and registering the second observer on the second listening instance according to the second observer identifier to generate the second listening object.

[0008] In an embodiment of the present application, the cross-process event bus framework includes a listener object generation class and a broadcast event processing class. The listener object generation class includes a broadcast function, and the broadcast event processing class includes a broadcast reception function; using the first listening object to broadcast the event information of the target event to the broadcast receiver includes: resetting the event value of the target event based on the change of the target event; generating the event information in the first listening object according to the event value, the event identifier of the target event, and the process name of the first process; calling the listener object generation class and executing the broadcast function to broadcast the event information; in response to the broadcast event, triggering the broadcast reception function to enable the broadcast receiver to receive the event information.

[0009] In an embodiment of the present application, the broadcast receiver determines whether the target event is subscribed by the second process according to the event information, including: parsing the event information to obtain the parsed event identifier and process name; matching the parsed event identifier and process name with the event identifier and process name set on the second listening object respectively; if the event identifier and / or the process name fails to match, determining that the target event is not subscribed by the second process; if both the event identifier and the process name match successfully, determining that the target event is subscribed by the second process.

[0010] In an embodiment of the present application, the listening object generation class further includes a publishing function; after generating the event information in the first listening object, it further includes: calling the listening object generation class, executing the publishing function, and publishing the event information through the first listening object, so that the first observer registered on the first listening object receives the event information.

[0011] In an embodiment of the present application, after using the broadcast receiver to send the event information to the second listening object, it further includes: calling the listening object generation class, executing the publishing function, and publishing the event information through the second listening object, so that the second observer registered on the second listening object receives the event information.

[0012] In an embodiment of the present application, the cross-process event bus framework includes a listening object management class and a garbage collection mechanism, and the listening object management class includes a listening object removal function; after completing the cross-process transmission of the event information, it further includes: monitoring the number of second observers on the second listening object; determining the removal method of the second listening object according to the subscription method of the target event; if the subscription method is a persistent subscription method, when the number reaches a preset number threshold, in response to the listening object removal operation, calling the listening object management class, executing the listening object removal function, and removing the second listening object; if the subscription method is a non-persistent subscription method, when the number reaches a preset number threshold, triggering the garbage collection mechanism to clear the second listening object.

[0013] In a second aspect, the present application provides a cross-process communication system, which includes: a construction module for constructing a listening component through a cross-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process, for cross-process communication between the first process and the second process; an information publishing module for, if it is monitored that a target event changes in the first process, using the first listening object to broadcast event information of the target event to the broadcast receiver, so that the broadcast receiver determines whether the target event is subscribed by the second process according to the event information; a cross-process communication module for, when the target event is subscribed by the second process, using the broadcast receiver to send the event information to the second listening object to complete cross-process transmission of the event information.

[0014] In a third aspect, the present application provides a vehicle-mounted terminal, which includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the vehicle-mounted terminal implements the cross-process communication method described in the first aspect.

[0015] As described above, a cross-process communication method, system and vehicle-mounted terminal provided by the embodiments of the present application have the following beneficial effects:

[0016] First, a listening component is constructed through a cross-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process, and cross-process communication is carried out between the first process and the second process. Then, when it is monitored that a target event changes in the first process, the event information of the target event is broadcast to the broadcast receiver by using the first listening object to realize the publication of the target event. The broadcast receiver will determine whether the target event is subscribed by the second process according to the received event information. If it is subscribed by the second process, the broadcast receiver will send the event information to the second listening object to realize the reception of the event information of the second process. Combining the cross-process event bus framework and the broadcast mechanism, a listening object and a broadcast receiver for cross-process communication are directly created through the cross-process event bus framework, and the publication and reception of event messages are realized by the respective listening objects between two processes and the broadcast receiver of the receiving process, without introducing a third-party library, reducing the dependency complexity of the project, reducing the volume of the project, and improving the compatibility of the project, realizing a lightweight, efficient and easy-to-integrate cross-process event bus framework, and realizing a cross-process event transmission mechanism in a lightweight manner.

[0017] It should be understood that the above general description and subsequent detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings herein are incorporated into and constitute a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts. In the drawings:

[0019] Figure 1 is a schematic diagram of an implementation environment of a cross-process communication system shown in an exemplary embodiment of the present application;

[0020] Figure 2 is a flowchart of a cross-process communication system method shown in an exemplary embodiment of the present application;

[0021] Figure 3 is a schematic diagram of a cross-process event bus framework shown in an exemplary embodiment of the present application;

[0022] Figure 4 is a flowchart of a specific cross-process communication method shown in an exemplary embodiment of the present application;

[0023] Figure 5 is a flowchart of communication between a voice process and a music process shown in an exemplary embodiment of the present application;

[0024] Figure 6 is a block diagram of a cross-process communication system shown in an exemplary embodiment of the present application;

[0025] Figure 7 is a schematic diagram of a structure of an in-vehicle terminal provided by an embodiment of the present application. Detailed Embodiments

[0026] The following will illustrate the implementation manners of the present application with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present application from the content disclosed in this specification. The present application can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for explaining the present application and not for limiting the protection scope of the present application.

[0027] It should be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present application in a schematic manner. Therefore, only the components related to the present application are shown in the diagrams, rather than being drawn according to the number, shape, and size of the components in actual implementation. The form, quantity, and proportion of each component in actual implementation can be arbitrarily changed, and the layout form of the components may also be more complex.

[0028] In the following description, a large number of details are explored to provide a more thorough explanation of the embodiments of the present application. However, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present application difficult to understand.

[0029] LiveData: A class in Android used to hold observable data. It is an observable data holding class with lifecycle awareness, which means it can automatically manage data subscription and unsubscription during the lifecycle of a component. LiveData follows the observer pattern, allowing data objects to notify observers when the data changes.

[0030] Event bus framework: A design pattern that provides a way to pass events in an application without direct coupling between the event sender and the receiver. It allows different components or services to communicate by publishing and subscribing to events, thus promoting code decoupling.

[0031] Jar package: A file format used to aggregate multiple Java class files and related resources, usually used for distributing Java libraries or applications. It is a compressed file that contains.class files, resource files, and optional metadata files, etc.

[0032] SDK: SDK (Software Development Kit) is a set of toolkits developed for a specific platform or programming language, aiming to help developers create applications. The SDK usually includes libraries, documentation, sample code, debugging tools, and other resources, etc.

[0033] Sticky subscription: A subscription mode in which subscribers can receive an event even if they register after the event is published. That is, sticky events are retained for a period of time after they are published until a subscriber comes to receive them. Therefore, sticky subscriptions allow subscribers to receive the latest events immediately after joining, regardless of when they start listening.

[0034] Non-sticky subscription: A subscription mode in which subscribers can only receive events published after they start listening. If an event is published before a subscriber registers, the subscriber will not receive these events.

[0035] Hook: Refers to a mechanism that allows developers to insert additional code or logic to extend or change the behavior of a program without modifying the existing code.

[0036] Android Broadcast Mechanism: The Android Broadcast Mechanism is a mechanism provided by the Android operating system for passing messages between different applications. Broadcasting is a way of event passing that allows one application (the sender) to send notifications or data to other applications (the receivers).

[0037] Map Collection: Map is a collection type that stores key-value pairs. Each key is unique in the collection, and the value can be any type of object. The Map collection is mutable, which means you can add, delete, or modify key-value pairs.

[0038] First of all, it should be noted that cross-process communication refers to the process of data exchange between two processes, allowing different processes to share data, pass information, or coordinate their activities; the event bus framework is an event publishing / subscribing structure that realizes decoupled communication between different components through the publish-subscribe pattern, allowing different components to communicate by publishing and subscribing to events without directly depending on each other; the cross-process event bus framework is an event processing framework based on the publish-subscribe pattern that allows communication and event processing between different processes and realizes an efficient event passing mechanism through the observer pattern.

[0039] However, the inventors of this application have found through research that the implementation of the cross-process event bus framework usually depends on third-party libraries. Although the functions of third-party libraries are powerful, due to the introduction of third-party libraries, cross-process communication also faces the following problems. 1. Dependency complexity: The introduced third-party libraries increase the dependency complexity of the project; 2. Increase in project size: The introduction of third-party libraries may increase the size of the project and affect the loading speed; 3. Compatibility issues: Third-party libraries may have compatibility issues, affecting the stability of the project; 4. Complex implementation of sticky events and cross-process events: When implementing sticky events and cross-process events in third-party libraries, additional dependencies usually need to be introduced or relatively complex logic needs to be implemented.

[0040] Therefore, please refer to Figure 1 , Figure 1 which is a schematic diagram of the implementation environment of a cross-process communication system shown in an exemplary embodiment of this application. As Figure 1As shown, the implementation environment includes a vehicle 110 and an inter-process communication system 120. Among them, the inter-process communication system 120 is embedded in the vehicle 110 and is used to implement inter-process communication in the vehicle 110. The inter-process communication system 120 includes, but is not limited to, a vehicle-mounted system, an in-vehicle computer, etc. Combining the inter-process event bus framework and the broadcast mechanism, a listening object and a broadcast receiver for inter-process communication are directly created through the inter-process event bus framework. The event messages are published and received by the respective listening objects of the two processes and the broadcast receiver of the receiving process, without introducing a third-party library, reducing the dependency complexity of the project, reducing the volume of the project, and improving the compatibility of the project, realizing a lightweight, efficient, and easy-to-integrate inter-process event bus framework, and implementing the inter-process event transfer mechanism in a lightweight manner.

[0041] Please refer to Figure 2 , Figure 2 is a flowchart of a method for an inter-process communication system shown in an exemplary embodiment of the present application. This method can be applied to Figure 1 the implementation environment shown. It should be understood that this method can also be applicable to other exemplary implementation environments, and this embodiment does not limit the implementation environment applicable to this method. In addition, in the embodiment of the present application, this inter-process communication method can be applicable to the Android system, that is, it can be applied to mobile devices of the Android system, such as mobile phone terminals, vehicle-mounted terminals, etc.

[0042] As Figure 2 shown, in an exemplary embodiment, the inter-process communication method at least includes steps S210 to S230, which are introduced in detail as follows:

[0043] Step S210, construct a listening component through the inter-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process. Inter-process communication occurs between the first process and the second process.

[0044] It should be noted that the communication between the first process and the second process is cross-process communication. The first process and the second process can be the publisher (sender) and the receiver of events for each other. Additionally, a single publisher can correspond to multiple receivers, and a single receiver can listen to multiple publishers. In the publisher process, an event corresponds to a listener object, which is used to monitor changes to the event in this process and implement event publishing. In the receiver process, an event also corresponds to a listener object, which is used to monitor changes to the event in other processes and implement event reception. For the receiver process, all its listener objects and the events of the subscribed publisher processes have a one-to-one relationship. For example, there are three listener objects in the receiver process, one corresponding to listening to event A of the publisher process, one corresponding to listening to event B of the publisher process, and one corresponding to listening to event C of the publisher process. Among them, the publisher processes can be the same process or different processes.

[0045] It should also be noted that since the broadcast mechanism is used for cross-process event propagation, a broadcast receiver is required to receive and process the events transmitted across processes. Each process can create a corresponding broadcast receiver. When a process acts as a receiver process, this broadcast receiver is used to receive and process the broadcast events of other processes.

[0046] In this embodiment, the first process is used as the publisher process and the second process is used as the receiver process. Therefore, the listener objects of the first process and the second process and the broadcast receiver of the second process are created to receive the broadcast events of the first process. In this way, without introducing any other third-party libraries, Jar packages, or SDKs, cross-process communication is achieved through the listener objects and the broadcast receiver.

[0047] In one embodiment, the construction method of the cross-process event bus framework includes: creating a listener object generation class and setting the listener object script, the first attribute, and the first function of the listener object generation class. The first attribute includes the sticky subscription attribute and the identification attribute of the event, and the first function includes the observer registration function; creating a listener object management class and setting the second attribute and the second function of the listener object management class. The second attribute includes the listener object set for storing listener objects, and the second function includes the initialization function and the listener object creation function; creating a broadcast event processing class and setting the third function of the broadcast event processing class. The third function includes the broadcast reception function to implement broadcast reception based on the broadcast event processing class.

[0048] In this embodiment, the listener object generation class is an inner class of the observable data holding class and inherits from the mutable real-time data class; the listener object script of the listener object generation class is used to generate listener objects. Among the first attributes set, the identification attribute can characterize the event corresponding to the generated listener object, and whether the sticky subscription attribute is turned on or off can characterize whether the event corresponding to the generated listener object supports sticky subscription or non-sticky subscription. Among the first functions set, the observer registration function is used to register an observer on the listener object when the listener object is generated, and the registered observer is a component that needs to pay attention to the event corresponding to the listener object; the listener object management class is used to manage listener objects, including obtaining, constructing, and removing, etc. Among the second attributes set, the listener object set is used to store all listener objects within each process. Among the second functions set, the listener object creation function is used to create listener objects, and the listener object creation function internally implements operations for finding, creating, and storing listener objects; the broadcast event processing class is used to receive and process broadcast events. Among the third functions set, the broadcast reception function enables the broadcast receiver to receive broadcast events published by other processes.

[0049] In this embodiment, building a cross-process event bus framework, namely including a listener object generation class, a listener object management class, and a broadcast event processing class, realizes a lightweight cross-process event bus framework, and uses the listener object generation class and the listener object management class to generate and manage listener objects and the broadcast mechanism in the broadcast event processing class to achieve simple and efficient communication between processes.

[0050] As a possible embodiment, the listener object set can be a Map set, which stores listener objects in the form of key-value pairs, that is, the listener object is associated and stored one-to-one with the key. The corresponding listener object can be obtained from the set through the key of the event. The key represents the event identifier, and the identifier can be a name, a number, etc., or the fully qualified class name of the event, integrating various attribute information of the event. The Map set is mutable and key-value pairs can be added, deleted, or modified.

[0051] It should also be noted that the sticky subscription attribute of the corresponding event set on the listening object is set according to the business scenario. Even if the observer registers after the event is published, if it is necessary to receive the previous information, the sticky subscription attribute is turned on; if the observer only needs to receive the information published after they start listening, the sticky subscription attribute is turned off. In this way, the event supports sticky subscription and non-sticky subscription, simplifies the implementation of cross-process sticky events, and can meet the needs of sticky / non-sticky subscription methods in different process communications while realizing cross-process communication. In addition, based on sticky subscription and non-sticky subscription, the observers registered on each listening object can be registered after the event changes or before the event changes, and, based on the observer's attention requirements for event changes, the observers registered on the listening object can be dynamically changed.

[0052] In one embodiment, a listening component is constructed through a cross-process event bus framework, including: obtaining the process name of the first process, the business scenario and event identifier of the target event, the first observer identifier of the observer in the first process who is concerned about the target event, and the second observer identifier of the observer in the second process who is concerned about the target event; calling the listening object management class, registering a broadcast receiver through the initialization function, and generating a first listening instance and a second listening instance of the target event through the listening object creation function; in response to the first listening instance, running the listening object script and executing the observer registration function to set the sticky subscription attribute and identifier attribute of the first listening instance according to the business scenario and event identifier, and registering the first observer on the first listening instance according to the first observer identifier to generate a first listening object; in response to the second listening instance, running the listening object script and executing the observer registration function to set the sticky subscription attribute and identifier attribute of the second listening instance according to the business scenario and event identifier, setting the process name on the second listening instance, and registering the second observer on the second listening instance according to the second observer identifier to generate a second listening object.

[0053] It should be noted that, whether it is the publishing process or the receiving process, the construction method of the listening object is to be constructed by combining the listening object management class and the listening object generation class. In cross-process communication, if an event of the publishing process is subscribed by the receiving process, in the receiving process, the second listening object corresponding to this event can be regarded as a copy or mirror of the first listening object corresponding to the same event in the publishing process.

[0054] In this embodiment, the first process serves as the publishing process. One event corresponds to one first listener object. For each first listener object, sticky subscription attributes and identification attributes are set according to the business scenario and event identifier of the corresponding event, and a first observer is registered according to the first observer identifier, thereby generating a first listener object and storing it in the listener object set of the first process; the second process serves as the receiving process. One event corresponds to one second listener object. For each second listener object, sticky subscription attributes and identification attributes are set according to the business scenario and event identifier of the corresponding event, and the process name where the subscribed event is located (such as the process name of the first process) is set, and a second observer is registered according to the second observer identifier, thereby generating a second listener object and storing it in the listener object set of the second process. In this way, the sticky subscription attribute on the listener object enables the event to support sticky or non-sticky subscription, and the identification attribute enables cross-process events to be correspondingly subscribed and published, ensuring the reliability of inter-process communication in the cross-process event bus framework.

[0055] In this embodiment, the broadcast receiver performs initialization for registration by calling the listener object management class. It should be noted that after the publishing process broadcasts an event, all the broadcast receivers registered on this broadcast channel can monitor the event information broadcast by the publishing process, and each broadcast receiver can determine whether to pass the event information to the second listener object according to the specific subscribed events of their respective receiving processes. In this way, the reliability of event publishing and receiving in cross-process communication is ensured.

[0056] Step S220: If it is detected that the target event changes in the first process, use the first listener object to broadcast the event information of the target event to the broadcast receiver, so that the broadcast receiver can determine whether the target event is subscribed by the second process according to the event information.

[0057] In this embodiment, when the target event changes, the event information is broadcast through the first listener object corresponding to the target event, and the broadcast receiver relays the event information passed across processes.

[0058] Before using the first listener object to broadcast the event information of the target event to the broadcast receiver, it is necessary to first obtain the first listener object from the listener object set of the first process. Specifically, the listener object management class can be called to match the event identifier of the target event as the key with the identification attributes of each first listener object in the listener object set, so as to obtain the first listener object corresponding to the target event. Considering the situation where the first listener object corresponding to the target event does not exist in the listener object set, a first listener object corresponding to the target event is newly created according to the in-process event bus framework and saved in the listener object set. In this way, it can be directly obtained next time.

[0059] In one embodiment, the cross-process event bus framework includes a listening object generation class and a broadcast event processing class. The listening object generation class includes a broadcast function, and the broadcast event processing class includes a broadcast reception function. Using a first listening object to broadcast the event information of a target event to a broadcast receiver includes: resetting the event value of the target event based on the change of the target event; generating event information in the first listening object according to the event value, the event identifier of the target event, and the process name of the first process; calling the listening object generation class to execute the broadcast function and broadcast the event information; and in response to the broadcast event, triggering the broadcast reception function so that the broadcast receiver receives the event information.

[0060] In this embodiment, resetting the event value of the target event and generating event information in the first listening object according to the event value, the event identifier of the target event, and the process name of the first process realizes the information publication of the target event in the first process. After the event value changes, the listening object generation class is called to execute the broadcast function so that the broadcast receiver receives the event information, which realizes the cross-process broadcast of the information of the target event in the first process. In this way, the cross-process publication of event information is realized.

[0061] In one embodiment, the broadcast receiver determines whether the target event is subscribed by a second process according to the event information, including: parsing the event information to obtain the parsed event identifier and process name; matching the parsed event identifier and process name with the event identifier and process name set on the second listening object respectively; if the event identifier and / or the process name fails to match, determining that the target event is not subscribed by the second process; if both the event identifier and the process name match successfully, determining that the target event is subscribed by the second process.

[0062] In this embodiment, after the broadcast receiver of the second process monitors the broadcast event information, it will parse the event information to obtain the parsed event identifier and process name, and obtain the event identifier and process name set on the second listening object, and then match the parsed event identifier and process name with the event identifier and process name set on the second listening object. If at least one of the event identifier and the process name fails to match, the target event is not subscribed by the second process. If both the event identifier and the process name match successfully, the target event is subscribed by the second process. At this time, the broadcast receiver will receive the event information and pass it to the second listening object. In this way, it first judges whether the target event is subscribed by the second process, and then determines whether to pass it to the second listening object, ensuring the reliability of the cross-process transmission of event information.

[0063] It should be understood that the same event may occur in different processes. Therefore, the event information not only includes the event identifier, but also carries the process name, thus avoiding the problem of incorrect cross-process transmission of event information caused by the same event that may occur in different processes.

[0064] In another possible embodiment, after the broadcast receiver of the second process monitors the broadcast event information, it will parse the event information. After obtaining the parsed event identifier and process name, it can call the listener object management class to obtain the second listener object corresponding to the process name and event identifier from the listener object set of the second process, so as to pass the event information to the second listener object.

[0065] In one embodiment, the listener object generation class further includes a publishing function; after generating event information in the first listener object, it further includes: calling the listener object generation class to execute the publishing function, and publishing the event information through the first listener object, so that the first observer registered on the first listener object receives the event information.

[0066] In this embodiment, the first process acts as the publishing process. After the event value on the first listener object corresponding to the target event is reset, it will also use the publishing function of the event bus mechanism to achieve in-process propagation of the target event. At this time, the first observer registered on the first listener object can also receive the event information, realizing the cross-process event transmission mechanism in a lightweight manner while retaining the in-process event transmission ability, and realizing the information publishing and subscription of the target event within the process.

[0067] Furthermore, the listener object management class further includes a listener object removal function. The listener object removal function is used to remove the listener object from the listener object set. The cross-process event bus framework further includes a garbage collection mechanism, enabling the cross-process event bus framework to have the ability to perceive the life cycle and effectively avoiding the occurrence of memory leakage problems. That is, after the first listener object in the first process is received by the second process and the first observer, it further includes: monitoring the number of first observers on the first listener object and the number of second processes; determining the removal method of the second listener object according to the subscription method of the target event; if the subscription method is a persistent subscription method, when the number of first observers and the number of second processes reach the preset number threshold, in response to the listener object removal operation, call the listener object management class to execute the listener object removal function and remove the first listener object from the listener object set of the first process; if the subscription method is a non-persistent subscription method, when the number of first observers and the number of second processes reach the preset number threshold, directly trigger the garbage collection mechanism to remove the first listener object from the listener object set of the first process. In this way, it can effectively avoid the problem of mistakenly deleting the first listener object corresponding to the persistently subscribed event due to reasons such as memory requirements, and can directly remove the first listener object after there are no observers and second processes on the first listener object when the target event is a non-persistent subscription method, effectively avoiding additional memory consumption, thereby improving the quality of cross-process communication.

[0068] Step S230, when the target event is subscribed by the second process, use a broadcast receiver to send the event information to the second listening object, completing the cross-process transmission of the event information.

[0069] In this embodiment, if the broadcast receiver determines that the target event it monitors is subscribed by the second process, it receives the event information and sends the event information to the second listening object.

[0070] Specifically, the event information includes an event identifier, an event value, and a process name. After parsing the event information, the broadcast receiver can only pass the event value to the second listening object so that the second listening object is aware of the change of the target event.

[0071] In a possible embodiment, the broadcast receiver passes the event information as a whole to the second listening object. After receiving the event information, the second listening object can compare the event identifier and process name in the event information with its own set identifier attribute and process name to double-check the accuracy of the event information transmission.

[0072] In an embodiment, after using the broadcast receiver to send the event information to the second listening object, it further includes: calling a listening object generation class to execute a publishing function, and publishing the event information through the second listening object so that the second observer registered on the second listening object receives the event information.

[0073] In this embodiment, the second process serves as the receiving process. After the second listening object corresponding to the target event receives the event information, it resets the subsequent value based on the event value in the event information, and uses the publishing function of the event bus mechanism to notify the second observer registered on the second listening object, so that the components in the second process that are concerned about the target event can perform other operations according to the event value, realizing the cross-process event transmission mechanism in a lightweight manner.

[0074] In an embodiment, the listening object management class further includes a listening object removal function. The listening object removal function is used to remove the listening object from the listening object set. The cross-process event bus framework further includes a garbage collection mechanism, enabling the cross-process event bus framework to have life cycle awareness and effectively avoiding the occurrence of memory leakage problems. That is, after completing the cross-process transmission of the event information, it further includes: monitoring the number of second observers on the second listening object; determining the removal method of the second listening object according to the subscription method of the target event; if the subscription method is a persistent subscription method, when the number reaches a preset number threshold, in response to the listening object removal operation, call the listening object management class to execute the listening object removal function and remove the second listening object; if the subscription method is a non-persistent subscription method, when the number reaches a preset number threshold, trigger the garbage collection mechanism to clear the second listening object.

[0075] In this embodiment, if the subscription method of the target event is a persistent subscription method, when there is no second observer on the second listening object, in response to the listening object removal operation, the listening object management class is called to execute the listening object removal function, and the second listening object is removed from the listening object set of the second process. If the subscription method of the target event is a non-persistent subscription method, when there is no second observer on the second listening object, the garbage collection mechanism is directly triggered to remove the second listening object from the listening object set of the second process. In this way, it can effectively avoid the problem of accidentally deleting the second listening object corresponding to the persistently subscribed event due to reasons such as memory requirements, and can directly remove the second listening object after there is no second observer on the second listening object when the target event is a non-persistent subscription method, effectively avoiding additional memory consumption, thereby improving the cross-process communication quality.

[0076] In a possible embodiment, the listening object set in the process includes a strong reference set and a weak reference set. The listening objects stored in the weak reference set are wrapped by weak references and can be removed by triggering the garbage collection mechanism. The listening objects stored in the strong reference set are wrapped by strong references and need to be removed based on the listening object removal operation. While effectively preventing memory leakage problems using weak reference technology, the reliability of inter-process communication under the cross-process event bus framework is ensured through strong reference technology.

[0077] In a possible embodiment, the listening object generation class includes an observer monitoring method. To determine whether there is an observer on the first listening object and the second listening object, that is, the observer quantity monitoring function is executed to monitor the number of observers on the listening object, and it is determined whether there is an observer on the listening object according to the number of observers. The observer quantity monitoring function can simultaneously monitor the number of observers on each listening object in the listening object set. In this way, reliable management of the listening object is achieved.

[0078] In a possible embodiment, the listening object generation class includes an observer removal function; before determining whether there is an observer on the listening object, it further includes: if the life cycle state of any observer has a life cycle, after the life cycle ends, the any observer is removed from the target listening object; if the life cycle state of any observer does not have a life cycle, in response to the observer removal operation, the listening object generation class is called to execute the observer removal function to remove the any observer from the target listening object. In this way, the persistent observer can be adaptively removed when it needs to be removed, which not only ensures the reliability of cross-process communication but also avoids unnecessary memory consumption.

[0079] In a possible embodiment, please refer to Figure 3 , Figure 3It is a schematic diagram of a cross - process event bus framework shown in an exemplary embodiment of the present application. As Figure 3 shown, in Android, in the observable data holding class (i.e., LiveData), there are event acquisition methods (getValue()), event value setting methods (setValue(T value)), event publishing methods (postValue(T value)), and observer monitoring methods (onInactive()). That is, it can monitor the changes of events, set the status values of events, perform information publishing, and monitor the observer status. MutableLiveData (i.e., the mutable real - time data class) is a subclass of LiveData. ProcMutableLiveData (i.e., the listener object generation class) is a subclass of MutableLiveData, including two attributes, namely the sticky subscription attribute (isSticky) and the identification attribute (keyForLiveDataBus), and including three functions. Among them, the sticky switch opening and closing function (hook(observer:Observer<in T>)) is used to implement the sticky switch of MutableLiveDataBus, so that events support sticky or non - sticky subscriptions, and the broadcast function (sendBroadcast(Value: <t>) for event broadcasting between processes, the post function (postValueWithoutBroadcastCast(value: <t>))For event publishing within a process, it also includes an observer registration function and an observer removal function (not shown in the figure). ProcLiveDataBus (i.e., the listener object management class) is a custom class, and ProcMutableLiveData is an inner class of this class, including a property, the listener object collection (map: Map<String, WeakReference<BusMutableLiveData<*>>>), including three functions, namely the initialization function (init(Context)), the listener object creation function (with(key: String, isSticky: Boolean = false): MutableLiveData <t>)And the monitoring object removal function (remove(key: String): MutableLiveData <t>),(wherein, the initialization function can register ProcBroadcastReceiver (i.e., register a broadcast receiver) to listen for object creation, and the listening object creation function can create a listening object (i.e., ProcBusMutableLiveData object). The BroadcastReceiver (i.e., the broadcast event handling class) includes a broadcast receiving function (onReceive(Context, Intent)) for receiving and handling broadcast events.)

[0080] Please refer to Figure 4 , Figure 4 is a flowchart of a specific cross-process communication method shown in an exemplary embodiment of the present application. As Figure 4 shown, Process A is any publishing process, and Process B is any receiving process. The specific cross-process communication method is described in detail as follows:

[0081] 1. In the process of starting Process B, call the initialization function init of the listening object management class ProcLiveDataBus to register a broadcast receiver in Process B for receiving and handling broadcast events;

[0082] 2. In Process B, use the listening object management class ProcLiveDataBus to subscribe to events in Process A. This operation will use the listening object creation function with of the listening object management class ProcLiveDataBus and the event identifier key to create a ProcBusMutableLiveData object in Process B, and register an observer on the ProcBusMutableLiveData object through the observer registration function of the listening object generation class ProcBusMutableLiveData.

[0083] 3. In Process A, where the event changes, use the listening object creation function with of the ProcLiveDataBus of the listening object management class and the event identifier key to create a ProcBusMutableLiveData object corresponding to Process A, and then use this object to send the event. When this operation is first performed in Process A, a ProcBusMutableLiveData object will be first created in Process A and saved in the Map collection with the event identifier as the key. When the event is sent again, the object will be directly obtained from the Map collection through this key of the event identifier).

[0084] 4. In process A, call the send function of the broadcast function of the ProcBusMutableLiveData class generated by the listening object. This operation will broadcast the event information through the system to achieve cross-process propagation. At the same time, it will also use the post function of the publishing function of the ProcBusMutableLiveData class generated by the listening object to achieve in-process propagation of the event.

[0085] 5. In process B, since a broadcast receiver for receiving event broadcasts was registered in step 1, it can receive the event broadcast sent from process A. The broadcast receiver parses the event information passed in the broadcast, finds the corresponding ProcBusMutableLiveData object in process B through the event identifier, and uses this object to continue propagating the event information within process B to notify the observers registered on the ProcBusMutableLiveData object in process B.

[0086] For example, in an Android in-vehicle system, there is a virtual image of a voice assistant. This image can display different actions according to the different states of the system music playback. For example, when the music is playing, the image will show that it is enjoying the music. When the music is paused, the image will stop the action of enjoying the music and change to a normal state. Since this image is a virtual image of the voice assistant, it is in the voice process, while the music is in another separate process. Due to the process isolation feature of the Android system, the voice process cannot directly obtain the music playback state of the music process. To meet the requirement for the voice process to perceive the music playback state of the music process, the cross-process event bus framework of this case is used. In this example, the music playback state is an event, and playing and pausing are different values of the event.

[0087] Please refer to Figure 5 , Figure 5 which is a flowchart showing the communication between the voice process and the music process illustrated in an exemplary embodiment of the present application. As Figure 5 shown, the cross-process communication between the voice process and the music process is described in detail as follows:

[0088] 1. In the process of starting the voice process, call the init function of the initialization function of ProcLiveDataBus to register a broadcast receiver in the voice process for receiving event broadcasts.

[0089] 2. In the voice process, use ProcLiveDataBus to subscribe to the music playback state event: ProcLiveDataBus.with <string>("EVENT_PLAY_STATE").observe(play state observer), this operation creates a ProcBusMutableLiveData object in the voice process and saves it in a Map collection with the key "EVENT_PLAY_STATE". The ProcBusMutableLiveData object is registered with the play state observer.

[0090] 3. In the music process, where the music play state changes, use ProcLiveDataBus to obtain the corresponding music play state event, and then use the ProcBusMutableLiveData object corresponding to the music play event in the music process to send out the music play state: ProcLiveDataBus.with <string>("EVENT_PLAY_STATE").send("PLAYING"). When this operation is first performed in the music process, a ProcBusMutableLiveData object will be created in the music process first, and this object will be saved to the Map collection with "EVENT_PLAY_STATE" as the key. When the music play state is sent again, the object will be directly retrieved from the Map collection through the key "EVENT_PLAY_STATE".

[0091] 4. In the music process, call the send method of the ProcBusMutableLiveData object. This operation will send the event information (event identifier "EVENT_PLAY_STATE", event value "PLAYING") and the process name "com.example.music" through an Android system broadcast to achieve cross-process propagation. At the same time, it will also use the publishing function of the listener object generation class object to achieve in-process propagation of the event.

[0092] 5. In the voice process, since a broadcast receiver for receiving event broadcasts is registered in 1, it can receive the event broadcast sent from the music process, parse the event identifier "EVENT_PLAY_STATE" passed in the broadcast, find the corresponding ProcBusMutableLiveData object in the voice process, and use the post method of this object to continue passing the event in the voice process to notify the play state observers registered on the ProcBusMutableLiveData object.

[0093] 6. The play state observer in the voice process obtains the music play state and uses it to update the actions of the voice image. Thus, cross-process propagation of the play state event is achieved.

[0094] The above cross-process communication method first constructs a listening component through a cross-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process. Cross-process communication occurs between the first process and the second process. Then, when it is detected that a target event changes in the first process, the first listening object is used to broadcast the event information of the target event to the broadcast receiver to achieve the publication of the target event. The broadcast receiver will determine whether the target event is subscribed to by the second process based on the received event information. If it is subscribed to by the second process, the broadcast receiver will send the event information to the second listening object to achieve the reception of the event information of the second process. Combining the cross-process event bus framework and the broadcast mechanism, listening objects and broadcast receivers for cross-process communication are directly created through the cross-process event bus framework. Event message publication and reception are achieved through the respective listening objects between two processes and the broadcast receiver of the receiving process, without introducing a third-party library, reducing the dependency complexity of the project, decreasing the volume of the project, and improving the compatibility of the project, realizing a lightweight, efficient, and easily integrated cross-process event bus framework, and implementing a cross-process event transmission mechanism in a lightweight manner.

[0095] Please refer to Figure 6 , Figure 6 which is a block diagram of a cross-process communication system shown in an exemplary embodiment of the present application. This system can be applied to Figure 1 the implementation environment shown. It should be understood that this system can also be applicable to other exemplary implementation environments, and the implementation environment applicable to this system is not limited in this embodiment.

[0096] As Figure 6 shown, in an exemplary embodiment, the cross-process communication system 600 at least includes a construction module 610, an information publication module 620, and a cross-process communication module 630, which are introduced in detail as follows:

[0097] The construction module 610 is used to construct a listening component through a cross-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process. Cross-process communication occurs between the first process and the second process;

[0098] The information publication module 620 is used to, if it is detected that a target event changes in the first process, use the first listening object to broadcast the event information of the target event to the broadcast receiver, so that the broadcast receiver determines whether the target event is subscribed to by the second process based on the event information;

[0099] The cross-process communication module 630, when the target event is subscribed to by the second process, uses the broadcast receiver to send the event information to the second listening object to complete the cross-process transmission of the event information.

[0100] It should be noted that the cross-process communication system provided in the above embodiments and the cross-process communication method provided in the above embodiments belong to the same concept. The content of the operations performed by each module has been described in detail in the method embodiments, and will not be repeated here.

[0101] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of an in-vehicle terminal provided by an embodiment of the present application. Figure 7 shows a schematic structural diagram of a computer system of an in-vehicle terminal suitable for implementing the embodiments of the present application. It should be noted that Figure 7 the shown computer system 700 of the in-vehicle terminal is only an example, and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0102] As Figure 7 shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 702 or the program loaded from the storage section 708 into the random access memory (RAM) 703, such as executing the method in the above embodiments. In the RAM 703, various programs and data required for system operations are also stored. The CPU 701, ROM 702, and RAM 703 are connected to each other via a bus 704. The input / output (I / O) interface 705 is also connected to the bus 704.

[0103] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including, for example, a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed, so that a computer program read from it can be installed into the storage section 708 as needed.

[0104] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product that includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit (CPU) 701, various functions defined in the system of the present application are executed.

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. Among them, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the above-mentioned module, program segment, or part of code includes one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for executing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0106] The units described in the embodiments of the present application can be implemented in software or in hardware, and the described units can also be provided in a processor. Among them, the names of these units do not constitute a limitation to the unit itself in some cases.

[0107] The above embodiments are only used to exemplarily illustrate the principles and effects of the present application, rather than to limit the present application. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of the present application. Therefore, all equivalent modifications or changes completed by those with ordinary knowledge in the technical field without departing from the spirit and technical idea disclosed by the present application should still be covered by the claims of the present application.< / string> < / string> < / t> < / t> < / t> < / t>

Claims

1. A cross-process communication method, characterized in that, The method includes: Constructing a listening component through a cross-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process, for cross-process communication between the first process and the second process. Among them, the cross-process event bus framework includes a listening object management class. The constructing of the listening component through the cross-process event bus framework includes: calling the listening object management class, registering the broadcast receiver, and generating a first listening instance and a second listening instance; registering a first observer on the first listening instance to generate the first listening object; registering a second observer on the second listening instance to generate the second listening object; If it is monitored that the target event in the first process changes, then use the first listening object to broadcast the event information of the target event to the broadcast receiver, so that the broadcast receiver determines whether the target event is subscribed by the second process according to the event information; When the target event is subscribed by the second process, use the broadcast receiver to send the event information to the second listening object to complete the cross-process transmission of the event information.

2. The cross-process communication method according to claim 1, wherein The construction method of the cross-process event bus framework includes: Creating a listening object generation class, and setting the listening object script, the first attribute, and the first function of the listening object generation class. The first attribute includes the sticky subscription attribute and the identification attribute of the event, and the first function includes the observer registration function; Creating a listening object management class, and setting the second attribute and the second function of the listening object management class. The second attribute includes a listening object set for storing listening objects, and the second function includes an initialization function and a listening object creation function; Creating a broadcast event processing class, and setting the third function of the broadcast event processing class. The third function includes a broadcast receiving function to implement broadcast receiving according to the broadcast event processing class.

3. The cross-process communication method according to claim 2, wherein The constructing of the listening component through the cross-process event bus framework includes: Obtaining the process name of the first process, the business scenario and event identifier of the target event, the first observer identifier of the observer in the first process who pays attention to the target event, and the second observer identifier of the observer in the second process who pays attention to the target event; Calling the listening object management class, registering the broadcast receiver through the initialization function, and generating the first listening instance and the second listening instance of the target event through the listening object creation function; In response to the first listening instance, running the listening object script and executing the observer registration function, so as to set the sticky subscription attribute and the identification attribute of the first listening instance according to the business scenario and the event identifier, and registering a first observer on the first listening instance according to the first observer identifier to generate the first listening object; In response to the second listening instance, run the listening object script and execute the observer registration function to set the sticky subscription attribute and identification attribute of the second listening instance according to the service scenario and the event identifier, set the process name on the second listening instance, and register a second observer on the second listening instance according to the second observer identifier to generate the second listening object.

4. The cross-process communication method according to claim 1, wherein The cross-process event bus framework includes a listening object generation class and a broadcast event processing class. The listening object generation class includes a broadcast function, and the broadcast event processing class includes a broadcast receiving function. Using the first listening object to broadcast the event information of the target event to the broadcast receiver includes: Reset the event value of the target event based on the change of the target event. Generate the event information in the first listening object according to the event value, the event identifier of the target event, and the process name of the first process. Call the listening object generation class to execute the broadcast function and broadcast the event information. In response to the broadcast event, trigger the broadcast receiving function to enable the broadcast receiver to receive the event information.

5. The cross-process communication method according to claim 4, wherein, The broadcast receiver determines whether the target event is subscribed by the second process according to the event information, including: Parse the event information to obtain the parsed event identifier and process name. Match the parsed event identifier and process name with the event identifier and process name set on the second listening object respectively. If the event identifier and / or the process name do not match, it is determined that the target event is not subscribed by the second process. If both the event identifier and the process name match successfully, it is determined that the target event is subscribed by the second process.

6. The cross-process communication method according to claim 4, wherein The listening object generation class further includes a publishing function. After generating the event information in the first listening object, it further includes: Call the listening object generation class to execute the publishing function, and publish the event information through the first listening object so that the first observer registered on the first listening object receives the event information.

7. The cross-process communication method according to claim 6, wherein After using the broadcast receiver to send the event information to the second listening object, it further includes: Call the listening object generation class to execute the publishing function, and publish the event information through the second listening object so that the second observer registered on the second listening object receives the event information.

8. The cross-process communication method according to claim 7, wherein The cross-process event bus framework includes a listening object management class and a garbage collection mechanism. The listening object management class includes a listening object removal function. After completing the cross-process transfer of the event information, it further includes: Monitor the number of the second observers on the second listening object. Determine the removal method of the second listening object according to the subscription method of the target event. If the subscription method is a persistent subscription method, when the number reaches a preset number threshold, in response to the listening object removal operation, call the listening object management class to execute the listening object removal function and remove the second listening object. If the subscription method is a non-persistent subscription method, when the quantity reaches a preset quantity threshold, the garbage collection mechanism is triggered to clear the second listening object.

9. A cross-process communication system, characterized in that, The system includes: A construction module, configured to construct a listening component through a cross-process event bus framework. The listening component includes a first listening object corresponding to a first process, a second listening object corresponding to a second process, and a broadcast receiver corresponding to the second process. The first process and the second process perform cross-process communication. Among them, the cross-process event bus framework includes a listening object management class. The construction of the listening component through the cross-process event bus framework includes: calling the listening object management class, registering the broadcast receiver, and generating a first listening instance and a second listening instance; registering a first observer on the first listening instance to generate the first listening object; registering a second observer on the second listening instance to generate the second listening object; An information publishing module, configured to, if it is detected that a target event in the first process changes, use the first listening object to broadcast the event information of the target event to the broadcast receiver, so that the broadcast receiver determines whether the target event is subscribed by the second process according to the event information; A cross-process communication module, when the target event is subscribed by the second process, uses the broadcast receiver to send the event information to the second listening object to complete the cross-process transmission of the event information.

10. A vehicle-mounted terminal, characterized in that, Includes: One or more processors; A storage device, configured to store one or more programs, and when the one or more programs are executed by the one or more processors, enable the vehicle-mounted terminal to implement the cross-process communication method according to any one of claims 1 to 8.

Images