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

Marketing Promotion: Why didn’t “A Bucket” go viral?

Jia Zhangke's short film "A Bucket"...

What happened to the "spy whale" that can help people pick up mobile phones?

In 2019, a beluga whale suspected to be a Russian...

A shocking global volcanic eruption! The "pain" and "love" of Mount St. Helens

If you ask which volcano in the United States is ...

App Store submission review guide, worth reading!

Introduction: When uploading new products to the ...

How to use the popular TV series "The Ming Dynasty" to attract targeted fans?

There is never a shortage of hot topics on the In...

How does the wedding photography industry use TikTok? Case Study

"For wedding photos that only happen once in...

Xiaohongshu’s marketing mechanism for pushing popular articles!

This article analyzes the hottest articles on Xia...

Find the perfect platform 8 APP testing solutions

Testing applications is very cumbersome. Where ca...