Open source address:Github.com/long8313002…

Usage Guidelines:

build.gradle

Implementation "com. Zhangzheng. CrashProtect: crashProtect: 0.0.1." "Copy the code

Application

class MyApplication :Application(){      override fun attachBaseContext(base: Context?) {        super.attachBaseContext(base)          CrashProtect.protectApp(this)    } }
Copy the code

An overview of the

When an exception occurs, we usually have two solutions to deal with it. The first one is to capture it and make compatible processing, which needs to be analyzed according to the specific situation of different businesses. The other one is to throw it directly to the VIRTUAL machine and kill the entire APP process. Either way, however, there are downsides. The first is that it makes development more expensive, code less concise, and less readable (some say try.. Catch affects performance, very little in real tests, but it may affect how the virtual machine optimizes the code). The other is definitely affecting the user experience.

Is there a way to improve the user experience without degrading code quality in between? In fact, based on the Android operating mechanism, let’s discuss a protection scheme based on page crash. To summarize: when a page fails, the entire application does not exit, only the current page exits.

Page Exception Classification

Abnormal Activity startup

From the start of an activity to the execution of its life cycle, this part of the process is controlled by the system. Even if we try startActivity… A catch is also useless (startActivity simply initiates the request to ActivityManagerService, and AMS notifies the app process when the request is processed). When this happens, there is no doubt that we need to close the exception page

Page event exception

The most common of these are view action events, such as button clicks. Logically, if an exception occurs during a click, we simply ignore the exception and forget about it. However, it is risky to do this. Think about it. If an exception occurs halfway through the process, the previous process has changed the state of the page, and the subsequent process will become unpredictable. So the exception strategy is: close the problem page

Page thread exception

Page initiated threads, because multithreading itself needs to consider security issues, so “page event exception” encountered in the problem, here can not be considered. So for page thread exceptions, our policy is to ignore them

supplement

In addition to the above cases, there may be other logic execution (e.g., system spontaneous logic, broadcast, delayed task), and we need to take care of the exception:

1. Determine that the abnormality occurs at the user code level rather than the system code (abnormal interruption in the system code will lead to an unstable state of the whole system, in which case the APP needs to be terminated immediately)

2. Match the task stack where the exception occurred, and if it does not match the Activity at the top of the stack, terminate the APP immediately. (If an exception is caused by an Activity in the middle, such as a delayed task, it would be strange to just terminate the Activity.)

The core code

Abnormal events

The core code is looper.loop (), and the Android system runs on an event-driven basis, essentially an endless loop, which I prefer to call an “engine.” I’ve simplified the loop() code, keeping only the core logic.

A typical production consumer model blocks when there are no events and passes them to a Handler when an event arrives.

When a crash occurs, loop() gets an exception and exits the loop. So what I did was catch the exception and get it going again! In order to control the exception protection process, I use recursion to make it run again.

Start the abnormal

This part of the implementation is to replace the Instrumentation agent, involved in the knowledge point of the main Activity start process, if not familiar with it, you can find information to understand. The proxy classes are as follows:

Use try.. Catch to protect, nothing special. However, since Android P later limited the system API, so the use of meta-reflection for processing.

Abnormal thread

This method is so common that all methods that catch system exceptions are segregated for threads and child threads are ignored. However, if a thread’s exception ends up in system code, it kills itself