In-Process Communication Method, System, Vehicle Terminal, and Storage Medium

Abstract

The present application provides an in-process communication method, system, vehicle-mounted terminal, and storage medium. The method includes: creating a set of listening objects through an in-process event bus framework, where each listening object in the set of listening objects corresponds to an event, and at least one observer corresponding to the event is registered on each listening object; if it is detected that the state of a target event in the process changes, obtaining the target listening object in the set of listening objects according to the target event; based on the state change of the target event, resetting the state value of the target event in the listening object and publishing it, and determining whether there is an observer on the target listening object after publishing; when there is no observer on the target listening object, removing the target listening object. By creating listening objects for in-process events through an in-process event bus framework and formulating a listening object cleaning mechanism, a simple and efficient communication mechanism between components in the process is realized without introducing a third-party library.

Description

Technical Field

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

[0002] With the continuous development of mobile applications, the in-process communication requirements of Android applications have been increasing. To meet this requirement, developers usually adopt an in-process event bus mechanism to implement data transmission and event response, improving the decoupling degree and maintainability of software. Existing Android in-process event bus frameworks usually rely on third-party libraries such as RxJava (Reactive Extensions for Java) and EventBus, and implement an efficient event transmission mechanism through the observer pattern, greatly simplifying the programming work of developers.

[0003] However, although this framework provides powerful functions, the introduction of third-party libraries also brings 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, affecting 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: When implementing sticky events in third-party libraries, 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 implement communication between components in the process through a lighter, more efficient, and easier-to-integrate in-process event bus mechanism. Summary of the Invention

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

[0005] In a first aspect, this application provides an in-process communication method, the method includes: creating a set of listening objects through an in-process event bus framework, each listening object in the set of listening objects corresponds to an event, and at least one observer corresponding to the event is registered on each of the listening objects; if it is detected that the state of a target event in the process changes, obtaining a target listening object in the set of listening objects according to the target event; based on the state change of the target event, resetting the state value of the target event in the listening object and publishing it, and determining whether there is an observer on the target listening object after publishing; when there is no observer on the target listening object, removing the target listening object.

[0006] In an embodiment of the present application, the construction method of the in-process event bus framework includes: creating a listener object generation class according to an observable data holding class and a mutable real-time data class, and setting a listener object script, a first attribute, and a first function of the listener object generation class, where the first attribute includes a sticky subscription attribute and an identification attribute of an event, and the first function includes an observer registration function and an observer removal function; customizing a listener object management class and setting a second attribute and a second function of the listener object management class, where the listener object management class is used to manage each listener object, the second attribute includes a weak reference set for storing each listener object and a strong reference set for storing listener objects that need to be persistently subscribed, and the second function includes a listener object creation function and a listener object removal function.

[0007] In an embodiment of the present application, creating a listener object set through the in-process event bus framework includes: obtaining the business scenario and event identifier of each event, as well as the observer identifier and life cycle state of all observers corresponding to each event; calling the listener object management class, and generating a listener instance for each event through the listener object creation function; in response to each listener instance, running the listener object script and executing the observer registration function to set the sticky subscription attribute and the identification attribute of each listener instance according to the business scenario and the event identifier of each event, and registering an observer on each listener instance according to the observer identifier to generate a plurality of listener objects; storing the plurality of listener objects into the weak reference set, and determining whether the subscription method of each listener object is a persistent subscription method according to the life cycle states of all observers. If so, storing the corresponding listener object into the strong reference set to complete the creation of the listener object set.

[0008] In an embodiment of the present application, the in-process event bus framework includes a listener object management class, and the listener object management class includes a listener object removal function; removing the target listener object includes: determining whether the subscription method of the target listener object is a persistent subscription method according to the life cycle states of all observers on the target listener object; if so, after all observers are removed, in response to a listener object removal operation, calling the listener object management class and executing the listener object removal function to remove the target listener object; if not, after all observers are removed, clearing the target listener object.

