What is the essential difference between Android main thread crash and child thread crash? How do you deal with it?

What is the essential difference between Android main thread crash and child thread crash? How do you deal with it?

[[358857]]

Question and Answer Session

Q: What is the essential difference between an Android main thread crash and a child thread crash?

A: The child thread crash is just like a normal Java thread. By using setDefaultUncaughtExceptionHandler, you can capture the exception of the corresponding child thread in ThreadGroup for subsequent processing (starting an independent process to remind the user and report to the platform, etc., or ignoring specific exceptions as if they did not happen through policy issuance). There is a slight difference between the main thread crash and the child thread crash in Android. Although both can be captured by setDefaultUncaughtExceptionHandler, there is actually a little trick behind this. After the Android main thread is started, it maintains a pipeline-blocking producer-consumer dead loop through MainHandler's Looper.loop(), and all main thread codes are dispatched through this loop and executed in MainLooper. Therefore, when the main thread crashes, this loop will be jumped out, causing Looper to be unable to continue executing other Messages in it. Therefore, when the main thread crashes, there will be several different manifestations. One of the scenarios is that a crash in Activity's onCreate will cause a black screen in the interface (note that this crash is not anr, because an exception is thrown in onCreate, which prevents subsequent code from being executed, that is, the Activity lifecycle framework code cannot continue, and subsequent Messages cannot be dispatched normally, so the interface is black before it comes out), while a crash in the View click event response may not result in a black screen (it may, depending on what operation is done), but subsequent Messages cannot be dispatched normally.

Extension session <br /> Q: What are your thoughts on the above description?

Answer: There is nothing to say about the child thread crash. Since the main thread crash will cause the Looper to exit, we can start a Looper.loop() with our own try-catch in the main thread to execute the main thread task. This is equivalent to replacing the Looper.loop() in the ActivityThread main with a loop() with try-catch. In this way, the loop will not exit after the main thread crashes, and the code can continue to execute. It's just that the scenario of the crash may be invalid. For example, the user clicks the button to set the copy and it crashes, and there may be no response after clicking it; at the same time, if there is a crash in the onCreate and other methods of the Activity started by clicking the button, it will cause a black screen, so this kind of crash needs to be treated differently (for example, reporting the exception and popping up a reminder box and directly killing the process, etc.).

The following is a simple implementation of the core code (the Activity life cycle is handled roughly and is only for demo):

  1. // Replace when Application starts
  2. new Handler(getMainLooper()).post(new Runnable() {
  3. @Override
  4. public void run() {
  5. // Every time it jumps, it will continue to loop again to ensure that it can loop forever
  6. while ( true ) {
  7. try {
  8. Looper.loop();
  9. } catch (Throwable e) {
  10. e.printStackTrace();
  11. // TODO Manually report errors to the exception management platform for interactive processing, etc.
  12. if (e.getMessage() != null && e.getMessage().startsWith( "Unable to start activity" )) {
  13. // TODO comes from Activity lifecycle crash, kill the process
  14. android.os.Process.killProcess(android.os.Process.myPid());
  15. break;
  16. }
  17. }
  18. }
  19. }
  20. });


Of course, for the crash black screen in the Activity life cycle method, in addition to judging the stack log method, we can also hook the mH main Handler of ActivityThread, entrust the Message handle function in it to our implementation, and then perform try-catch to capture it. If an exception is found, close the corresponding Activity or kill the app. In fact, there are ready-made open source libraries on the Internet for this solution, which you can refer to.

This article is reprinted from the WeChat public account "Coder Daily Question", which can be followed through the following QR code. To reprint this article, please contact the Coder Daily Question public account.

<<:  QQ 8.5 for iPhone officially released: Split-screen file viewing and new moods

>>:  WeChat, which has been criticized for so long, finally came up with a feature worth praising

Recommend

SAIC Motor delivered 750 “government reception vehicles” to the CIIE

(October 12, 2024, Shanghai) Today, the "Del...

3 things you didn't know about the MacBook Air's demise

Back in 2010, Apple launched a new version of the...

The love-hate relationship between development and testing

[[228041]] IT practitioners are always in dire st...

Android page rendering efficiency optimization practice

1. Current status of car series page layout rende...

Black coffee with dark chocolate, not bitter but sweet?

Coffee and chocolate are a classic combination. D...

Can microorganisms influence human thinking and behavior?

When it comes to microorganisms, many people have...

Liu Kunkun's 2021 Zero-Based Commercial Illustration Course, Phase 3 [HD]

Liu Kunkun's 2021 Zero-Based Commercial Illus...

A Guide to Hard-core Influencer Branding

There is no brand that doesn’t want to become a h...

iQOO Z7 review: great fun, long-lasting, and powerful

In recent years, it has become very difficult to ...