I have been engaged in Android development for some time. I believe that many Android programmers developed from Windows will habitually encounter the same problem as me: how to exit the program completely? My own experience is not authoritative and is for reference only.
At the beginning, I also searched for exit information on the Internet. There were also many articles on the Internet. The methods to exit the android program are as follows:
1. directly call system. Exit (0) or directly use Android. OS. process. killprocess;
2. Call activitymanager. restartpackage or killbackgroudprocesses;
3. Create an activity stack list, record all the activities by inheriting the base class or calling the function, and finish them one by one when exiting;
4. intentionally create a fatal error and use the error to force exit;
5. Create a singletop root activity through which the activity stack is automatically cleared and then exited;
6. Call the hidden activitymanager. forcestoppackage Method
However, these methods are basically not perfect after the test, or they are not clean, or they only support old versions earlier than 2.2, or they require root permissions. Among them, system. Exit (0) and Android. OS. process. killprocess can end the current activity. Sometimes the current activity and the previous activity can be ended, but it will basically not work if there are more.
The perfect solution is to release the activity stack list by myself. I also used this method for a while. I think it is good. The problem seems to be solved, but it is quite uncomfortable to solve it, make the activity stack by yourself, which means that each activity must inherit the same parent class. When I debug a program while cursing Google, why can't you provide an easy-to-use exit interface?
It was not a long time before I found that the program only ended the activity, but the program did not exit. There were several threads running in the background. After exiting, an error was prompted after a long time, it's really disappointing. I want to ask the program to wait for a thread before exiting. I found that these threads were not created by myself, but downloaded data in the background using a third-party map component. Finally, I took over thread. uncaughtexceptionhandler and cut down the error and did not display it.
Originally, we ended the activity interface, but after the interface, as long as there is a thread running, the program is still running, it can be said that the horse ran and danced. After the activity is closed, the interface disappears, and other things are carried out as usual. If there is a network request in the thread, the CPU and bandwidth are still occupied.
Continue to study and find an interesting phenomenon. After the program exits, start the program again and find that the global variables declared using public static have not changed. What does it mean? For example, if your mainactivity has a global static variable public static int C, the default value is 0. When the program is started for the first time, you set it to add 1 in oncreate, execute C ++ = 1 or C ++. Then you close the program and immediately start the program again. At this time, the value of C is still 1 and the value of C is not 0, after executing C ++ = 1, it will become 2. Then you can open and close the program without stopping, and you will find that the value of C is continuously increasing.
Then we will naturally study the Android Application, because it is said that the application is unique in the program and is suitable for placing global variables. I created and used my own application class in the program, and then put global static variables in it for the assignment test. The result is still the same-the system did not clear the global variables when the program was closed and started again.
So I wrote the startup log in oncreate of the application (it also has an onterminate event, but after reading the help, I realized that the event was false, oncreate is actually called only at the first startup, and the application is not re-created at the second startup. What does it mean? Sadly, our program didn't quit at all.
After our activity was closed, the program did not end. In fact, our end program was just shown to ourselves. In essence, the program did not exit, and the program was always in the background, it will never automatically exit unless you end with a task manager with root permissions.
Of course, all of the above experiments are conducted when the memory is sufficient. Although the program will not exit, the system will still be exited when the memory is cleared. Because Google does not provide the exit function, it is obvious that Google wants us to know that you don't have to take the initiative to exit the program. I will help you exit when necessary.
For PC programmers who are used to exiting, this is really unreasonable. Why do you need to occupy valuable memory when I quit? It may even occupy other resources. I didn't understand it at the beginning, but I thought it would not matter if the memory occupied. As long as the CPU was not occupied, it would be a waste of time and space, and it would not consume any power at all, the current loading speed can be increased, and the memory can be automatically cleaned up when the memory is insufficient. This is not a problem. If you cannot withdraw, you will not be able to quit.
Then another thing happened, which made me have different views on the android activity and memory mechanism. My colleague has a mobile phone sent by China Telecom with a poor configuration and only a few hundred MB of memory. I ran my program on it and found a strange phenomenon: in the program, I successively opened three activities that contain the edit box A, B, and C. In addition, all three activities have different content. Currently, C is displayed; then I press the Home Key, make a call, and then use the task manager to switch back to the program. At this time, the program shows that it is actually the original activity C, but the content in the above edit box disappears; return to B and A and find that the editing content of B and A disappears. That is to say, the stack sequence of A, B, and C is still there, but the status of the interface is lost.
There is such a magical thing in the world. After careful debugging, you will know that when you press the Home Key to call back to the program, the oncreate of the program activity will be called again, the program re-creates activity C.
Further research found that not only activity C, but also two other activities A and B were re-created.
After further research, we found that even the application was re-created, and all global variables were cleared. This is exactly what I originally wanted to exit. It came out when I didn't need it, and it was just ironic.
At this point, the system automatically ended my program due to insufficient memory when I pressed the Home Key and recorded the activity stack before the end, the onsaveinstancestate of the activity and the onlowmemory of the application will be called to give the program the opportunity to save the data. When the program is returned again, the system will automatically re-create the application and restore Activity C in the stack order; however, at this time, A and B may not be restored. That is to say, we usually think that the assumptions of Activity A and B following C are really false. In fact, they do not exist, but they only exist in a stack; all interfaces and global variables except the top-level activity have been cleared.
After learning about this, I found that the previous exit operations are full of cloudification. On the contrary, our exit operations will not only be good, but also cause unexpected confusion. In this case, we do not make any sense to exit the program through stack.
In the end, I had to surrender. My program had to quit without any further work. I will mark the exit of the root activity. The next time I come in, I will automatically clean up and set some global variables, even if the program is restarted. Want to exit the program? I don't think it is necessary to exit the new APIs of Google.
By the way, the program crashes. For some time, I want to use the crash mechanism to exit the program. Finally, I found that the crash mechanism is similar to the system. exit (0) and Android. OS. process. like killprocess, killprocess can only end the current activity and may cause the re-creation of the current or previous activity to trigger the oncreate event. However, the entire program cannot be cleared, so you have to give up.