[0009] In an embodiment of the present application, the in-process event bus framework includes a listener object generation class, and the listener object generation class includes an observer removal function; before determining whether the observer exists on the target listener object after publication, it further includes: if the life cycle status of any observer has a life cycle, after the end of the life cycle, removing the any observer from the target listener object; if the life cycle status of any observer does not have a life cycle, in response to an observer removal operation, calling the listener object generation class to execute the observer removal function and removing the any observer from the target listener object.

[0010] In an embodiment of the present application, determining whether the observer exists on the target listener object after publication includes: defining an observer number monitoring function in the observer removal function; executing the observer number monitoring function to monitor the number of observers on the target listener object; and determining whether the observer exists on the target listener object according to the number of observers.

[0011] In an embodiment of the present application, before obtaining the target listener object in the listener object set according to the target event, it further includes: matching the listener object in the listener object set according to the event identifier of the target listener event; if the matching fails, creating a listener object corresponding to the target listener event according to the in-process event bus framework and storing it in the listener object set.

[0012] In a second aspect, the present application provides an in-process communication system, which includes: a creation module for creating a listener object set through an in-process event bus framework, where each listener object in the listener object set corresponds to an event, and at least one observer corresponding to the event is registered on each listener object; a monitoring module for obtaining the target listener object in the listener object set according to the target event if it is detected that the status of the in-process target event changes; an interaction module for resetting the status value of the target event in the listener object and publishing it based on the status change of the target event, and determining whether the observer exists on the target listener object after publication; and a removal module for removing the target listener object when the observer does not exist on the target listener object.

[0013] 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, enabling the vehicle-mounted terminal to implement the in-process communication method described in the first aspect.

[0014] Fourthly, the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor of a computer, the computer is enabled to execute the in-process communication method described in the first aspect.

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

[0016] Firstly, a set of listening objects is created through an in-process event bus framework. Each listening object in the set of listening objects corresponds to an event, and at least one observer corresponding to the event is registered on each listening object. When it is detected that the state of a target event in the process changes, the target listening object in the set of listening objects is obtained according to the target event. Then, based on the state change of the target event, the state value of the target event in the listening object is reset and published to notify the observers on the target listening object. Next, it is determined whether there are still observers on the target listening object after publication, and when there are no observers on the target listening object, the target listening object is removed. The listening objects of in-process events are created through the in-process event bus framework, and the message publishing of the publisher and the information subscription of the subscriber are realized through the listening objects. There is no need to introduce a third-party library, which reduces the dependency complexity of the project, reduces the volume of the project, and improves the compatibility of the project, realizes a lightweight in-process event bus framework, and formulates a listening object cleaning mechanism to avoid unnecessary memory occupation. Without introducing a third-party library, a simple and efficient communication mechanism between components in the process is realized through a lighter, more efficient and easier-to-integrate in-process event bus mechanism.

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

[0018] The drawings here are incorporated into the specification and constitute a part of this specification, showing the 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 the implementation environment of an in-process communication system shown in an exemplary embodiment of the present application;

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

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

[0022] Figure 4 It is a block diagram of an in-process communication system shown in an exemplary embodiment of the present application;

[0023] Figure 5 It is a schematic structural diagram of an in-vehicle terminal provided by an embodiment of the present application. Detailed implementation manners

[0024] 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 illustrating the present application, rather than for limiting the protection scope of the present application.

[0025] 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 ratio of each component in its actual implementation can be arbitrarily changed, and the layout form of its components may also be more complex.

[0026] 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.

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

[0028] Jar package: It is 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.

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

[0030] Reference: In programming, it is a pointer or identifier that points to an object in memory. References are used to access and manipulate objects. In Java, all objects are manipulated through references, and references can be strong references, soft references, weak references, or phantom references.

[0031] Weak reference: It is a reference that allows the referenced object to be reclaimed by the garbage collector. In Java, the WeakReference class implements weak references. If an object has only weak references, it can be reclaimed when the garbage collector runs, regardless of whether there is enough memory.

[0032] Strong reference: It means that as long as the reference exists, the referenced object will not be reclaimed by the garbage collector.

[0033] Memory leak: It refers to the situation where objects that are no longer needed in a program are not reclaimed by the garbage collector and thus still occupy memory space. Memory leaks can cause an application to consume more and more memory over time, eventually possibly leading to a decline in program performance or even a crash. Common causes of memory leaks include long-lived objects holding references to short-lived objects.

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

