What should I do if my application is killed?

What should I do if my application is killed?

The application is easy to be killed when running in the background. This is normal, but when you return to the foreground, it is easy to have a null pointer. How to solve this problem and check Stay's opinions.

 

Let's jump out and see how the android app runs.

The app is forcibly released when the memory is insufficient when it is killed in the background, some disgusting rom forces the background processes to release the cache to improve the user experience.

We all think android rom is disgusting, but at the same time, we still use more disgusting methods to bypass these bottlenecks. Chaos, because there is no good constraint at the top, which is also the disadvantage of open source. Anyway. We still have to break our heads to solve these problems, otherwise the job will be gone.

 

Let's reproduce this bug first:

 

Suppose: App A-> B-> C-> D

Run the Home Key in the background of activity D. Open ddms, select the App process, and kill it.

Select the App from the "recently opened application" and return to the page D activity. If there are no static variables in the App, the App will not crash at this time. Click "return to C, in this case, the C interface is displayed only after a black screen. However, if C references a static variable and wants to obtain a value in the static variable, it will be NullPointer.

 

The above reproduction process is just a few points. Let's talk about it:

1. When an application is killed, the entire App process is killed, and all the variables are cleared. Includes Application instances. Let alone those static variables.

2. Although the variables are cleared, Android provides some remedial measures. The activity stack is not cleared. That is to say, the stack A-> B-> C-> D is saved, but the activity instances of ABCD are gone. So when I return to the App, the page D is displayed.

3. In addition, when an activity is forced to kill, the system will call onSaveInstance to let you save some variables, but I personally think this is not enough for massive static variables.

4. Black screen will be returned to C because C needs to be re-painted and re-taken through the onCreate process. It takes some time for rendering, so black screen will be returned.

 

This is probably the above points. If the App does not reference static variables, you do not need to use the NullPointer crash. Once you have static variables or some Application global variables, it is very dangerous. Such as logon status and user profile. These values are empty.

 

Some people will say that it doesn't matter. Isn't it okay to change all the static variables to a Singleton? Then attach some persistent cache. If it is null, it will be OK to fetch the cache. Well, this is certainly also a method, but it is also a pain for development, at least 30% more coding time to cover all. In addition, there are so many teammates who help you dig holes, it's hard to worry about it.

 

Since the App has been forced to kill, why don't you go through the first startup process? Instead of letting the App go back to D, it starts A. In this way, all the variables are initialized according to the normal process, the pointer will not be null, right? Some people say that the user experience of this solution is not good at all. But what is perfect? Is it better to repeat the process or to repeat 1.1 NullPointer? We believe that the product will not be difficult for you. Of course, you can also take iOS as an example. If iOS kills an App in the recently opened App and clicks the App again, the process will be repeated.

 

If you accept my solution, think about how to repeat the process instead of going back to D? That is to say, the initialization of D is interrupted and return to A, and then press the back key. It does not return to D, C, and B. Think about it.

 

Let's instantiate this scenario first.

A is the App launch page

B is the logon page

C is the homepage

D is the second-level page

 

Let's briefly describe the solution, and let's think about it.

 

1. Set the launchMode of the homepage to singleTask. I will not talk about it, but google it myself.

2. In BaseActivity, onCreate checks whether the App is forced to kill. If it is forced to kill the App, it does not go down and directly repeat the App process.

3. The home page plays a role in undertaking or transferring, and all cross-level jumps must be completed through the home page.

 

Again, the solution for the above scenarios can be used to solve other problems:

1. Exit the App on any page

2. Return to the home page on any page

3. log out on any page or return to the logon page if the token is invalid.

 

In fact, the most important knowledge point is launchMode, which can be carried out by many people during the interview, or even the principle. But few of them will actually be used properly. Sometimes, the advantages and disadvantages of technology are embodied in this. It must be unable to reach the highest point.

 

Digress:

When I encountered this problem for the first time, I was wondering why Android had to do so. Since all applications had been killed, why did I save the stack information. Since the stack information is saved, why not cache the entire App variable on the hard disk. In this way, ram can be saved, and the maximum memory allocated to each running App does not need to be limited. In this case, the OOM of Bitmap is also very difficult. How nice. Well, iOS memory management seems to be like this (I am a white talk, do not be honest)

 

There are many bugs that are system-level restrictions. Although there is no technical solution that can't be solved, it is necessary to solve the problem in self-thinking ways, so it is just a pitfall of yourself and teammates.

 

The longer you develop technology, the more you can feel that what is difficult is not technology, but business. How to understand the business and the nature of the requirements behind it is the most important thing in development. Instead of blindly writing code based on requirements, it is better to take some time to understand the requirements. Find out the cause and effect, and think about encapsulation and expansion. These are the exercises of thinking logic and the fastest way to improve technology.

 

 

A thoughtful classroom is not just about technology. Www.stay4it.com