CN112416623A - Message delivery method for android system and computer-readable storage medium - Google Patents
Message delivery method for android system and computer-readable storage medium Download PDFInfo
- Publication number
- CN112416623A CN112416623A CN202011359646.0A CN202011359646A CN112416623A CN 112416623 A CN112416623 A CN 112416623A CN 202011359646 A CN202011359646 A CN 202011359646A CN 112416623 A CN112416623 A CN 112416623A
- Authority
- CN
- China
- Prior art keywords
- message
- broadcast
- subscriber
- class
- android system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000002716 delivery method Methods 0.000 title description 6
- 238000000034 method Methods 0.000 claims abstract description 117
- 230000008569 process Effects 0.000 claims abstract description 32
- 230000003111 delayed effect Effects 0.000 claims description 14
- 238000006243 chemical reaction Methods 0.000 claims description 8
- 230000000694 effects Effects 0.000 claims description 5
- 239000012634 fragment Substances 0.000 claims description 5
- 238000004891 communication Methods 0.000 abstract description 11
- 230000005540 biological transmission Effects 0.000 abstract description 9
- 230000006870 function Effects 0.000 description 3
- 239000000969 carrier Substances 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The invention discloses a message transmission method and a computer readable storage medium for an android system, wherein the message transmission method comprises the following steps: after receiving a message sending request, judging whether the message is sent in a process or not; if the message is sent in the process, setting the value of the observable memory class according to the message so that a subscriber of the message can call back the message based on the observable memory class to obtain the message; if the message is sent in a cross-process mode, the broadcast intention is determined and is transmitted to the subscriber in a broadcast mode, so that the subscriber can acquire the message according to the broadcast intention, and the broadcast intention comprises the message and identification information of the subscriber. The method not only can effectively reduce the risk of memory leakage, but also can realize cross-process communication.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a message delivery method and a computer-readable storage medium for an android system.
Background
For the Android system, messaging is the most basic component, and different pages and different components in each application are in messaging. The message transmission can be used for transmission among the four Android components and communication between the asynchronous thread and the main thread, but the current message transmission mode has the risk of memory leakage, and further application breakdown can be caused.
Disclosure of Invention
The present invention is directed to solving, at least to some extent, one of the technical problems in the related art. Therefore, a first objective of the present invention is to provide a message passing method for an android system, which not only can effectively reduce the risk of memory leakage, but also can implement cross-process communication.
A second object of the invention is a computer-readable storage medium.
In order to achieve the above object, an embodiment of a first aspect of the present invention provides a message delivery method for an android system, including the following steps: after receiving a message sending request, judging whether the message is sent in a process or not; if the message is sent in the process, setting the value of the observable memory class according to the message so that a subscriber of the message can call back the message based on the observable memory class to obtain the message; if the message is sent in a cross-process mode, the broadcast intention is determined and is transmitted to the subscriber in a broadcast mode, so that the subscriber can acquire the message according to the broadcast intention, and the broadcast intention comprises the message and identification information of the subscriber.
According to the message transmission method for the android system, after a message transmission request is received, whether the message is sent in the process is judged, if the message is sent in the process, the value of the observable storage class is set according to the message, so that a subscriber of the message can call back the message based on the observable storage class to obtain the message, and the observable storage class has life cycle perception, so that the message is transmitted through the observable storage class, and the risk of memory leakage can be effectively reduced; if the message is sent in a cross-process mode, the broadcast intention is determined, and the broadcast intention is transmitted to the subscriber in a broadcast mode, so that the subscriber can acquire the message according to the broadcast intention, and cross-process communication is achieved.
According to an embodiment of the present invention, before setting a value of the observable memory class or determining the broadcast intention according to the message, further comprising: judging whether the current thread is a main thread; if the thread is a main thread, setting a value of an observable memory class or determining a broadcast intention according to the message; if the thread is not the main thread, after the current thread is switched to the main thread through the Handler, the value of the observable memory class is set according to the message or the broadcast intention is determined.
According to an embodiment of the present invention, before setting a value of the observable memory class or determining the broadcast intention according to the message, further comprising: the delayed sending time of the message is set by the Handler.
According to an embodiment of the present invention, before setting a value of the observable memory class or determining the broadcast intention according to the message, further comprising: and setting the message grade of the message through the Handler, wherein the message grade is used for representing the sending sequence of the message.
According to an embodiment of the present invention, after receiving the message sending request, the method further includes: performing type conversion on the message; writing the converted message into a cross-process message carrier; and adding the cross-process message carrier into a message list to be sent.
According to an embodiment of the present invention, after setting the value of the observable memory class according to the message, further comprising: observing the life cycle of the subscriber through the observable storage class; if the subscriber's life cycle is over, the message is removed from the message list.
According to one embodiment of the invention, the end of the lifecycle comprises: the subscriber is cancelled or the lifetime of the subscriber's Activity and/or Fragment is destroyed.
According to one embodiment of the invention, the broadcast intention is delivered to the subscriber by a broadcast mode, which comprises the following steps: the broadcast intention is delivered to a broadcast receiver corresponding to the subscriber in a broadcast mode, so that the broadcast intention is received through the broadcast receiver, the message is acquired according to the broadcast intention, and the message is delivered to the subscriber through an observable storage class.
According to one embodiment of the invention, the observable memory class is the LiveData class.
To achieve the above object, a second embodiment of the present invention provides a computer-readable storage medium, on which a messaging program for an android system is stored, and the messaging program, when executed by a processor, implements the above-mentioned messaging method for the android system.
According to the computer-readable storage medium provided by the embodiment of the invention, by the message transmission method for the android system, the risk of memory leakage can be effectively reduced, and cross-process communication can be realized.
Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.
Drawings
FIG. 1 is a flow diagram of a messaging method for an android system, in accordance with one embodiment of the present invention;
fig. 2 is a flowchart of a messaging method for an android system according to a specific example of the present invention.
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.
A message delivery method and a computer-readable storage medium for an android system proposed by an embodiment of the present invention are described below with reference to the accompanying drawings.
Fig. 1 is a flowchart of a messaging method for an android system according to an embodiment of the present invention. Referring to fig. 1, the message delivery method for the android system may include the following steps:
step S101, after receiving the message sending request, judging whether the message is sent in the process.
The message may be any Object (Object), may define different types of messages, or may be a custom message. The sending of messages includes sending messages intra-process and sending messages cross-process (also referred to as inter-process messages). After receiving the message sending request, it may be determined whether to send the message in the process or send the message across the processes according to the message sending request, which may be implemented by using the prior art, and is not limited herein.
In one embodiment, after receiving the message sending request, the method further comprises: performing type conversion on the message; writing the converted message into a cross-process message carrier; and adding the cross-process message carrier into a message list to be sent. The converted data types include, but are not limited to, Boolean type, Double type, Float type, Int type, Long type, String type, and custom type.
Specifically, after receiving the message sending request, the message publisher may perform type conversion on the message, such as conversion into a Boolean type, a Double type, or a Float type, and then write the converted message into a cross-process message carrier, such as Bundle (an android cross-process communication message carrier), and create and store a data structure of the message, such as a HashMap (hash table), and store the cross-process message carrier in the HashMap. That is to say, the message publisher writes all messages to be sent into corresponding cross-process message carriers respectively, and then stores the cross-process message carriers into a message list to be sent, so that messages in the message list to be sent are transmitted one by one subsequently.
It should be noted that before storing the cross-process message carrier to the HashMap, it is also determined whether the message in the cross-process message carrier already exists in the HashMap, and if so, the message is not stored, otherwise, the cross-process message carrier is stored to the HashMap. That is, before saving, it is checked whether the message to be sent already exists in the message list to be sent, and if so, the message to be sent is not saved, so as to reduce the number of saving times.
And step S102, if the message is sent in the process, setting the value of the observable memory class according to the message so that a subscriber of the message can call back the message based on the observable memory class to obtain the message. Optionally, the observable memory class is the LiveData class.
After receiving the message sending request, the message publisher can store the message in a message list to be sent through a cross-process message carrier, and then judge whether the message is sent in a process or in a cross-process mode according to the message sending request. If the message is sent in the process, the message is transmitted to the subscriber of the message through the observable memory class, for example, the observable memory class is an LiveData class, a plurality of LiveData classes are provided in the message bus, each LiveData class represents a message channel, each LiveData class has corresponding identification information and a subscriber list, when the message is sent, the message channel is obtained through getChannel, that is, the LiveData class is obtained, then the value of the LiveData class is set to inform all subscribers in the subscriber list that the current data is updated, and the corresponding program code may be: LiveData < HashMap >. set (new HashMap), at this time, all subscribers in the subscriber list can obtain the message by the message callback method, for example, by inheriting the mutelivedata in the LiveData class, rewriting the observe method, and adding the callback method to the subscriber list.
It should be noted that before obtaining a message through the message callback method, the subscriber also determines whether the current thread is a main thread, if the current thread is a non-main thread, the current thread is switched to the main thread through a Handler, then the message callback method is defined, and the callback method is added to the subscriber list by inheriting the muselelivedata in the LiveData class and rewriting the observe method, so as to obtain the message.
In one embodiment, after setting the value of the observable memory class according to the message, further comprising: observing the life cycle of the subscriber through the observable storage class; if the subscriber's life cycle is over, the message is removed from the message list. Optionally, the ending of the life cycle comprises: the subscriber is cancelled or the lifetime of the subscriber's Activity and/or Fragment is destroyed.
Specifically, a corresponding subscriber can be acquired through a LifecycleOwner interface, LifecycleLiveData is defined to inherit the LiveData class, and a removeObserver method in the LiveData class is rewritten.
In one embodiment, before setting the value of the observable memory class according to the message, the method further comprises: judging whether the current thread is a main thread; if the thread is the main thread, setting the value of the observable memory class according to the message; if the thread is not the main thread, the value of the observable memory class is set according to the message after the current thread is switched to the main thread through the Handler.
That is, when determining that the current process sends a message, the message publisher firstly determines whether the current thread is a main thread, and if the current thread is the main thread, the message publisher sets a value of an observable memory class such as a LiveData class according to the message, so as to transmit the message through the observable memory class such as the LiveData class; otherwise, the current thread is switched to the main thread through the Handler, and then the observable memory class such as the LiveData class is set according to the message so as to transmit the message through the observable memory class such as the LiveData class.
In one embodiment, before setting the value of the observable memory class according to the message, the method further comprises: the delayed sending time of the message is set by the Handler. That is, when the delayed message is sent in the process, the Handler can be used for setting the time required for delayed sending, and then the observable memory class such as the LiveData class is set according to the message, so that the message is transmitted through the observable memory class such as the LiveData class, the delayed sending of the message in the process is realized, and the problem that the message cannot be sent in a delayed manner is effectively solved.
In one embodiment, before setting the value of the observable memory class according to the message, the method further comprises: and setting the message grade of the message through the Handler, wherein the message grade is used for representing the sending sequence of the message. That is, when messages are sent in order in the process, the message level, namely the priority level, of the messages can be set through the Handler, then the messages are sent one by one according to the message level, and when the messages are sent, observable memory types such as the LiveData types are set according to the messages, so that the messages are transmitted through the observable memory types such as the LiveData types, the messages are sent in order in the process, and the problem that the messages cannot be sent in order is effectively solved.
As an example, when it is determined that a message is currently sent in a process, a delay time for sending the message and a message class of the message may be set by a Handler first, so that messages in a message list to be sent are sent one by one according to the delay time and the message class. During sending, judging whether the current thread is a main thread, and if the current thread is the main thread, setting an observable memory class such as a LiveData class according to the message; otherwise, the current thread is switched to the main thread through the Handler, and then the observable memory class such as the LiveData class is set according to the message. When the value of an observable memory class such as a LiveData class changes, the observable memory class such as the LiveData class informs all subscribers in a corresponding subscriber list of the observable memory class, at this time, the subscriber judges whether a current thread is a main thread or not, if the current thread is a non-main thread, the current thread is switched to the main thread through a Handler, then a message callback method is defined, and the callback method is added to the subscriber list to acquire a message by inheriting the observable memory class such as the MutableLiveData in the LiveData class and rewriting an observe method.
In the embodiment, since the observable storage device such as the LiveData device can sense and follow the life cycle of the components such as Activity, Fragment and the like, when the components are destroyed, the data in the message list to be sent is cleared immediately, so that memory leakage is avoided, meanwhile, delayed sending and ordered sending of the messages can be realized based on the Handler, and the problem that the messages cannot be delayed and ordered sent is solved.
Step S103, if the message is sent in a cross-process mode, determining a broadcast intention, and transmitting the broadcast intention to a subscriber in a broadcast mode, so that the subscriber can acquire the message according to the broadcast intention, wherein the broadcast intention comprises the message and identification information of the subscriber.
If the message is sent in a cross-process manner, the message is delivered to the subscriber of the message in a BroadCast manner, for example, a BroadCast intention is determined firstly, the BroadCast intention comprises the message and identification information of the subscriber, then the BroadCast intention is delivered to the subscriber through BroadCast, and the subscriber acquires the message according to the BroadCast intention at the moment.
According to one embodiment of the invention, the broadcast intention is delivered to the subscriber by a broadcast mode, which comprises the following steps: the broadcast intention is delivered to a broadcast receiver corresponding to the subscriber in a broadcast mode, so that the broadcast intention is received through the broadcast receiver, the message is acquired according to the broadcast intention, and the message is delivered to the subscriber through an observable storage class.
Specifically, when sending a message across processes, a broadcast receiver may be registered and defined, for example, a broadcast receiver class is defined, BroadcastReceiver class is inherited, a subscriber is received through the broadcast receiver, and after receiving the broadcast intention, a message in the broadcast intention is obtained, and the type of the message is converted so as to conform to a data type corresponding to the subscriber, such as the foregoing type, and then the message is delivered to the subscriber in the process through an observable storage class. That is, when sending a message across processes, the message is first transmitted to a broadcast receiver corresponding to a subscriber in a broadcast manner, and then the broadcast receiver acquires the message and transmits the message to the subscriber in the process through an observable storage class.
In one embodiment, before determining the broadcast intention, further comprising: judging whether the current thread is a main thread; if the current thread is the main thread, determining the broadcast intention; and if the current thread is a non-main thread, determining the broadcast intention after switching the current thread to the main thread through a Handler.
That is to say, when it is determined that the current message is sent in a cross-process manner, the message publisher firstly judges whether the current thread is a main thread, if so, the message publisher determines the broadcast intention, and transmits the broadcast intention to the subscriber in a broadcast manner, so that the subscriber can obtain the message according to the broadcast intention; otherwise, the current thread is switched to the main thread through the Handler, then the broadcasting intention is determined, and the broadcasting intention is transmitted to the subscriber through a broadcasting mode, so that the subscriber can acquire the message according to the broadcasting intention.
In one embodiment, before determining the broadcast intention, further comprising: the delayed sending time of the message is set by the Handler. Namely, when the delay message is sent across the processes, the time needing to be sent in a delay mode can be set through the Handler, then the broadcast intention is determined, and the broadcast intention is transmitted to the subscriber in a broadcast mode, so that the subscriber can acquire the message according to the broadcast intention, the delay sending of the cross-process message is achieved, and the problem that the message cannot be sent in a delay mode is effectively solved.
In one embodiment, before determining the broadcast intention, further comprising: and setting the message grade of the message through the Handler, wherein the message grade is used for representing the sending sequence of the message. Namely, when messages are sent in order across processes, message grades, namely priority levels, of the messages can be set through a Handler, then the messages are sent one by one according to the message grades, and when the messages are sent, broadcast intentions are determined, and the broadcast intentions are transmitted to subscribers in a broadcast mode, so that the subscribers can acquire the messages according to the broadcast intentions, the ordered sending of the messages across processes is achieved, and the problem that the messages cannot be sent in order is effectively solved.
As an example, when determining that a message is currently sent across processes, a delay time for sending the message and a message class of the message may be set by a Handler first, so that messages in a message list to be sent are sent one by one according to the delay time and the message class. During sending, judging whether the current thread is a main thread, if so, determining a broadcast intention, wherein the broadcast intention comprises information and identification information of a subscriber, and transmitting the broadcast intention to a broadcast receiver corresponding to the subscriber in a broadcast mode; otherwise, the current thread is switched to the main thread through the Handler, then the broadcasting intention is determined, and the broadcasting intention is transmitted to the broadcasting receiver corresponding to the subscriber in a broadcasting mode. After receiving the broadcast intention, the broadcast receiver acquires the message in the broadcast intention and the identification information of the subscriber, converts the format of the message, and transmits the message to the subscriber in the process through an observable memory class such as a LiveData class, namely, the cross-process communication is firstly carried out, and then the in-process communication is carried out. It should be noted that the broadcast receiver is in the main thread corresponding to the subscriber.
In the embodiment, the cross-process message sending can be realized through a broadcasting mode, meanwhile, the delayed sending and the ordered sending of the message can be realized based on the Handler, and the problem that the message cannot be delayed sent and ordered sent when the message is sent in a cross mode is solved.
Fig. 2 is a flowchart of a messaging method for an android system according to a specific example of the present invention, and referring to fig. 2, the messaging method for an android system may include the following steps:
step S201, performs format conversion on the message.
Step S202, writing the message after format conversion into a cross-process message carrier Bundle.
And step S203, storing the cross-process message carrier into a to-be-sent message list HaspMap.
Step S204, judging whether the message is sent in the process. If yes, go to step S205 or step S206; otherwise, step S210 or step S211 is performed.
And step S205, setting the delay time of message sending through the Handler to delay the message sending.
And step S206, setting the message grade of the message through the Handler to send the message in order.
Step S207, determine whether the current thread is the main thread. If yes, go to step S209; otherwise, step S208 is performed.
And step S208, switching the current thread to the main thread through the Handler.
In step S209, the value of the LiveData class is set.
And step S210, setting the delay time of message sending through the Handler to delay the message sending.
And step S211, setting the message grade of the message through the Handler to send the message in order.
In step S212, it is determined whether the current thread is the main thread. If yes, go to step S214; otherwise, step S213 is performed.
And step S213, switching the current thread to the main thread through the Handler.
In step S214, the Broadcast intention is defined and transmitted via Broadcast.
It should be noted that steps S201 to S214 mainly implement the distribution of the message by the publisher.
In step S215, it is determined whether the current thread is the main thread. If yes, go to step S217; otherwise, step S216 is executed.
And step S216, switching the current thread to the main thread through the Handler.
Step S217, defining a message callback method, rewriting the observe by inheriting the MultibleLiveData in the LiveData class, and adding the callback method into the subscriber queue.
Step S218, defining LifecycleLiveData to inherit the LiveData class, rewriting removeObserver in the LiveData class, deleting the corresponding message in the HaspMap through the removeObserver when the subscriber is cancelled or the life cycle of Activity and Fragment is destroyed.
In step S219, it is determined whether the current thread is the main thread. If yes, go to step S221; otherwise, step S220 is executed.
And step S220, switching the current thread to the main thread through the Handler.
Step S221, defining a broadcast receiver class, inheriting broadcastReceiver, rewriting onReceive to receive the broadcast intention, acquiring the message in the broadcast intention and performing format conversion.
Step S222 sets the value of the LiveData class to deliver the message to the in-process subscriber.
It should be noted that steps S215 to S222 mainly implement the receiving of the message by the subscriber.
In summary, according to the message passing method for the android system in the embodiment of the present invention, after receiving the message sending request, it is determined whether the message is sent in the process, and if the message is sent in the process, the value of the observable storage class is set according to the message, so that the subscriber of the message receives the message based on the observable storage class and performs message callback, and since the observable storage class has life cycle awareness, the message passing is performed through the observable storage class, and the risk of memory leakage can be effectively reduced; if the message is sent in a cross-process mode, the broadcast intention is determined, and the broadcast intention is transmitted to the subscriber in a broadcast mode, so that the subscriber can acquire the message according to the broadcast intention, and cross-process communication is achieved. Meanwhile, delayed sending and ordered sending of the message can be achieved based on the Handler, the problem that the message cannot be delayed sent and ordered sent is solved, and the size of the application packet can be effectively reduced, for example, the size of the EventBus packet is 57kb, the size of the RxBus packet is 2.2MB, and the size of the application packet corresponding to the application can reach 15 kb.
In addition, an embodiment of the present invention also provides a computer-readable storage medium on which a messaging program for the android system is stored, where the messaging program, when executed by a processor, implements the above-mentioned messaging method for the android system.
According to the computer-readable storage medium provided by the embodiment of the invention, by the message transmission method for the android system, the risk of memory leakage can be effectively reduced, and cross-process communication can be realized.
It should be noted that the logic and/or steps represented in the flowcharts or otherwise described herein, such as an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
In the present invention, unless otherwise expressly stated or limited, the terms "mounted," "connected," "secured," and the like are to be construed broadly and can, for example, be fixedly connected, detachably connected, or integrally formed; can be mechanically or electrically connected; they may be directly connected or indirectly connected through intervening media, or they may be connected internally or in any other suitable relationship, unless expressly stated otherwise. The specific meanings of the above terms in the present invention can be understood by those skilled in the art according to specific situations.
Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.
Claims (10)
1. A message passing method for an android system is characterized by comprising the following steps:
after receiving a message sending request, judging whether the message is sent in a process or not;
if the message is sent in the process, setting the value of the observable memory class according to the message so that a subscriber of the message can call back the message based on the observable memory class to obtain the message;
if the message is sent in a cross-process mode, determining a broadcast intention, and transmitting the broadcast intention to the subscriber in a broadcast mode, so that the subscriber can obtain the message according to the broadcast intention, wherein the broadcast intention comprises the message and identification information of the subscriber.
2. The messaging method for the android system of claim 1, further comprising, prior to setting a value of an observable memory class or determining an intent to broadcast from the message:
judging whether the current thread is a main thread;
if the thread is a main thread, setting a value of an observable memory class or determining a broadcast intention according to the message;
if the current thread is not the main thread, after the current thread is switched to the main thread through the Handler, setting a value of an observable memory class or determining a broadcast intention according to the message.
3. The messaging method for the android system of claim 2, further comprising, prior to setting a value of an observable memory class or determining an intent to broadcast from the message:
and setting the delayed sending time of the message through the Handler.
4. The messaging method for the android system of claim 2, further comprising, prior to setting a value of an observable memory class or determining an intent to broadcast from the message:
and setting the message grade of the message through the Handler, wherein the message grade is used for representing the sending sequence of the message.
5. The messaging method for the android system of claim 1, further comprising, after receiving the message sending request:
performing type conversion on the message;
writing the converted message into a cross-process message carrier;
and adding the cross-process message carrier into a message list to be sent.
6. The messaging method for the android system of claim 5, further comprising, after setting a value of an observable memory class from the message:
observing a lifecycle of the subscriber through the observable memory class;
and if the life cycle of the subscriber is finished, removing the message from the message list.
7. The messaging method for the android system of claim 6, wherein the end of the lifecycle comprises: the subscriber is cancelled or the lifetime of the subscriber's Activity and/or Fragment is destroyed.
8. The messaging method for the android system of claim 1, wherein the delivering the broadcast intent to the subscriber by broadcast comprises:
and transmitting the broadcast intention to a broadcast receiver corresponding to the subscriber in a broadcast mode, receiving the broadcast intention through the broadcast receiver, acquiring the message according to the broadcast intention, and transmitting the message to the subscriber through the observable storage class.
9. Messaging method for android system according to any of claims 1 to 8, characterized in that the observable memory class is the LiveData class.
10. A computer-readable storage medium, having stored thereon a messaging program for an android system, which when executed by a processor implements a messaging method for an android system as recited in any one of claims 1-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011359646.0A CN112416623A (en) | 2020-11-27 | 2020-11-27 | Message delivery method for android system and computer-readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011359646.0A CN112416623A (en) | 2020-11-27 | 2020-11-27 | Message delivery method for android system and computer-readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112416623A true CN112416623A (en) | 2021-02-26 |
Family
ID=74842730
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011359646.0A Pending CN112416623A (en) | 2020-11-27 | 2020-11-27 | Message delivery method for android system and computer-readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112416623A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106598725A (en) * | 2016-10-31 | 2017-04-26 | 武汉斗鱼网络科技有限公司 | Android-based Handler memory leakage prevention device and method |
| US20180033312A1 (en) * | 2016-07-29 | 2018-02-01 | International Business Machines Corporation | Unmanned aerial vehicle ad-hoc clustering and collaboration via shared intent and operator discovery |
| CN109194736A (en) * | 2018-08-30 | 2019-01-11 | 百度在线网络技术（北京）有限公司 | Message De-weight method, device, electronic equipment, medium and unmanned vehicle |
| CN111552581A (en) * | 2020-05-07 | 2020-08-18 | 网易（杭州）网络有限公司 | Event delivery method, device and system and electronic equipment |
-
2020
- 2020-11-27 CN CN202011359646.0A patent/CN112416623A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180033312A1 (en) * | 2016-07-29 | 2018-02-01 | International Business Machines Corporation | Unmanned aerial vehicle ad-hoc clustering and collaboration via shared intent and operator discovery |
| CN106598725A (en) * | 2016-10-31 | 2017-04-26 | 武汉斗鱼网络科技有限公司 | Android-based Handler memory leakage prevention device and method |
| CN109194736A (en) * | 2018-08-30 | 2019-01-11 | 百度在线网络技术（北京）有限公司 | Message De-weight method, device, electronic equipment, medium and unmanned vehicle |
| CN111552581A (en) * | 2020-05-07 | 2020-08-18 | 网易（杭州）网络有限公司 | Event delivery method, device and system and electronic equipment |
Non-Patent Citations (3)
| Title |
|---|
| MARINATSANG: "Android线程间通信-Handler消息机制", pages 1 - 10, Retrieved from the Internet <URL:CSDN博客，https://blog.csdn.net/MarinaTsang/article/details/84786577> * |
| WEIXIN_38754349: "Android 使用 LiveData 实现 EventBus", pages 1 - 9, Retrieved from the Internet <URL:CSDN博客，https://blog.csdn.net/weixin_38754349/article/details/106088750> * |
| 好人静: "Android的跨进程通信", pages 1 - 5, Retrieved from the Internet <URL:CSDN博客，https://blog.csdn.net/nihaomabmt/article/details/82870426> * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2009153177A (en) | Method and radio communication device for transmission efficiency improvement preparation processing for multimedia message | |
| CN111698175B (en) | Message receiving and transmitting method and system for gateway | |
| CN111401956A (en) | Advertisement service degradation method, device, server and storage medium | |
| CN111045807B (en) | Method, device, computer equipment and storage medium for processing task based on zookeeper | |
| CN101232466B (en) | Information transmitting method and information transmitting device | |
| CN112416623A (en) | Message delivery method for android system and computer-readable storage medium | |
| CN112882742A (en) | Software updating method and related equipment | |
| CN110708234A (en) | Message transmission processing method, message transmission processing device and storage medium | |
| CN112732560B (en) | Method and device for detecting leakage risk of file descriptor | |
| US20210107325A1 (en) | Method and device for upgrading tpms diagnostic tool | |
| CN112148320A (en) | Application program upgrading method, device, equipment and storage medium | |
| CN114844931A (en) | Vehicle remote control method, device, server and storage medium | |
| CN113746932A (en) | Network request merging method and device, electronic device and computer program product | |
| CN111459819B (en) | Software testing method and device, electronic equipment and computer readable medium | |
| CN116017747A (en) | Frequency point priority adjustment method and device | |
| CN108810644B (en) | Bullet screen message distribution method, device, equipment and storage medium | |
| CN113157611A (en) | Data transmission control method, device, equipment and readable storage medium | |
| EP4322502A1 (en) | Internet-of-vehicles based traffic scheduling method and apparatus, device and medium | |
| CN111083127B (en) | Session management method, electronic device, and computer-readable storage medium | |
| US20240069888A1 (en) | Vehicular software update system and method therefor | |
| CN117915476B (en) | Information integration system processing method and system | |
| CN111524059A (en) | Memory utilization method, system, terminal and storage medium during image caching | |
| CN116962386A (en) | File transmission method, device, electronic equipment and storage medium | |
| CN115474222B (en) | Communication method and system of terminal, electronic equipment and storage medium | |
| CN104956328A (en) | Reentrant resource scheduling method, device and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20231129 Address after: 518000 Baoneng Center, No. 3008 Baoneng North Road, Luohu District, Shenzhen, Guangdong Province Applicant after: Shenzhen Shengbo Hairui Management Co.,Ltd. Address before: 510700 Baoneng Cultural Plaza, 59 lichui street, Huangpu District, Guangzhou City, Guangdong Province Applicant before: Baoneng (Guangzhou) Automobile Research Institute Co.,Ltd. |
|
| TA01 | Transfer of patent application right |