前言

内存泄露：生命周期长的对象A引用了生命周期短的对象B。生命周期短的B对象已经完成了使用，原本可以被GC回收，但被生命周期长的对象A引用，导致不可被GC回收，从而出现B对象泄露。

常见原因：

1. 对象被静态变量引用；
2. 被Application的成员变量引用；
3. 被长时间运行的Thread引用。

影响：

1. 频繁触发GC,导致应用卡顿
2. 出现OutOfMemoryException，OOM导致功能不可用或应用crash

Activity泄露

现象

通过AS的Leaked Activities 工具得到的数据

产生原因：

Activity被ActivityThread中的nextIdle(ActivityClientRecord)引用而出现了泄露！！！这个就有点意思了……

常规分析:

1. 分析AndroidManifest配置；
2. 分析Activity的引用；
3. check Activity的逻辑;

没有发现可疑的逻辑。
百度，google一番，没有发现有相同或类似的现象。

ActivityThread源码分析

既然Activity是中ActivityThread中引用而导致泄露的，那就从ActivityThread的源码分析着手。

一、Activity的引用分析

Activity在ActivityClientRecord中的引用

(1) ActivityClientRecord中有nextIdle的引用
(2) ActivityClientRecord中有Activity的引用
ActivityClientRecord的作用

(1) ActivityRecord是Activity在ActivityManagerService中ActivityStack中的数据结构，AMS通过ActivityRecord管理Activity的生命周期和状态。

(2) ActivityClientRecord则是应用进程对应ActivityRecord的数据结构。每一个没有destroy的Activity在ActivityThread中都有一个ActivityClientRecord。
ActivityClientRecord在ActivityThread中的引用

(1) mActivities是一个ArrayMap,key是IBiner对象。IBinder除了用于IPC，还有一个作用是甄别不同进程的对象映射。

(2) mActivityes中的IBinder key就是AMS中的ActivityRecord中 IApplicationToken.Stub在Binder驱动中的代理对象。用于甄别ActivityRecord和ActivityClientRecord的对应关系。以达到AMS中Activity的状态和本进程Activity状态同步。
ActivityClientRecord中Activity的赋值

方法调用：

(1) ActivityThread.handleLaunchActivity()

(2) ActivityThread.performLaunchActivity()

在performLaunchActivity中将新创建的Activity赋值到ActivityClientRecord中的activity。
ActivityClientRecord的存储到mActivities

方法调用：

(1) ActivityThread.handleLaunchActivity()

(2) ActivityThread.performLauncherActivity()

在performLaunchActivity中将ActivityClientRecord put到mActivities
ActivityClientRecord从mActivities中移除

方法调用：

(1) ActivityThread.performDestroyActivity()

将ActivityClientRecord从mActivities中移除

小结: mActvities中的ActivityClientRecord会在Activity的创建时添加，在destroy中移除。如果Activity调用了onDestory()方法，ActivtyClientRecord中引用的Activity的不会导致Activity泄露

二、分析nextIdle的使用

1. 赋值
  
  在handleResumeActivity()方法中将caller中的ActivityClientRecord赋值给target ActivityClientRecord中的nextIdle
1. 置空
 
 在handleResumeActivity添加Idle
在Idle中置空nextIdle

小结:
nextIdle在新Acivity的创建时,caller的ActivityClientRecord作为的nextIdle赋值给了新的ActivityClientRecord。

在target Activity onResume后添加一个IdleHandler去置空nextIdle.

原因分析

猜测

结合ActivityClientRecord在ActivityThread中的使用，猜测是IdleHandler没有执行导致target Activity 的ActivityClientRecord中nextIdle没有置空导致。
验证

在LoadingPageActivity启动的MainActivity的onCreate()方法中添加一个IdleHandler(Looper.getMainLooper().myQueue().addIdleHandler(new IdleHandler());

果然IdleHandler的回调方法queueIdle()没有执行。
原因
1. MainActivity 中handler一直有post Runnalbe
2. MainLooper 不会进入wait message
3. 导致 ActivityThread 的 IdleHandler没有执行

解决方式

定位到Activity泄露的原因，解决就不复杂了。

IdleHandler没有执行说明MainLooper中一直有消息，不会出现wait message的情况。
跟踪android.os.Looper中的looper()方法,发现多个msg.target打印了同一个Handler，而且是不间断的打印。
分析Handler，定位到MainActivity.onCreate()中某一个逻辑是通过Handler轮询某一个对象是否创建，为空就handler.post(Runnable)在下一个message中再次检测。在某个条件下这个对象会一直为null，导致handler.post(Runnable)一直不间断执行，从而出现MainLooper不会出现wait message。
换一种逻辑实现轮询检测对象为空的实现。LoadingPageActivity的泄露问题就解决了。