[0035] Non-sticky subscription: It is a subscription model in which subscribers can only receive events published after they start listening. That is to say, if an event is published before a subscriber registers, the subscriber will not receive these events.

[0036] Hook: It 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.

[0037] Inner class: It means defining another class inside an outer class. The inner class exists as a member of the outer class and depends on the outer class.

[0038] First of all, it should be noted that in-process communication refers to the data exchange and information transfer between various parts (such as threads, modules, components, etc.) within a process; the event bus framework is an event publishing / subscribing structure that realizes decoupled communication between different components through the publish-subscribe mode, allowing different components to communicate by publishing and subscribing to events without directly depending on each other; the in-process event bus framework is an event processing framework based on the publish-subscribe mode, which allows communication and event processing between different components within the same process, and realizes an efficient event transfer mechanism through the observer mode.

[0039] However, through the research of the inventors of this application, it is found that although the in-process event bus framework greatly simplifies the programming work of developers, the current event transfer mechanism needs to rely on third-party libraries for implementation. Due to the introduction of third-party libraries, the following problems also arise. 1. Dependency complexity: The introduced third-party libraries increase the dependency complexity of the project; 2. Project volume increase: The introduction of third-party libraries may increase the volume 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: When implementing sticky events with 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 an in-process communication system shown in an exemplary embodiment of this application. As Figure 1 shown, the implementation environment includes a vehicle 110 and an in-process communication system 120. Among them, the in-process communication system 120 is embedded in the vehicle 110 and is used to implement in-process communication in the vehicle 110. The in-process communication system 120 includes, but is not limited to, a car machine system, an in-vehicle computer, etc. By creating a listening object for in-process events through the in-process event bus framework, the message publishing of the publisher and the information subscription of the subscriber are realized through the listening object, without introducing third-party libraries, reducing the dependency complexity of the project, reducing the volume of the project, and improving the compatibility of the project, realizing a lightweight in-process event bus framework, and formulating a listening object cleaning mechanism to avoid unnecessary memory occupation. Without introducing third-party libraries, a simple and efficient communication mechanism between components within the process is realized through a lighter, more efficient and easier-to-integrate in-process event bus mechanism.

[0041] Please refer to Figure 2 , Figure 2 which is a flowchart of an in-process communication method shown in an exemplary embodiment of this application. This method can be applied to Figure 1Regarding the described implementation environment, it should be understood that this method can also be applicable to other exemplary implementation environments, and the implementation environment applicable to this method is not restricted in this embodiment. Additionally, in the embodiments of this application, this in-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, in-vehicle terminals, etc.

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

[0043] Step S210, create a set of listener objects through the in-process event bus framework. Each listener object in the set of listener objects corresponds to an event, and at least one observer corresponding to the event is registered on each listener object.

[0044] It should be noted that the listener object corresponding to each event is used to monitor event changes to achieve information publishing by the publisher, and to register observers in the process who are concerned about the event changes, so as to notify the event changes to the observers and achieve information subscription by the subscribers (i.e., observers). In this way, without introducing any other third-party libraries, Jar packages, or SDKs, in-process communication is achieved through the listener objects.

[0045] In one embodiment, the construction method of the in-process event bus framework includes: creating a listener object generation class according to the observable data holding class and the mutable real-time data 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 and the observer removal function; customizing a listener object management class, and setting the second attribute and the second function of the listener object management class. Among them, the listener object management class is used to manage each listener object. The second attribute includes a weak reference set for storing each listener object and a strong reference set for storing listener objects that require persistent subscription. The second function includes a listener object creation function and a listener object removal function.

[0046] 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 observer removal function is used to remove the observer from 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, it includes a weak reference set storing all listener objects and a strong reference set storing listener objects that need persistent subscription, wrapping the listener objects with weak references or strong references. Among the second functions set, the listener object creation function is used to create listener objects, and the listener object removal function is used to remove listener objects from the weak reference set and / or the strong reference set.

