Overview of how Activities are killed by the system_问答_开发者

Can anyone give a short overview of the cases when and how an activity is killed by the runtime? I'd like to know the difference between the paused and stopped state. What could force the system to destroy a paused activity, exactly the same (low memory) reason as if it was stopped?

I think if an activity is paused because of an incoming phone call (which suddenly causes a low memory situation) the system simply prefers to release ressources of stopped activities. But how is that done? When does the system "kindly ask" the activity by calling fi开发者_Go百科nish() and when not, and when does onDestroy() still get called?

Most of what you asked is described pretty well by the documentation, but I think I can clarify a couple of things.

I'd like to know the difference between the paused and stopped state.

Visibility. The two states are distinct because a paused activity may only be partially obscured by another activity such as one that's had the Dialog theme applied. That requires keeping whatever resources are needed to maintain visual state. Stopped activities can jettison those resources which could make the difference between the activity being destroyed or preserved if resources are tight.

I think ... the system simply prefers to release ressources of stopped activities. But how is that done?

It has to. Stopped activities are completely invisible, which makes them better candidates for killing than those that are still contributing something to what the user sees. I've never seen Android yank a paused-but-partially-visible activity out from under one that's resumed, but I suppose it could happen under the right circumstances. The system knows each activity's state because it's what's directing them there.

When does the system "kindly ask" the activity by calling finish() and when not, and when does onDestroy() still get called?

The system will do orderly destruction when it can, but the API only guarantees are that an activity will ever see onPause() and onSaveInstanceState().

ETA: The exact reasons why activities are removed from the stack are in the source. You shouldn't depend on those reasons being universal truth, because there may be a future version of Android that makes its decisions differently.

Par for the course, I see! I see some valuable information, mixed with expensive misinformation. No, the online docs do NOT every specify exactly under what circumstances the process is killed. This is deliberate, since it is subject to change without notice. Sure, the most common reason for onDestroy() to be called is that the system is running out of memory, which is less common on newer phones (since they have so much memory). But there is no guarantee that that be the ONLY reason it is called.

But yes, the 'contract' between Android and the developers is that if you follow the rules, implementing the needed lifecycle callbacks when they are needed, then it will work, and you do not NEED to know exactly under what circumstances onStop(), onSaveInstanceState() and onDestroy() are called.

Now unlike Google, I will admit that the wording of the contract is somewhat vague at points. This is because, among other lesser reasons, they use terms that have a standard industry meaning, such as 'foreground', but they use them in slightly altered senses. And the alteration is either never explained or explained only in obscure places. It also doesn't help that the diagram purports to show "the paths an activity may take between states", yet fails to show that onDestroy() can be called at many times, even bypassing the transition from Resumed to Stopped. Yet the text clearly describes that possibility.

This is why, unfortunately, reading the Application Lifecycle section of "Application Fundamentals" is simply not enough. Instead, one must also read the Javadoc for EACH of the callbacks under that for Activity, and also the section of "Application Fundamentals" on Processes.

After that, it is enormously helpful to put Log.d statements in each of the callbacks and watch the logcat output while you cycle your application through the lifecycle. But even then, do not rely on lifecycle events taking place in the order you see in logcat unless you can find justification for it in one of these online docs mentioned above.