This article is based on native Android9.0Source code to parse Android message mechanisms: frameworks/base/core/java/android/os/Handler.java
frameworks/base/core/java/android/os/Looper.java
frameworks/base/core/java/android/os/MessageQueue.java
frameworks/base/core/java/android/os/Message.java
frameworks/base/core/java/android/app/ActivityThread.java
Copy the code1. An overview of the
We know that we can’t do time-consuming operations on the main thread of Android, such as network access and data processing, because if the main thread processing time exceeds the system limit, the application will not respond. In practice, however, processing time-consuming tasks is unavoidable, and it is often necessary to update some UI controls after processing time-consuming tasks to display the results. In this scenario, the most common solution is to perform time-consuming operations in a new thread, and then notify the main thread of relevant UI updates. This is where the Android messaging mechanism is needed.
What exactly is a messaging mechanism? To put it simply, Android messaging mechanism is a set of “message” as the intermediary to achieve task switching between threads or tasks in the same thread on demand execution mechanism, which involves message sending, storing messages, message loop and message distribution and processing.
This article will first demonstrate how to use the Android messaging mechanism through a simple example, and then analyze the source code to further understand the internal implementation of the messaging mechanism, and finally explain some of the attention points of using the Android messaging mechanism.
2. First look at Android messaging
To start with a simple example of how Android messaging works in practice, let’s directly use the previously mentioned scenario where the child thread processes a time-consuming task and notifies the main thread to update the UI after the task is completed. The example code is as follows:
public class MainActivity extends Activity {
// Define Handler and Thread local variables
private Handler mHandler;
private Thread mThread;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler = new Handler() {
@Override
public void handleMessage (Message msg) {
// 4\. Different processing according to different message types
switch (msg.what) {
// Perform uI-related operations here, such as displaying processing results.}}}; mThread =new Thread() {
@Override
public void run(a) {
// 2\. Hibernate for a period of time to simulate child threads processing time-consuming tasks.
try {
Thread.sleep(30000);
} catch (InterruptedException ie) {
ie.printStackTrace();
}
// 3\. Send message
mHandler.sendEmptyMessage(0); }};// 1\. Start the child threadmThread.start(); }}Copy the codeIn the example code, the logical flow is marked by serial number, that is, the child thread is started and the task is processed inside the thread, the message is sent to the main thread through the Handler after the task is processed, and finally the message is processed and the UI is updated in the main thread.
The Android messaging mechanism looks pretty simple. Just use Handler to send messages and process them. Is it really that simple? Of course not! As mentioned earlier, there are several key points involved in the messaging mechanism: send messages, store messages, message loops, and distribute processing messages. In this example, we only see send messages and process messages, not store messages and message loops.
This is because the Handler in this example uses messages sent and stored in the message queue in the main thread. The creation and circulation of the message queue are automatically performed by the system when the main thread is created, which is transparent to us and is not good for understanding the overall flow of the message mechanism.
Here is a more general example from which message queue creation and message loop opening can be clearly seen:
class LooperThread extends Thread {
public Handler mHandler;
public void run(a) {
// Initialize the Looper object, which creates a message queue inside.
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
// Process messages in the message queue.}};// If the message loop is started, the message will be fetched from the message queue and wait for the arrival of new messages when there are no messages.Looper.loop(); }}Copy the codeCombining these two examples, we have seen how the Android messaging mechanism works. We have also seen the process of sending a message, creating a message queue, opening a message loop, and processing a message. Here is a more intuitive “message passing flowchart” :
You can see the entire message passing process through the flowchart, as well as the classes involved at different stages:
- Message sending: Pass
HandlerTo the associatedMessageQueueSend a message; - Message storage: The sending of messages as
MessageStored in the form ofMessageQueue; - Message loop: Pass
LooperKept fromMessageQueueWhen there is no message in the queue, it blocks waiting for a new message. - Message distribution and processing:
LooperGet the message and distribute it toHandlerProcess.
3. Understand the Android messaging mechanism
As mentioned above, the message delivery process is mainly divided into “send message”, “store message”, “message loop” and “message distribution and processing”. I intended to explain each stage separately according to this process, but in the concrete writing, I found that each stage is not completely separated. For example, before talking about “sending messages”, we should first understand “message storage structure” and “message loop start”, and “message distribution” is the function of “message loop”.
Because of the interrelationship between these phases, there is no way to explain Android messaging strictly in the order in which it is delivered. After much deliberation, I decided to walk through the logic behind the generic Android messaging example described above.
Here’s another general example:
class LooperThread extends Thread {
public Handler mHandler;
public void run(a) {
// 1\. Initializes the Looper object, which creates a message queue inside.
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
// 4\. Processes messages in the message queue.}};// 2\. If the message loop is started, the message will be taken out from the message queue. If there is no message, the message will be blocked waiting for the arrival of new messages.
Looper.loop();
}
// 3\. Send message
mHandler.sendEmptyMessage(0);
}
Copy the codeThe following sections are based on the key points of the “messaging mechanism” identified in different numbers in the sample code.
3.1 Message Carrier
“Message” is the carrier of information in the Android Message mechanism, which contains the data to be transmitted in the entire Message transmission process. To understand the “Message mechanism”, we must first understand the Message carrier class Message:
/支那* Defines a message containing adescription and arbitrary data object that can be * sent to a{@link Handler}. This object contains two extra int fields andan
* extra object field that allow youto not do allocations in many cases. *
* <p class="note">While the constructor of Message is public, thebest way to get * one of these is to call {@link #obtain Message.obtain()} or one of the
* {@link Handler#obtainMessage Handler.obtainMessage()} methods, which willpull * them from a pool of recycled objects.</p>
* /
public final class Message implements Parcelable {... }Copy the codeThe Android framework’s declaration of Message carrier is brief, but conveys two core and most important messages:
MessageThe role of:MessageContains description information and data objects and is sent in the messaging mechanismHandlerThe data object mainly consists of two integer fields and an object field through which information can be passed. The cost of integers is minimal, so use integer fields to pass information wherever possible.
/支那* User-defined message code so that therecipient can identify * what this message is about. Each {@link Handler} has its own name-space
* for message codes, so youdo not need to worry about yours conflicting * with other handlers.
* /
public int what;
/支那* arg1 and arg2 are lower-cost alternatives to using * {@link #setData(Bundle) setData()} if you only need to store a * few integer values. */
public int arg1;
public int arg2;
/ * *
* An arbitrary object to send to the recipient. When using
* {@link Messenger} to send themessage across processes this can only * be non-null if it contains a Parcelable of a framework class (not one
* implemented by theapplication). For other data transfer use * {@link #setData}.
* * <p>Note that Parcelable objects here are not supported prior to
* the{@link android.os.Build.VERSION_CODES#FROYO} release. */
public Object obj;
Copy the codeMessageThe way to create: thoughMessageThere are public constructors, but it is recommended to use the ones providedobtainSeries of functions to obtainMessageObject, which recycles objects from the cache pool rather than creating new objects, avoiding creating too many objects in memory and possible performance problems.
/** * Return a new Message instance from the global pool. Allows us to * avoid allocating new objects in many cases. */
public static Message obtain() {
synchronized (sPoolSync) {
// Fetch Message objects from the cache pool if there are any available objects in the cache pool.
if(sPool ! =null) {
// Get the object in the cache and move the buffer pool pointer back.
Message m = sPool;
sPool = m.next;
m.next = null;
// Clear the flag bit
m.flags = 0; // clear in-use flag
// Update the current cache pool size
sPoolSize--;
returnm; }}// Create a new Message object when no object is available in the cache pool.
return new Message();
}
Copy the codeMessage contains a series of obtain functions that can be used to obtain objects in different scenarios, but this is the core, and is called internally by all other functions. If you are interested, you can review the source code for yourself.
The obtain function obtains Message objects from the cache pool. When were the objects added to the cache pool? Since the objects in the cache pool are objects that can be reused, it is clear that the Message object is added to the cache when it is no longer needed, taken out of the MessageQueue and distributed to the Handler, using the recycle-unchecked function:
/** * Recycles a Message that may be in-use. * Used internally by the MessageQueue and Looper when disposing of queued Messages. */
void recycleUnchecked() {
// Set the flag bit to "in use", which will be cleared when fetched from the cache.
flags = FLAG_IN_USE;
// The information in the Message object is no longer meaningful and is emptied before being put into the cache pool.
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = - 1;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
// Only a certain number of Message objects are cached in the cache pool. The default is 50.
if (sPoolSize < MAX_POOL_SIZE) {
// Put the object at the head of the list in the cache pool.
next = sPool;
sPool = this;
// Update the cache pool size in time.sPoolSize++; }}}Copy the code3.2 Creating a Message Queue
The creation of a message queue is critical to messaging, determining how messages are accessed during delivery. But threads do not have message queues by default and cannot loop messages within them. To start a message loop for a thread, use the Looper class, which creates a message queue for the associated thread and starts a message loop by calling the Prepare () interface:
/**
* Class used to run a message loop for a thread. Threads by default do
* not have a message loop associated with them; to create one, call
* {@link #prepare} in the thread that is to run the loop, and then
* {@link #loop} to have it process messages until the loop is stopped.
*/
public final class Looper {
// omit extraneous code
// sThreadLocal.get() will return null unless you've called prepare().
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
// Internal message queues and associated threads
final MessageQueue mQueue;
final Thread mThread;
// omit extraneous code
/** Initialize the current thread as a looper.
* This gives you a chance to create handlers that then reference
* this looper, before actually starting the loop. Be sure to call
* {@link #loop()} after calling this method, and end it by calling
* {@link #quit()}.
*/
public static void prepare(a) {
// Create an exit message loop. The main thread's message loop is not exit.
prepare(true);
}
private static void prepare(boolean quitAllowed) {
// Throw an exception if the current thread already has a Looper object.
// There can only be one message queue per thread.
if(sThreadLocal.get() ! =null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
// Create a Looper object and associate it with the thread.
sThreadLocal.set(new Looper(quitAllowed));
}
// Private constructor to create a message queue and get the current thread object.
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
Copy the codeAs you can see, looper.prepare () simply creates a MessageQueue object internally and associates it with the current thread, while ensuring that there is only one MessageQueue per thread.
MessageQueue is a structure used to store message objects.
/**
* Low-level class holding the list of messages to be dispatched by a
* {@link Looper}. Messages are not added directly to a MessageQueue,
* but rather through {@link Handler} objects associated with the Looper.
*
* <p>You can retrieve the MessageQueue for the current thread with
* {@link Looper#myQueue() Looper.myQueue()}.
*/
public final class MessageQueue {... }Copy the codeMessageQueue is a class that holds a list of message objects that are added through handlers associated with Looper and eventually distributed by Looper. There is one key piece of information that we should pay special attention to: List of messages, does this tell us that even though the name of this class is Queue, it’s not a queue, it’s a list? Indeed, MessageQueue is accessed internally using a one-way linked list method, which will be seen later in the process of parsing Message access, but will not be described in detail here.
3.3 Starting a Message Loop
Now that the “message queue” is created, can you add message objects directly to it? Looper.loop() : looper.loop () : looper.loop ()
/**
* Run the message queue in this thread. Be sure to call
* {@link #quit()} to end the loop.
*/
public static void loop(a) {
// Get the current thread's Looper object.
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
// Get the message queue of the current thread.
final MessageQueue queue = me.mQueue;
// omit extraneous code
// Start an infinite loop to listen for messages on the queue
for (;;) {
// Get the message object in the message queue, block the wait if there is no message object.
Message msg = queue.next(); // might block
if (msg == null) {
// Stop listening and exit the loop while the message queue is exiting
return;
}
// omit extraneous code
try {
// Send the message to the appropriate handler.
msg.target.dispatchMessage(msg);
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} finally {
if(traceTag ! =0) { Trace.traceEnd(traceTag); }}// omit extraneous code
// Reclaim the message object and place it in the message cache pool for future reuse.msg.recycleUnchecked(); }}Copy the codeThis code itself is quite complex, I omit the part of the code irrelevant to the core logic, for the convenience of everyone to read and understand, the core logic is to use an “infinite loop” to listen to the message queue, when found available messages and distribute processing, if not, wait.
3.4 Sending and storing Messages
The Message Queue has been created, the Message Loop has been started, and you can finally send messages.
To send a message, we need to use the Handler class, which send and POST series methods can be used to “send a message”, the core method is the same, here with post method to explain the process of sending a message:
/**
* Causes the Runnable r to be added to the message queue.
* The runnable will be run on the thread to which this handler is
* attached.
*
* @param r The Runnable that will be executed.
*
* @return Returns true if the Runnable was successfully placed in to the
* message queue. Returns false on failure, usually because the
* looper processing the message queue is exiting.
*/
public final boolean post(Runnable r) {
return sendMessageDelayed(getPostMessage(r), 0);
}
private static Message getPostMessage(Runnable r) {
// Encapsulate the Runnable object as a Message and set the callback,
// This callback will play a role in subsequent message distribution processing.
Message m = Message.obtain();
m.callback = r;
return m;
}
public final boolean sendMessageDelayed(Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
// Change the delay time to absolute time for subsequent execution.
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
// Message queue, that is, message queue created with looper.prepare ().
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
// Add messages to the message queue
return enqueueMessage(queue, msg, uptimeMillis);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
// Sets the target of the message queue for subsequent message distribution.
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
// The message object is queued
return queue.enqueueMessage(msg, uptimeMillis);
}
Copy the codeThrough a series of calls, the Handler may end MessageQueue. EnqueueMessage () to store the message to the message queue, MessageQueue internal is how to store the object was sent message?
boolean enqueueMessage(Message msg, long when) {
// If the target of the message object is NULL, this means that the message cannot be distributed.
// Is an invalid message object.
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
// An exception is thrown while the message is in use. The message cannot be used concurrently.
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
Reclaim message objects while exiting the message loop.
if (mQuitting) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
// Add the message object to the appropriate location in the message queue
if (p == null || when= =0 || when < p.when) {
// New head, wake up the event queue if blocked.
// If the message queue is empty or the current message object is the latest, it is placed directly at the head of the list.
msg.next = p;
// Update the list pointer
mMessages = msg;
// Wake up if the message loop was blocked
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
// Find the appropriate insertion location based on the time information in the message object
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false; }}// Insert the linked list after finding the appropriate location
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr ! = 0 because mQuitting is false.
// Wake up the wait, at which point the message loop can continue to fetch messages, possibly in a blocked wait state.
if(needWake) { nativeWake(mPtr); }}return true;
}
Copy the code3.5 Message Distribution
Have a new message in the message queue and message loop awakened, the message in the message queue can be removed and distributed to the appropriate handler, it can be seen in “open message loop” section, using the MSG. Target. DispatchMessage (MSG), A target is a Handler object that looks directly at the distribution process:
public void dispatchMessage(Message msg) {
// When the Message object is formed from the Runnable wrapper, the callback is not null.
if(msg.callback ! =null) {
handleCallback(msg);
} else {
// mCallback is set in the Handler constructor or not.
if(mCallback ! =null) {
// Call Handler's callback to process the message
if (mCallback.handleMessage(msg)) {
// The message can be intercepted, after which handler. handleMessage cannot continue processing the message.
return; }}// Call Handler's handleMessage to process the message. Subclasses implement this method.handleMessage(msg); }}private static void handleCallback(Message message) {
// Callback in Message is Runnable, and runnable.run () is executed directly.
message.callback.run();
}
/** * Callback interface you can use when instantiating a Handler to avoid * having to implement your own subclass of Handler. */
public interface Callback {
/ * * *@param msg A {@link android.os.Message Message} object
* @return True if no further handling is desired
*/
// The Handler callback method that returns a value for message interception.
public boolean handleMessage(Message msg);
}
/** * Subclasses must implement this to receive messages. */
// Handler handles message callbacks, which subclasses need to implement.
public void handleMessage(Message msg) {}Copy the codeThe distribution of messages is prioritized:
- The first consideration is to hand over
Message.callbackTo process if it is throughpostMessages sent by a series of functions will go here to be processed while passing throughsendBy default, messages sent by a series of functions do not have this callback interface; - if
Message.callbackIf it doesn’t exist, consider giving itHandler.callbackIn the process, messages can be intercepted by returning values; - if
Handler.callbackDoes not exist or does exist but is not intercepted during the processing of the messageHandler.handleMessageThis interface requires subclass implementation and is the most commonly used place to process messages in practice.
Here, the transmission process of the message is basically finished, we can combine the previous flow chart carefully figure out, I believe it can be rightAndroidBetter understanding of messaging mechanisms.
4. Expand your knowledge
4.1 Main thread message loop creation
Said before there is no message queue a thread by default, cannot open in its internal message loop, but we directly in practical work often used in the main thread Handler for message sending and processing, and normal operation, this is because the main thread has created message queue at start-up time and open the message loop, It’s just that the process is transparent and we don’t perceive it.
Those of you who know the Activity startup process already know where the creation process is. That’s right, in ActivityThread. Don’t worry if you don’t know the startup process. Here, you can simply use the ActivityThread as the entry point for your Activity and look directly at the entry function:
/支那* This manages the execution of the main thread in an
* application process, scheduling and executing activities,
* broadcasts, and other operations on it as theactivity * manager requests.
* * {@hide}
* /
public final class ActivityThread extends ClientTransactionHandler {
public static void main(String[] args) {
// Record start for subsequent systrace checking and debugging of performance issues.
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
// omit extraneous code
// Create a message queue for the master thread
Looper.prepareMainLooper();
// omit extraneous code
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// You can use systrace to observe the code execution.
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
// Start the message loop
Looper.loop();
// The main thread message loop does not exit, if this means an accident, throw an exception.
throw new RuntimeException("Main thread loop unexpectedly exited"); }}Copy the codeThe code structure is similar to the generic Android message mechanism example, where you see the creation of a message queue and the opening of a message loop. The difference is that the main thread creates a message queue using Looper. PrepareMainLooper:
/支那* Initialize the current thread as a looper, marking it as an
* application's main looper. The main looper for your application
* is created by the Android environment, so you shouldnever need * to call this function yourself. See also: {@link #prepare()}
* /
public static void prepareMainLooper() {
// Start a message loop that cannot exit
prepare(false);
synchronized (Looper.class) {
if(sMainLooper ! =null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
// return the main thread looper objectsMainLooper = myLooper(); }}Copy the codeThe message loop created by the main thread cannot exit because it handles many important transactions, such as callbacks to the Activity life cycle. Exiting will result in an exception, which will be explained in more detail when we explain the Activity startup process.
4.2 Memory Leaks
Java garbage collection mechanism for each engaged in Java developers should not strange, we also know that not all object memory can be recycled in time, if the garbage collector to recycle some objects, but because they also by other object references, so these objects cannot be recycled, which is the main cause of memory leaks.
Is there a memory leak when you use Android messaging? Let’s start with a common usage:
public class MainActivity extends Activity {
private TextView mTextView = null;
private Handler mMyHandler = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// Initialize the controller
mTextView = (TextView) findViewById(R.id.sample_text);
// Initialize the Handler object
mMyHandler = new MyHandler();
// Start a delay message and mMyHandler executes after 3000ms.
mMyHandler.sendEmptyMessageDelayed(0.3000);
}
private class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
// Execute a message to update the control in the main thread.
if(mTextView ! =null) {
mTextView.setText("execute message"); }}};@Override
public void onDestroy(a) {
super.onDestroy(); }}Copy the codeIn this example, MyHandler is in the form of the Activity’s internal class, so mMyHandler needs to hold a reference to the external class object, and mMyHandler is referenced as a target by the Message object it sends. The end result is that the Activity is referenced indirectly by Message. Since this Message needs to be executed after a certain amount of delay, if the Activity exits before then, but its reference is held by Message, it cannot be reclaimed by the system, resulting in a memory leak.
Since the Activity is leaking memory by being referenced by Message, is there a way to keep it from holding the reference? Of course, this can be avoided by using a “static inner class”, because a “static inner class” does not need to hold a reference to an external class object.
public class MainActivity extends Activity {
private TextView mTextView = null;
private Handler mMyHandler = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTextView = (TextView) findViewById(R.id.sample_text);
// Initialize the Handler object and pass in the main thread as a parameter.
mMyHandler = new MyHandler(mTextView);
// Start a delay message and mMyHandler executes after 3000ms.
mMyHandler.sendEmptyMessageDelayed(0.3000);
}
private static class MyHandler extends Handler {
// Hold external object variables by weak reference.
private WeakReference<TextView> mTextViewRef = null;
// Initializes the weak-reference object and holds the correct object reference thereafter.
public MyHandler(TextView textView) {
mTextViewRef = new WeakReference<>(textView);
}
@Override
public void handleMessage(Message msg) {
// Execute a message to update the control in the main thread.
if(mTextViewRef ! =null&& mTextViewRef.get() ! =null) {
mTextViewRef.get().setText("execute message"); }}};@Override
public void onDestroy(a) {
super.onDestroy();
// Messages in the exit message queue
mMyHandler.removeCallbacksAndMessages(null); }}Copy the codeThe combination of “static inner class” and “weak reference” allows you to access variables without holding references to external class objects, and to remove messages from the message queue when the Activity exits, further avoiding the risk of memory leaks.
This is just one of the ways to avoid memory leaks, but there must be other ways to do this as well, so you can explore for yourself.
5. To summarize
This article explains how to use the Android message mechanism, the overall process and the implementation principle of each stage, in the end also mentioned the main thread message loop creation and error use of memory leakage and avoid methods, hoping to help you learn the message mechanism.