[0047] In this embodiment, the in-process event bus framework is constructed, that is, the listener object generation class and the listener object management class, implementing a lightweight in-process event bus framework, and realizing simple and efficient communication between in-process components by using the way of generating and managing listener objects by the listener object generation class and the listener object management class.

[0048] It should be noted that the sticky subscription attribute of the corresponding event set on the listener object is set according to the business scenario. If the subscriber needs to receive the previous information even if they register after the information is published, the sticky subscription attribute is turned on; if the subscriber 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 and non-sticky subscriptions, simplifies the implementation of sticky events, and can meet the needs of sticky / non-sticky subscription methods in different in-process communications while realizing in-process component communication. In addition, based on sticky subscription and non-sticky subscription, the observers registered on each listener object can be registered after the event changes or before the event changes, and moreover, based on the attention requirements of the observers for event changes, the observers registered on the listener object can be dynamically changed.

[0049] It also should be noted that there is a garbage collection mechanism in the in-process event bus framework, which will remove the listener objects without observers from the listener object set. In order to avoid the problem of removing the listener objects corresponding to the persistently subscribed events when there are no observers, these types of listener objects are stored in the strong reference set and wrapped with strong references. In this way, while effectively preventing memory leakage problems by using weak reference technology, the reliability of component communication under the in-process event bus framework is ensured by using strong reference technology.

[0050] In a possible embodiment, see Figure 3 , Figure 3 is a schematic diagram of an in-process event bus framework shown in an exemplary embodiment of the present application. As Figure 3 shown, in Android, the observable data holding class (i.e., LiveData) is provided with an event change acquisition method (getValue()), an event status value setting method (setValue(T value)), a publishing method (postValue(T value)), and an observer monitoring method (onInactive()), that is, it can monitor the change of events, set the status value of events, publish information, and monitor the status of observers. MutableLiveData (i.e., the mutable real-time data class) is a subclass of LiveData. BusMutableLiveData (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), including two functions (not shown in the figure), namely the observer registration function and the observer removal function. In addition, it also includes a sticky switch opening and closing function (hook(observer:Observer<in T>)) for implementing the sticky switch of MutableLiveDataBus, so that events support sticky or non-sticky subscriptions. LiveDataBus (i.e., the listener object management class) is a custom class, and BusMutableLiveData is an inner class of this class, including two attributes, namely the weak reference set (map:Map<String,WeakReference<BusMutableLiveData<*>>>) and the strong reference set (keepMap:Map<String,BusMutableLiveData<*>>), including two functions, namely the listener object creation function (with(key:String,isSticky:Boolean=false):MutableLiveData <t>) and the monitoring object removal function (remove(key: String): MutableLiveData <t>)。

[0051] As a possible embodiment, the BusMutableLiveData class is created. The constructor of this class receives two parameters, namely isSticky of boolean type (used to mark whether sticky is enabled) and keyForLiveDataBus of String type (used to save the name of the event), and overrides the onInactive function (observer monitoring method) of the MutableLiveData class. This function will be system-callbacked when the number of active observers of MutableLiveData becomes 0. In this function, check the number of observers of the BusMutableLiveData object (i.e., the listening object). If there are no observers, remove the listening object from the Map collection to prevent memory leaks. The created LiveDataBus class has two Map collection objects internally, which are used to manage and obtain BusMutableLiveData objects. Among them, the BusMutableLiveData objects subscribed by the observe method are referenced using the WeakReference weak reference method to prevent memory leaks, while the BusMutableLiveData objects subscribed by the observerForever method are managed using a strong reference Map to prevent bugs caused by the BusMutableLiveData object being reclaimed by memory. LiveDataBus contains two functions, corresponding to two functions, namely the with function (used to obtain or create BusMutableLiveData according to the event key) and the remove function (used to remove the corresponding BusMutableLiveData from the Map collection according to the event key). Among them, the event key is the event identifier, such as name, number, etc.

