美文网首页
使用Android Profiler分析Handler非静态内部

使用Android Profiler分析Handler非静态内部

作者: 土豆海马 | 来源:发表于2022-06-16 21:49 被阅读0次

    一 问题起因

    最近朋友在他们的项目中,在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 如下:

    <?xml version="1.0" encoding="utf-8"?>
    <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".MainActivity">
    
        <Button
            android:id="@+id/btnNext"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_marginTop="40dp"
            android:text="跳转"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toTopOf="parent" />
    
    </androidx.constraintlayout.widget.ConstraintLayout>
    

    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如下:

    <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".HandlerActivity">
    
        <Button
            android:id="@+id/btnStart"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_marginTop="40dp"
            android:text="开始请求"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toTopOf="parent" />
    
    </androidx.constraintlayout.widget.ConstraintLayout>
    

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

    三 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架构,解耦的方式去优化代码,尽可能避免不要的风险

    相关文章

      网友评论

          本文标题:使用Android Profiler分析Handler非静态内部

          本文链接:https://www.haomeiwen.com/subject/swaqvrtx.html