Activity内存泄露的分析和解决

前言

内存泄露：生命周期长的对象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的引用分析

1. Activity在ActivityClientRecord中的引用

   
   

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

2. ActivityClientRecord的作用

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

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

3. ActivityClientRecord在ActivityThread中的引用

   
   
   (1) mActivities是一个ArrayMap,key是IBiner对象。IBinder除了用于IPC，还有一个作用是甄别不同进程的对象映射。
   
   (2) mActivityes中的IBinder key就是AMS中的ActivityRecord中 IApplicationToken.Stub在Binder驱动中的代理对象。用于甄别ActivityRecord和ActivityClientRecord的对应关系。以达到AMS中Activity的状态和本进程Activity状态同步。

4. ActivityClientRecord中Activity的赋值
   
   方法调用：
   
   (1) ActivityThread.handleLaunchActivity()
   
   (2) ActivityThread.performLaunchActivity()
   
   在performLaunchActivity中将新创建的Activity赋值到ActivityClientRecord中的activity。

5. ActivityClientRecord的存储到mActivities

   方法调用：
   
   (1) ActivityThread.handleLaunchActivity()
   
   (2) ActivityThread.performLauncherActivity()
   
   在performLaunchActivity中将ActivityClientRecord put到mActivities

6. ActivityClientRecord从mActivities中移除

   方法调用：
   
   (1) ActivityThread.performDestroyActivity()
   
   将ActivityClientRecord从mActivities中移除

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

二、分析nextIdle的使用

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

   在Idle中置空nextIdle

   
   小结:
   nextIdle在新Acivity的创建时,caller的ActivityClientRecord作为的nextIdle赋值给了新的ActivityClientRecord。
   
   在target Activity onResume后添加一个IdleHandler去置空nextIdle.

原因分析

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

2. 验证
   
   在LoadingPageActivity启动的MainActivity的onCreate()方法中添加一个IdleHandler(Looper.getMainLooper().myQueue().addIdleHandler(new IdleHandler());
   
   果然IdleHandler的回调方法queueIdle()没有执行。

3. 原因

   1. MainActivity 中handler一直有post Runnalbe
   2. MainLooper 不会进入wait message
   3. 导致 ActivityThread 的 IdleHandler没有执行

解决方式

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

1. IdleHandler没有执行说明MainLooper中一直有消息，不会出现wait message的情况。

2. 跟踪android.os.Looper中的looper()方法,发现多个msg.target打印了同一个Handler，而且是不间断的打印。

3. 分析Handler，定位到MainActivity.onCreate()中某一个逻辑是通过Handler轮询某一个对象是否创建，为空就handler.post(Runnable)在下一个message中再次检测。在某个条件下这个对象会一直为null，导致handler.post(Runnable)一直不间断执行，从而出现MainLooper不会出现wait message。

4. 换一种逻辑实现轮询检测对象为空的实现。LoadingPageActivity的泄露问题就解决了。