[0052] In one embodiment, a collection of listening objects is created through an in-process event bus framework, including: obtaining the business scenario and event identifier of each event, as well as the observer identifier and lifecycle state of all observers corresponding to each event; calling a listening object management class to generate a listening instance for each event through the listening object creation function; in response to each listening instance, running a listening object script and executing an observer registration function, and setting the sticky subscription attribute and identifier attribute of each listening instance according to the business scenario and event identifier of each event, and registering an observer on each listening instance according to the observer identifier to generate multiple listening objects; storing the multiple listening objects into a weak reference collection, and determining whether the subscription method of each listening object is a persistent subscription method according to the lifecycle state of all observers. If so, store the corresponding listening object into a strong reference collection to complete the creation of the collection of listening objects.

[0053] In this embodiment, one event in the process corresponds to one listening object. Each listening object sets sticky subscription attributes and identification attributes according to the business scenario and event identifier of the event, and registers an observer according to the observer identifier, thereby generating a listening object. For multiple listening objects in the process, they are all stored in a weak reference set, and the listening objects corresponding to the events that need to be persistently subscribed are stored in a strong reference set, thus completing the creation of the listening object set. In this way, the sticky subscription attribute on the listening object enables the event to support sticky or non-sticky subscription, and the identification attribute enables the events in the process to be correspondingly subscribed and published. The combination of strong reference and weak reference effectively prevents memory leakage problems while ensuring the reliability of communication between components under the event bus framework in the process.

[0054] Step S220: If it is detected that the state of the target event in the process has changed, obtain the target listening object from the listening object set according to the target event.

[0055] In this embodiment, when the state of the target event changes, it is necessary for the listening object corresponding to the target event to implement information publication and subscription. Therefore, the target listening object is obtained from the listening object set according to the target event. Specifically, the event identifier of the target event can be used as the key to match the identification attribute of each listening object in the listening object set, so as to obtain the target listening object.

[0056] In one embodiment, before obtaining the target listening object from the listening object set according to the target event, it further includes: matching the listening object in the listening object set according to the event identifier of the target listening event; if the matching fails, create a listening object corresponding to the target listening event according to the event bus framework in the process and store it in the listening object set.

[0057] In this embodiment, considering the situation that there is no listening object corresponding to the target event in the listening object set, the target listening object cannot be directly obtained from this set. Therefore, a listening object corresponding to the target listening event is newly created according to the event bus framework in the process and saved in the listening object set. In this way, it can be directly obtained next time. In addition, the creation method of the listening object here is the same as the creation method of each listening object in the above listening object set, which will not be elaborated here.

[0058] Step S230: Based on the state change of the target event, reset the state value of the target event in the listening object and publish it, and determine whether there is an observer on the target listening object after the publication.

[0059] It should be noted that resetting the status value of the target event in the reset monitoring object, that is, realizing the information publishing of the target event. After the status value changes, the observers on the target monitoring object can receive the reset status value, realizing the information subscription of the target event.

[0060] In this embodiment, after the information is published, some observers will be removed from the target monitoring object based on their own lifecycle status. Therefore, it is necessary to dynamically determine whether there are observers on the target monitoring object, and when there are none, remove the target monitoring object. In this way, the space memory can be effectively saved.

[0061] For example, when the mode of an in-process interface component changes, such as from the daytime mode to the nighttime mode, the monitoring object corresponding to the interface mode event changes the status value of the interface mode according to this change, such as changing from 1 (indicating the daytime mode) to 2 (indicating the nighttime mode). After the status value is reset, the observers on this monitoring object, that is, the components in the process that pay attention to the interface mode event, can know the change of the interface mode through the corresponding monitoring object.

[0062] Step S240, when there are no observers on the target monitoring object, remove the target monitoring object.

[0063] In this embodiment, if there are no observers on the target monitoring object, the target monitoring object is removed to save space memory, thereby improving the in-process communication quality. If there are still observers on the target monitoring object, the target monitoring object is kept to continue realizing the in-process communication.

[0064] It should be noted that when the target monitoring object is removed, its weak reference or strong reference mechanism is also cleared.

[0065] In one embodiment, determining whether there are observers on the target monitoring object after publishing includes: defining an observer number monitoring function in the observer removal function; executing the observer number monitoring function to monitor the number of observers on the target monitoring object; and determining whether there are observers on the target monitoring object according to the number of observers.

