Android app is killed by the system, androidkill

Android app is killed by the system, androidkill

When

When our app is switched to the background, for example, if the user presses the home key or switches to another app, our app will no longer interact with the user, this is the time when everything may happen to our app, because the system will think that you are not so important now, the app that is interacting with users has the highest priority. The system will try its best to ensure the normal operation of these apps. If these apps then apply for more resources, for example, when the current system conditions cannot be met in the memory, the system will take the background app for a knife, that is, it is very rude to kill the entire app process, at this time, you should not expect that the onDestroy and other callback will be triggered. The only thing you can expect is the onPause, onStop, onSaveInstanceState and other methods in the background, if you have a status to save, you should process it in these places, instead of sending it to onDestroy. It will disappoint you, and it is OK to release resources in this place. Because the system wants to kill the process, the next question is which process to kill. For this reason, the system has a dedicated module called LML (low memory killer). For details, refer to the official documentation. See here: processes-and-threads.

Switch back to app again

For example, when you leave the app, three act (A, B, C, and C) have been opened at the top, that is, the top of the task stack, A is your main activity. If the process is killed by the system in the background, if the user returns again (via recent tasks or directly click the app icon in launcher ), at this time, you will see the reconstruction of the C activity, instead of starting A normally. The system also restored the original task stack, that is to say, the content in the stack is still A, B, C. If you press the back key to end C, then the system will help us recreate B, A is the same logic at the end of B. Note that if the app is killed by the user, A instead of C is returned when the app is started again. Remember that the system error causes the app to be killed, then the system will have the responsibility to help us recreate the act. For details about how to recreate an act, refer to the official document recreating-activity. After the code is switched back, although the act is rebuilt, if you use something like a singleton in your code to store some variable values, unfortunately, in this case, all fields in the single instance are changed to the default values (0, false or null), because you think, the process is killed, and all static fields are lost. Stackoverflow has this problem. For example, the static variable becomes null.
At present, the author has a similar structure in the maintained code, and there are some similar problems online. It's really a pain. I'm going to get rid of this Singleton datakeeper statement, there are several ideas:

How to simulate

Because the system background kill process has a certain degree of randomness, it is impossible for developers to wait for this situation to happen. We have to find a way to reproduce it quickly. The specific steps are as follows:

Steps for simulating background kill Processes

Refer to stackoverflow's question.