2019-02-19

# <center>Activity内存泄露的分析和解决</center>

## 前言

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

<p><b>常见原因：</b></p>

1. 对象被静态变量引用；

2. 被Application的成员变量引用；

3. 被长时间运行的Thread引用。

<p><b>影响：</b>

1. 频繁触发GC,导致应用卡顿

2. 出现OutOfMemoryException，OOM导致功能不可用或应用crash

## Activity泄露

### 现象

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


<b>产生原因：</b>

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

<p><b>常规分析:</b>

1. 分析AndroidManifest配置；

2. 分析Activity的引用；

3. check Activity的逻辑;

没有发现可疑的逻辑。

<br>百度，google一番，没有发现有相同或类似的现象。

## ActivityThread源码分析

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

#### 一、Activity的引用分析

1. <b>Activity在ActivityClientRecord中的引用</b>


<br>(1) ActivityClientRecord中有nextIdle的引用

<br>(2) ActivityClientRecord中有Activity的引用

2. <b>ActivityClientRecord的作用</b>

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

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

3. <b>ActivityClientRecord在ActivityThread中的引用</b>


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

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


4. <b>ActivityClientRecord中Activity的赋值</b>

<br><b>方法调用：</b>

<br>(1) ActivityThread.handleLaunchActivity()

<br>(2) ActivityThread.performLaunchActivity()

<br>在performLaunchActivity中将新创建的Activity赋值到ActivityClientRecord中的activity。


  

5. <b>ActivityClientRecord的存储到mActivities</b>

<b>方法调用：</b>

<br>(1) ActivityThread.handleLaunchActivity()

<br>(2) ActivityThread.performLauncherActivity()

<br>在performLaunchActivity中将ActivityClientRecord put到mActivities


6. <b>ActivityClientRecord从mActivities中移除</b>

<b>方法调用：</b>

<br>(1) ActivityThread.performDestroyActivity()

<br>将ActivityClientRecord从mActivities中移除


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

#### 二、分析nextIdle的使用

1. <b>1. 赋值</b>

<br>  在handleResumeActivity()方法中将caller中的ActivityClientRecord赋值给target ActivityClientRecord中的nextIdle

  

2. <b>2. 置空</b>

<br>在handleResumeActivity添加Idle


  在Idle中置空nextIdle


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

<br>在target Activity onResume后添加一个IdleHandler去置空nextIdle.</b>

## 原因分析

<b>1. 猜测</b>

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

<b>2. 验证</b>

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

<br>果然IdleHandler的回调方法<b>queueIdle()</b>没有执行。

<b>3. 原因</b>

1. MainActivity 中handler一直有post Runnalbe

2. MainLooper 不会进入<b>wait message</b>

3. 导致 ActivityThread 的 IdleHandler没有执行

## 解决方式

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

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

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

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

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