[0066] In this embodiment, by defining an observer number monitoring function, the number of observers on the target monitoring object is monitored in real time, so as to determine whether there are observers on the target monitoring object. In this way, the timely and effective monitoring of the number of observers is realized, and the reliability of removing the target monitoring object is further improved.

[0067] In one possible embodiment, the observer number monitoring function can simultaneously monitor the number of observers on each monitoring object in the monitoring object set. In this way, the reliable management of the monitoring object is realized.

[0068] In one embodiment, the in-process event bus framework includes a listener object generation class, and the listener object generation class includes an observer removal function; before determining whether there is an observer on the target listener object after publication, it further includes: if there is a lifecycle for the lifecycle state of any observer, after the lifecycle ends, remove any observer from the target listener object; if there is no lifecycle for the lifecycle state of any observer, in response to the observer removal operation, call the listener object generation class and execute the observer removal function to remove any observer from the target listener object.

[0069] In this embodiment, for the observers registered on the target listener object, if the lifecycle state of the observer has a lifecycle, it indicates that after the lifecycle ends, there is no need to pay attention to the events corresponding to the target listener object. Therefore, after the lifecycle ends, remove the observer from the target listener object, thus reducing the memory consumption of the target listener object to dynamically ensure the communication quality; if the lifecycle state of the observer has no lifecycle, it indicates that the observer is in a state of continuously paying attention to the events corresponding to the target listener object. In this case, when the removal operation of the observer is triggered, call the listener object generation class and execute its observer removal function to remove the observer from the target listener object. If there is no removal operation, no removal is performed. In this way, the persistent observer can be adaptively removed when needed, which not only ensures the reliability of in-process communication but also avoids unnecessary memory consumption.

[0070] In one embodiment, the in-process event bus framework includes a listener object management class, and the listener object management class includes a listener object removal function; removing the target listener object includes: according to the lifecycle states of all observers on the target listener object, determining whether the subscription method of the target listener object is a persistent subscription method; if so, after all observers are removed, in response to the listener object removal operation, call the listener object management class and execute the listener object removal function to remove the target listener object; if not, after all observers are removed, clear the target listener object.

[0071] In this embodiment, the life cycle states of the observers include the existing life cycle and the non-existing life cycle. If all the observers on a target listening object have a non-existing life cycle, the subscription method for the event corresponding to the target listening object is the persistent subscription method. Even after all the observers are removed, it is necessary to trigger the listening object removal operation and then call the listening object management class to execute the listening object removal function to remove the target listening object. In this way, it can effectively avoid the problem of accidentally deleting the listening object corresponding to the persistently subscribed event due to reasons such as memory requirements. If all the observers on a target listening object have an existing life cycle, the event corresponding to the target listening object is the non-persistent subscription method, and the target listening object is directly cleared after all the observers are removed. In this way, it can effectively avoid unnecessary memory consumption.

[0072] For example, in a process of Android, Component A needs to send a message to Component B, but Component A does not hold a reference to Component B, so it cannot directly communicate with Component B through the reference of Component A. At this time, the implementation of the publication and subscription of information between Component A and Component B is as follows:

[0073] 1. Subscribe to the message event of Component A in Component B through LiveDataBus;

[0074] If Component B is not an Android LifyCycleOwner (a component with a life cycle), then use LiveDataBus.with <string>("MESSAGE_KEY").observeForever(Observer) creates a listening object for message subscription; if component B is an Android LifecycleOwner, then use LiveDataBus.with <string>("MESSAGE_KEY").observe(observer) creates a listener object for message subscription. At this time, the in-process event bus framework will automatically cancel the subscription to this event when the lifecycle of Component B ends, and recycle the event BusMutableLiveData object when there are no observers for this event).

