今天，在Q群中有网友（@广州-包晴天）发出了网上的一个相对经典的问题，问题具体见下图。

本来是无意写此文的，但群里多个网友热情不好推却，于是，撰此文予以分析。

从这个问题的陈述中，我们发现，提问者明显对Android中的几个基本概念在理解上是存在误区的（或直接称之为理解错误）。且这种误区，我发现是较为广泛的存在于不少Android开发心中的。

理解误区主要体现在对以下几个概念没有区分清：

1，Activity的onDestory回调方法；

2，Activity的销毁；

3，Activity的内存回收；

4，内存泄露；

5，Activity中动态注册的BroadcastReceiver与Activity的引用持有关系。

下面我们来一个个具体分析下。

1，Activity的onDestory回调方法。

onDestory作为Activity中生命周期中的一个常见的方法，我们先来看一下官方文档中的描述。

从这个定义中，我们得出如下几点细节：

a，onDestory回调方法是Activity被销毁前的最后一个Activity中回调方法；

b，onDestory回调方法的触发时机是Activity被外部主动调用了finish()方法，或因系统内存空间不足而导致的临行性的销毁该Activity实例，以便获得内存空间。

在实际操作中，onDestory回调方法的触发时机（或称之为Activity销毁的触发时机）主要表现在如下四种情况：

a，人为的主动的调用了finish()方法，以期望去销毁当前的Activity；

b，人为的主动操作导致的系统去销毁当前Activity，如常见的按下手机上的返回键；

c，系统因内存不足导致的临行性的销毁该Activity实例，如从A Activity跳转到B Activity后，系统内存不足的情况下可能会销毁掉A Activity；

d，打开手机上的“开发者选项”中的“不保留活动”选项，其中，这个更多的是为了模拟出C场景，效果同C。

另外，上述的b中的按下手机上的返回键，系统源码中也是调用了finish()方法。

区分上述的ab与cd两种方式可以通过isFinishing()方法的返回值来判断。

为了行文方便，且从ab与cd的人为主观性角度出发，本文将ab情形称之为“主动销毁”，cd情形称之为“被动销毁”。

2，Activity的销毁。

相较于onDestory作为的Activity生命周期中的回调方法，“销毁”一词在Activity中更多的表示的是Activity所处声明周期中的一种“状态”。

处于此种状态的Activity实例，对于User Interface层来说是不再可见的（无论是当前界面还是按返回键等各种情况）。

实践中，处于“销毁状态”的Activity与上述的Activity销毁的触发时机具有一致的逻辑关系，这种逻辑关系具体体现为：

a，对于主动销毁，除却Activity实例不再可见外，当前Activity实例也直接被Activity栈中移除，直接表位为对用户操作导航路径的影响；

b，对于被动销毁，当前Activity实例依然不再可见，但与主动销毁不同的是，Activity实例的对应关系在Activity栈中依然存在，此时，对用户操作导航路径并无影响。

如B Activity中，A Activity虽然被动销毁，但未改变栈结构，按下返回键依然看到A，不够此时的A与之前的A并非一个Activity实例。

需要注意的是，处于“销毁状态”的Activity，严格意义上与当前Activity的真实内存占用是否释放没有直接的对应关系。也就是说，Activity的销毁，并不意味着Activity的内存就已经被回收。

3，Activity的内存回收。

Android是基于Java基础之上，虽然在内存回收机制等方面做了一定的处理与优化（主要是基于Dalvik/ART），但针基本的GC原理上并无差别。主要表现在：

a，对于一个堆内存中的对象空间，一旦还有其他的强引用可达，该内存空间就处于不可回收状态；

b，GC的触发时机依然具有不可确定性，取决于系统依据当前的运行状态与其系统本身的GC机制判定进行。

也就是说，即使堆内存中对象已经处于可回收状态，但只要GC未被触发，内存依然被占用。

在此，需要区分下GC的不可回收状态与可回收状态的区别，严格意义上来说，其并非对立面，因为针对可回收状态，还有可能对应的软引用与弱引用需要加以考虑。

4，内存泄露。

Android中，内存泄露作为一个基本的概念，常常被提及且实践中也需尽量掌握。网上关于内存泄露的文章林林总总。

终究内存泄露的本质，是指当前对象在实际运行中超出了其本身意义上生命周期范围的，从而导致本该处于内存可回收状态的但实际上却一直处于不可回收状态的内存占用非正常现象。

内存泄露在出现，常常见于如下两种情况（为行文方便，下述将发生了内存泄露的对象称之为M）：

a，因异步回调中持有M，异步回调本身的生命时长长于M本身而导致的M发生内存泄露（如最常见的是Activity中的Handler以及异步线程导致Activity本身发生内存泄露）；

b，因静态属性所指向的对象中持有了M而导致的M一直被强引用可达，使得M发生内存泄露（如最常见的单例对象中强引用了外部的非静态对象）。

内存泄露过多会导致应用内存的不断上升，达到一定程度会直接导致内存溢出（OOM）。具体解决内存泄露时，主要都是针对上述AB两种情况分析排查即可。

5，Activity中动态注册的BroadcastReceiver与Activity的引用持有关系。

对于Android中的广播机制，可以先参考文章：《Android总结篇系列：Android广播机制》

Activity中动态注册的广播接收器，一般性写法都是此Activity种持有创建的广播接收器的对象引用。并指明广播接收器对应的接收广播类型（IntentFilter）。

Activity中调用registerReceiver(mBroadcastReceiver, intentFilter)方法进行广播接收器的注册。此时，通过Binder机制向AMS(Activity Manager Service)进行注册。

AMS会对应的记录Activity上下文、广播接收器以及对应的IntentFilter等内容，并形成类似于消息的发布-订阅存储模式与结构。

当对应的广播发出时，在定义的广播接收器的onReceive(context, intent)方法回调中，对于Activity中动态注册的广播接收器，onReceive方法回调中的context指的是Activity Context！

也就是说，Activity与mBroadcastReceiver此时实际上是通过AMS相互持有强引用的。因此，对于Activity中动态注册的广播接收器，一定要在对应的声明周期回调方法中去unregisterReceiver，以斩断此关联。

否则，就会出现当前Activity的内存泄露。