Practical dry goods! Quickly locate and solve a new idea to solve a strange bug related to Handler

background

I recently took over a new project and encountered a bug related to Handler. It took a lot of time to solve it, and finally solved it through another idea.

Through this article, I share it with you, and also help you quickly locate and solve Handler-related problems later.

Problem Description

The problem is that the message sent by the Handler is not received in handleMessage.

Of course, the place where the message is sent and the place where the message is received are not the same file.

It can be considered that Handler is managed uniformly through HashMap.

Idea 1

Will the sent Handler and the received Handler be different?

After all, it is managed by HashMap, may it be replaced?

Verification method: Print the reference of Handler to confirm, the result is the same Handler.

Idea 2

Will the sent message be removed by remove?

Verification method: A new unique msg.what was introduced to confirm, but the result was not received.

Idea 3

    /**
     * Sends a Message containing only the what value.
     *  
     * @return Returns true if the message 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 sendEmptyMessage(int what)
    {
        return sendEmptyMessageDelayed(what, 0);
    }

Through the comments of the source code, it is found that if the message is already in the queue, it will not be stuffed again, but if the queue already exists, it should not be received.

Finally, it is correct to print the return value.

Although this idea did not solve the problem, because of this, another idea was opened, that is, will the queue be blocked and the message stuck?

Final verification method

Therefore, finally, IdleHandler is introduced to verify whether there is a problem with the message queue and there is no idle message callback.

Regarding the IdleHandler, let me briefly explain that it usually calls back when the Handler is idle. If you do not remove it after listening, it will always call back.

One of the usage is to delay initialization to improve the interface rendering speed.

For more information, see:

IdleHandler

Finally, it was confirmed that there is no callback when using IdleHandler in the thread (child thread) that sends the message, and the original Handler is built on the main thread.

Therefore, the root cause is that the thread of the Handler is modified, and the message of the sub-thread is continuously generated. The queue may be occupied all the time, so the newly sent message cannot be received.

Refined analysis of Android development related source code

With the gradual saturation of the Android development industry, the interview requirements for Android developers are getting higher and higher. Whether to master the underlying source code is an important part of testing an Android developer. When I was asked in the interview, I couldn't answer the source code question. I would lose my value, cut the salary and not even talk about it, and I could not even pass the interview!

There are various kinds of blogs on the Internet for source code analysis, good and bad. It's messy, or the content is too shallow, fragmented, and fragmented. It can't be connected when you look at it.

So I deliberately shared the "Android Development-Related Source Code Compilation and Analysis" that I spent 4 months during the epidemic.

Due to the large amount of content, to avoid affecting everyone's reading experience, here only screenshots show the catalog part, the 487 detailed and complete version of "Android Development Related Source Code Compilation and Analysis" e-book document collection method: like + follow my homepage scan plus WeChat privately sent to you (free of charge)~

Contents: A total of 18 sections, 487 pages of PDF, including MMKV source code, ARouter source code, AsyncTask source code, Volley source code, Retrofit source code, OkHttp source code, ButterKnife source code, Okio source code, SharedPreferences source code, EventBus source code, Android custom annotations preliminary study, View work Mechanism source code analysis, Android touch event distribution mechanism source code analysis, Android key event distribution mechanism source code analysis, in-depth analysis of Handler source code, in-depth analysis of Binder source code, in-depth analysis of JNI source code, and in-depth analysis of Glide source code.

How to get the e-book document of "Android Development Related Source Code Compilation and Analysis": The
above content  has been included in the open source project: [ github ] , and you can obtain it by yourself.

Guess you like

Origin blog.csdn.net/weixin_44339238/article/details/112285816