我不清楚操作系统"破坏"某项活动时的情况。

让我解释一下原因 - 在此处的活动生命周期图表中：http：//developer.android.com/reference/android/app/Activity.html

有一个箭头直接从onStop()转到'App process killed'然后是一个箭头从'App process killed'到OnCreate()。

因此，该图表明，如果操作系统由于内存限制等而导致活动被杀死，则不会调用onDestroy()。

然而，在生命周期的描述中，"destroy"这个词被多次使用。例如，此页面的以下引用：http：//developer.android.com/training/basics/activity-lifecycle/recreating.html

The system may also destroy your activity if it's currently stopped
and hasn't been used in a long time or the foreground activity
requires more resources so the system must shut down background
processes to recover memory.

因此，文档说该活动在图中箭头从onStop()到onCreate()并绕过onDestroy()被销毁。这就是我感到困惑的原因，因为它显然是一个矛盾。

如果我有一个在onCreate()方法中创建一些对象的活动，并且我在onDestroy()中将它们设置为null，但是如果应用程序从onStop()移动到onCreate()，则不会调用onDestroy()，那么我不会内存泄漏，因为它们将在onCreate()中再次创建？

我无法在onStop()中将它们设置为null，因为如果生命周期从onStop()移动到onRestart()到onStart()，它们将为null。

因此，为了处理生命周期图中的所有路径，如何处理在活动中创建和销毁子对象的正确顺序？
在onCreate()中是否有必要仅在它们为null时才创建对象而不是其他？

This diagram therefore shows that onDestroy() is NOT called if the OS kills the activity due to memory constraints etc.

有问题的箭头标有"优先级较高的应用程序需要内存"。因此，此图表显示，如果操作系统终止进程，则不会调用onDestroy()，因为具有较高优先级的应用程序需要内存。在其他情况下，Android会更轻柔地终止应用程序的进程，在这种情况下，Android会花时间在您的活动上调用onDestroy()。在其他方案中也会调用onDestroy()，例如finish()，BACK按钮的默认行为，配置更改的默认行为等。

If I have an activity which creates some objects in its onCreate() method and I set them to null in onDestroy() but onDestroy() is not called if the app moves from onStop() to onCreate() then won't I have a memory leak as they will get created again in onCreate()?

不，因为"如果应用程序从onStop()移动到onCreate()"，整个过程将终止。尽管文档中的一些陈述恰恰相反，Android并不会因内存不足而破坏个别活动。

Therefore how does one deal with the correct sequence of creating and destroying of child objects within an activity in order to deal with all paths in the lifecycle diagram?

应该在onStop()之前或之前清理很多东西。具体来说，您正在做的任何事情都可能导致用户后悔安装您的应用程序，例如请求GPS修复，应考虑在onPause()或onStop()中进行清理。

对于那些你确定应该在onDestroy()中清理的东西，请这样做。 AFAIK，只有三种可能性：