概述 Activity 如何被系统杀死
谁能简要概述一下活动何时以及如何被运行时终止的情况？我想知道暂停和停止状态之间的区别。什么会迫使系统销毁暂停的活动，其原因与停止的原因完全相同（内存不足）？
我认为，如果某个活动因来电而暂停（突然导致内存不足的情况），系统只是更愿意释放已停止活动的资源。但这是怎么做到的呢？系统什么时候通过调用 finish() 来“友好地询问”活动，什么时候不调用，以及 onDestroy() 何时仍然被调用？
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 finish() and when not, and when does onDestroy() still get called?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
文档中很好地描述了您提出的大部分问题，但我想我可以澄清一些事情。
能见度。这两种状态是不同的，因为暂停的活动可能仅被另一个活动（例如应用了
Dialog主题的活动）部分遮挡。这需要保留维持视觉状态所需的任何资源。停止的活动可能会放弃这些资源，如果资源紧张，这可能会导致活动被破坏或保留。必须如此。停止的活动是完全不可见的，这使得它们比那些仍在为用户所看到的内容做出贡献的活动更适合被杀死。我从未见过 Android 将已暂停但部分可见的活动从已恢复的活动中拉出，但我认为在适当的情况下可能会发生这种情况。系统知道每个活动的状态，因为它是引导它们到达那里的原因。
系统会在可能的情况下进行有序销毁，但 API 只能保证 Activity 会看到
onPause()和onSaveInstanceState()。ETA：活动从堆栈中删除的确切原因在源代码中。您不应该依赖这些理由作为普遍真理，因为 Android 的未来版本可能会做出不同的决定。
Most of what you asked is described pretty well by the documentation, but I think I can clarify a couple of things.
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
Dialogtheme 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.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.
The system will do orderly destruction when it can, but the API only guarantees are that an activity will ever see
onPause()andonSaveInstanceState().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.
当然，我明白了！我看到了一些有价值的信息，其中夹杂着昂贵的错误信息。不，在线文档并没有具体说明在什么情况下进程会被终止。这是故意的，因为它可能会发生更改，恕不另行通知。当然，调用 onDestroy() 的最常见原因是系统内存不足，这在较新的手机上不太常见（因为它们有这么多内存）。但不能保证这是调用它的唯一原因。
但是，是的，Android 和开发人员之间的“契约”是，如果您遵循规则，在需要时实现所需的生命周期回调，那么它就会起作用，并且您不需要确切地知道在什么情况下 onStop()，调用 onSaveInstanceState() 和 onDestroy()。
与谷歌不同的是，我承认合同的措辞在某些方面有些模糊。这是因为，除其他次要原因外，他们使用具有标准行业含义的术语，例如“前景”，但其含义略有不同。这种改变要么从未得到解释，要么只在不起眼的地方得到解释。该图声称显示“活动在状态之间可能采取的路径”，但未能显示 onDestroy() 可以多次调用，甚至绕过从 Resumed 到 Stopped 的转换，这也无济于事。然而文本清楚地描述了这种可能性。
不幸的是，这就是为什么仅仅阅读“应用程序基础知识”的应用程序生命周期部分是不够的。相反，还必须阅读 Activity 下每个回调的 Javadoc，以及“应用程序基础知识”中有关进程的部分。
之后，将 Log.d 语句放入每个回调中并在循环应用程序的生命周期时观察 logcat 输出将非常有帮助。但即便如此，也不要依赖按照您在 logcat 中看到的顺序发生的生命周期事件，除非您可以在上述在线文档之一中找到其合理性。
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.