[0075] 2. Send a message in Component A: LiveDataBus.with <string>("MESSAGE_KEY").postValue("Im the message!”), which is published through the BusMutableLiveData object and notified to each observer.

[0076] 3. The observer of Component B will be called back and receive the message with the content "Im the message";

[0077] If the observerForever method is used for subscription, when it is no longer needed, use BusMutableLiveData.onInactive to remove the "observer"; if the observer method is used for subscription, the in-process event bus framework will automatically remove the observer and recycle the corresponding memory.

[0078] 4. Determine whether the BusMutableLiveData object is removed and the removal method of the BusMutableLiveData object according to the number of observers on the BusMutableLiveData object and the subscription method of the message event of Component A.

[0079] The above in-process communication method first creates a set of listening objects through the in-process event bus framework. Each listening object in the set of listening objects corresponds to an event, and at least one observer corresponding to the event is registered on each listening object. When it is detected that the state of the target event in the process changes, the target listening object in the set of listening objects is obtained according to the target event, and then based on the state change of the target event, the state value of the target event in the listening object is reset and published to notify the observers on the target listening object. Then, it is determined whether there are still observers on the target listening object after the publication, and when there are no observers on the target listening object, the target listening object is removed. The in-process event bus framework is used to create the listening objects of the in-process events, and the listening objects are used to implement the message publication of the publisher and the information subscription of the subscriber. There is no need to introduce a third-party library, which reduces the dependency complexity of the project, reduces the volume of the project, and improves the compatibility of the project. A lightweight in-process event bus framework is implemented, and a listening object cleaning mechanism is formulated to avoid unnecessary memory occupation. Without introducing a third-party library, a simple and efficient communication mechanism between components in the process is realized through a lighter, more efficient and easier-to-integrate in-process event bus mechanism.

[0080] Please refer to Figure 4 , Figure 4 which is a block diagram of an ECU access system based on a command line shown in an exemplary embodiment of the present application. This system can be applied to Figure 1 Regarding the illustrated implementation environment, it should be understood that the system can also be applicable to other exemplary implementation environments, and the implementation environment applicable to the system is not limited in this embodiment.

[0081] As Figure 4 shown, in an exemplary embodiment, the in-process communication system 400 includes at least a creation module 410, a monitoring module 420, an interaction module 430, and a removal module 440, which are introduced in detail as follows:

[0082] The creation module 410 is used to create a set of listening objects through the in-process event bus framework. Each listening object in the set of listening objects corresponds to an event, and at least one observer corresponding to the event is registered on each listening object;

[0083] The monitoring module 420 is used to, if it monitors that the state of the in-process target event changes, obtain the target listening object in the set of listening objects according to the target event;

[0084] The interaction module 430 is used to, based on the state change of the target event, reset the state value of the target event in the listening object and publish it, and determine whether there is an observer on the target listening object after the publication;

[0085] The removal module 440 is used to remove the target listening object when there is no observer on the target listening object.

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

[0087] Please refer to Figure 5 , Figure 5 which is a schematic structural diagram of an in-vehicle terminal provided by an embodiment of the present application. Figure 5 shows a schematic structural diagram of a computer system of an in-vehicle terminal suitable for implementing the embodiment of the present application. It should be noted that Figure 5 the shown computer system 500 of the in-vehicle terminal is only an example and should not bring any limitation to the functions and usage scope of the embodiment of the present application.

[0088] As Figure 5 As shown, computer system 500 includes a Central Processing Unit (CPU) 501, which can perform various appropriate actions and processes according to a program stored in a Read-Only Memory (ROM) 502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503, such as executing the methods in the above embodiments. In the RAM 503, various programs and data required for system operations are also stored. The CPU 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An Input / Output (I / O) interface 505 is also connected to the bus 504.

[0089] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including, for example, a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed so that a computer program read from it can be installed into the storage section 508 as needed.

[0090] Specifically, 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, which 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 a network via the communication section 509, and / or installed from the removable medium 511. When the computer program is executed by a Central Processing Unit (CPU) 501, various functions defined in the system of the present application are executed.

[0091] The present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor of a computer, the computer is caused to execute the in-process communication method as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist separately and not be assembled into the electronic device.

[0092] It should be noted that the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable computer program. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0093] 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 module, program segment, or part of code contains one or more executable instructions for implementing a 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, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0094] The units involved in the embodiments described in this 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 on the units themselves in some cases.

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

Claims

