前言
内存泄露：生命周期长的对象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中的<b>IBinder</b> key就是AMS中的ActivityRecord中 <b>IApplicationToken.Stub</b>在Binder驱动中的代理对象。用于甄别<b>ActivityRecord</b>和<b>ActivityClientRecord</b>的对应关系。以达到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泄露</b>
二、分析nextIdle的使用
- 赋值
在handleResumeActivity()方法中将caller中的ActivityClientRecord赋值给target ActivityClientRecord中的nextIdle
- 赋值
-
- 置空
在handleResumeActivity添加Idle
在Idle中置空nextIdle
<b>小结:
nextIdle在新Acivity的创建时,caller的ActivityClientRecord作为的nextIdle赋值给了新的ActivityClientRecord。
在target Activity onResume后添加一个IdleHandler去置空nextIdle.</b> - 置空
原因分析
猜测
结合ActivityClientRecord在ActivityThread中的使用，猜测是IdleHandler没有执行导致target Activity 的ActivityClientRecord中nextIdle没有置空导致。验证
在LoadingPageActivity启动的MainActivity的onCreate()方法中添加一个IdleHandler(Looper.getMainLooper().myQueue().addIdleHandler(new IdleHandler());
果然IdleHandler的回调方法queueIdle()没有执行。-
原因
- MainActivity 中handler一直有post Runnalbe
- MainLooper 不会进入wait message
- 导致 ActivityThread 的 IdleHandler没有执行
解决方式
定位到Activity泄露的原因，解决就不复杂了。
IdleHandler没有执行说明MainLooper中一直有消息，不会出现wait message的情况。
跟踪android.os.Looper中的looper()方法,发现多个msg.target打印了同一个Handler，而且是不间断的打印。
分析<b>Handler，定位到MainActivity.onCreate()中某一个逻辑是通过Handler轮询某一个对象是否创建，为空就handler.post(Runnable)在下一个message中再次检测。在某个条件下这个对象会一直为null，导致handler.post(Runnable)一直不间断执行，从而出现MainLooper不会出现wait message。
换一种逻辑实现轮询检测对象为空的实现。LoadingPageActivity的泄露问题就解决了。
