使用Android Profiler分析Handler非静态内部类隐式持有外部类的引用

一 问题起因

最近朋友在他们的项目中，在Activity中使用Handler方式进行网络接口请求，他觉得这种方式可能会引发内存泄露，但又说不上来为什么，没有有力的证据说服同事。

image.png

Handler一般用来进行线程之间的数据通信（如Android的子线程向主线程Main发送数据）。如果在Activity中创建一个非静态的内部类Handler，那这个Handler就会隐式地持有Activity的引用，引用链接如下：

MessageQueue –  Message –  Handler –  Activity

Handler创建之后，会被封装到Message对象中，放进MessageQueue队列里，循环等待被执行。假如因耗时操作等原因被阻塞了，在Message没有被消费掉，就跳出Activity，就会导致Activity无法被回收，内存泄露。

二 代码模拟

下面我们使用Android Profiler 来 分析定位内存泄露的过程。

大概步骤如下：

1. 首先，创建一个简单Android Java工程，里面有MainActivity和HandlerActivity，其中HandlerActivity用来模拟Handler的内存泄露问题
2. 使用Android Profiler来分析进入和退出HandlerActivity发生的内存泄露

AndroidStudio 版本是：

image.png

MainActivity很简单，就一个跳转按钮，代码如下

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button btnNext = findViewById(R.id.btnNext);

        btnNext.setOnClickListener(v -> {
            //点击跳到下一步
            HandlerActivity.startActivity(MainActivity.this);
        });

    }
}

activity_main.xml 如下:

HandlerActivity 中，也有一个按钮，点击按钮，开一个线程做耗时操作，模拟接口请求阻塞的情况。耗时结束时，发送一个回调到Handler的handleMessage方法中，代码如下

public class HandlerActivity extends AppCompatActivity {

    public static void startActivity(Context context) {
        context.startActivity(new Intent(context， HandlerActivity.class));
    }

    private Button mBtnStart;

    //定义Handler对象
    private Handler handler = new Handler() {
        @Override
        //当有消息发送出来的时候就执行Handler的这个方法
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Toast.makeText(HandlerActivity.this， "数据返回了！"， Toast.LENGTH_LONG).show();
            Log.i("tag"， "handleMessage -->" + Thread.currentThread().getName());
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        mBtnStart = findViewById(R.id.btnStart);
        mBtnStart.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                //点击按钮后，开始线程，请求数据。然后等待数据在handleMessage中回调
                processThread();
            }
        });
    }

    private void processThread() {
        //构建一个下载进度条
        Log.i("tag"， "processThread()-->" + Thread.currentThread().getName());
        new Thread() {
            @Override
            public void run() {
                Log.i("tag"， "run()-->" + Thread.currentThread().getName());
                //在新线程里执行长耗时方法
                longTimeMethod();
                //执行完毕后给handler发送一个空消息
                handler.sendEmptyMessage(0);
            }
        }.start();
    }

    //模拟下载文件的长耗时方法
    private void longTimeMethod() {
        try {
            Log.i("tag"， "longTimeMethod-->" + Thread.currentThread().getName());
            Thread.sleep(10000); //10秒钟
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

activity_handler.xml如下：

以上是简单项目的所有代码

三 Android Profile 定位分析

Android手机通过数据线接通电脑， 可以开发者调试模式， 将项目运行至手机(这里测试项目的包名是 com.lucky.handler)

image.png

image.png

App运行后，会出现MainActivity主页面(我们先保持在这个页面不要跳转)， 然后点开Android Studio 的Profiler

image.png

如果Session 窗口中，没有任何app进程，可以新建一个(要确保app启动了)

image.png

创建完成，加载一会，就会有内存情况分析出现(要在Session中选中可以分析的进程)

image.png

正常情况，点开Profiler就会出现上门的图，Session中的进程可以删除重新添加

接下来，点击MERORY区域:

image.png

这里有三种方式可以，我们使用 Captrue heap dump来分析内存泄露。

每点击一次Record，都会记录当前App内存情况，生成一个Heap Dump记录，所以app操作之后点击一次Record，内存情况记录会跟上一次有所不同的。

GC按钮图标是一个垃圾桶：

image.png

首先分析内存不泄露的情况：点击Mainctivity的跳转按钮，跳转到HandlerActivity , 然后点击HandlerActivity中的"开始请求"按钮，等待handleMessage回调后，退出HandlerActivity，回到MainActivity。然后回到Android Profile，执行一次GC按钮（模拟GC回收不可达的引用），再点击Record按钮，就会得到一个Heap Dump "记录1"

image.png

我们看到，Leaks 数量是0，说明没有因内存泄露不可以回收的引用。

接下来点击 MEMORY旁边的返回按钮：

image.png

我们继续操作内存泄露的情况。点击Mainctivity的跳转按钮，跳转到HandlerActivity , 然后点击HandlerActivity中的"开始请求"按钮，立马退出HandlerActivity，不等待handleMessage回调 ，回到MainActivity。然后回到Android Profile，执行一次GC按钮（模拟GC回收不可达的引用），再点击Record按钮，就会得到一个Heap Dump "记录2"

image.png

我们看到，即使执行了GC，也无法回收，仍然有一个内存泄露的引用

image.png

通过过滤器来查看，我们发现，这是一个Activity生命周期的引用。

我们保持在当前Mainactivity不动，等到10秒钟耗时结束后，我们再执行一次GC和Heap dump操作，得到记录3，会发现这个引用可以被回收了：

image.png

四 问题总结

通过以上分析，我们得出结论：

1. 如果耗时操作（例如接口请求）尚未执行完毕，就退出Activity，那么Activity就会引发内存泄露
2. 退出Activity后，Handler的handleMessage仍然可以正常回调，假如在这里面做UI的刷新操作，就会有崩溃的风险（因为activity已经退出了）

五 如何解决

正常情况下，如果接口正常回调完成，Activity是能够被回收的，如果遇到长时间的阻塞，且来回开启HandlerActivity，就会引发不可预估的风险。

1. 将Handler改成静态内部类方式，并用弱引用持有Activity，这样在内存吃紧的时候，是能够正常回收的。
2. 在退出Activity的时候，remove掉Handler，或者让Message被消费掉，引用自然会释放
3. 在Activity中进行网络请求这种方式已经不可取，可以充分利用MVVM架构，解耦的方式去优化代码，尽可能避免不要的风险