1. An in-process communication method, characterized in that, The method includes: Creating a set of listener objects through an in-process event bus framework, where each listener object in the set of listener objects corresponds to an event, and at least one observer corresponding to the event is registered on each of the listener objects; If it is detected that the state of the in-process target event has changed, then obtain the target listener object in the set of listener objects according to the target event; Based on the state change of the target event, reset the state value of the target event in the listener object and publish it, and determine whether there is an observer on the target listener object after the publication; When there is no such observer on the target listener object, remove the target listener object; The construction method of the in-process event bus framework includes: According to the observable data holding class and the mutable real-time data class, create a listener object generation class, and set 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 and the observer removal function; Customize a listener object management class, and set the second attribute and the second function of the listener object management class. Among them, the listener object management class is used to manage each of the listener objects. The second attribute includes a weak reference set for storing each of the listener objects and a strong reference set for storing the listener objects that need persistent subscription. The second function includes the listener object creation function and the listener object removal function.

2. The in-process communication method according to claim 1, wherein The creation of the set of listener objects through the in-process event bus framework includes: Obtain the business scenario and event identifier of each event, as well as the observer identifier and lifecycle status of all observers corresponding to each event; Call the listener object management class, and generate a listener instance for each event through the listener object creation function; In response to each listener instance, run the listener object script and execute the observer registration function, so as to set the sticky subscription attribute and the identification attribute of each listener instance according to the business scenario and the event identifier of each event, and register an observer on each listener instance according to the observer identifier, generating a plurality of listener objects; Store the plurality of listener objects into the weak reference set, and determine whether the subscription method of each listener object is a persistent subscription method according to the lifecycle status of all observers. If so, store the corresponding listener object into the strong reference set to complete the creation of the set of listener objects.

3. The in-process communication method according to claim 1, wherein The in-process event bus framework includes a listener object management class, and the listener object management class includes a listener object removal function; The removal of the target listener object includes: Determine whether the subscription method of the target listener object is a persistent subscription method according to the lifecycle status of all observers on the target listener object; If so, after all observers are removed, in response to the listener object removal operation, call the listener object management class and execute the listener object removal function to remove the target listener object; Otherwise, after all observers are removed, the target listening object is cleared.

4. The in-process communication method according to claim 3, wherein The in-process event bus framework includes a listening object generation class, and the listening object generation class includes an observer removal function; Before determining whether the observer exists on the target listening object after publication, it further includes: If the life cycle status 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 status 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, and the any observer is removed from the target listening object.

5. The in-process communication method according to claim 1, wherein Determining whether the observer exists on the target listening object after publication includes: Defining an observer number monitoring function in the observer removal function; Executing the observer number monitoring function to monitor the number of observers on the target listening object; Determining whether the observer exists on the target listening object according to the number of observers.

6. The in-process communication method according to any one of claims 1 to 5, characterized in that Before obtaining the target listening object in the listening object set according to the target event, it further includes: Matching the listening object in the listening object set according to the event identifier of the target listening event; If the matching fails, a listening object corresponding to the target listening event is created according to the in-process event bus framework and stored in the listening object set.

7. An in-process communication system, characterized in that, The system includes: A creation module, configured to create a listening object set through an in-process event bus framework, where each listening object in the listening object set corresponds to an event, and at least one observer corresponding to the event is registered on each listening object; A monitoring module, configured to, if it is monitored that the status of an in-process target event changes, obtain the target listening object in the listening object set according to the target event; An interaction module, configured to reset the status value of the target event in the listening object and publish it based on the status change of the target event, and determine whether the observer exists on the target listening object after publication; A removal module, configured to remove the target listening object when the observer does not exist on the target listening object; The creation module is further configured to create a listening object generation class according to an observable data holding class and a mutable real-time data class, and set 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 and the observer removal function; a custom listening object management class is defined, and the second attribute and the second function of the listening object management class are set. Among them, the listening object management class is used to manage each listening object, the second attribute includes a weak reference set for storing each listening object and a strong reference set for storing the listening objects that need persistent subscription, and the second function includes a listening object creation function and a listening object removal function.

8. A vehicle-mounted terminal, characterized in that, Includes: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the vehicle-mounted terminal to implement the intra-process communication method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, Computer-readable instructions are stored thereon, which, when executed by a processor of a computer, cause the computer to execute the intra-process communication method according to any one of claims 1 to 6.

Images