使用 Memory Profiler 排查内存泄漏
内存泄漏和内存溢出
**Memory Profiler **是 Android Profiler 中的一个组件，可帮助您识别导致应用卡顿、冻结甚至崩溃的内存泄漏和流失。 它显示一个应用内存使用量的实时图表，让您可以捕获堆转储、强制执行垃圾回收以及跟踪内存分配。
shell命令查看内存情况：
adb shell dumpsys meminfo com.example.a.sample -d
图 1. Memory Profiler
如图 1 所示，Memory Profiler 的默认视图包括以下各项：
- 用于强制执行垃圾回收 Event 的按钮。
- 用于捕获堆转储的按钮。
- 用于记录内存分配情况的按钮。 此按钮仅在连接至运行 Android 7.1 或更低版本的设备时才会显示。
- 用于放大/缩小时间线的按钮。
- 用于跳转至实时内存数据的按钮。
- Event 时间线，其显示 Activity 状态、用户输入 Event 和屏幕旋转 Event。
- 内存使用量时间线，其包含以下内容：
一个显示每个内存类别使用多少内存的堆叠图表，如左侧的 y 轴以及顶部的彩色键所示。
虚线表示分配的对象数，如右侧的 y 轴所示。
用于表示每个垃圾回收 Event 的图标。
不过，如果您使用的是运行 Android 7.1 或更低版本的设备，则默认情况下，并不是所有分析数据均可见。 如果您看到一条消息，其显示“Advanced profiling is unavailable for the selected process”，则需要启用高级分析以查看下列内容：
- Event 时间线
- 分配的对象数
- 垃圾回收 Event
在 Android 8.0 及更高版本上，始终为可调试应用启用高级分析。
在您的堆转储中，请注意由下列任意情况引起的内存泄漏：
- 长时间引用 Activity、Context、View、Drawable 和其他对象，可能会保持对 Activity 或 Context 的引用。
- 可以保持 Activity 实例的非静态内部类，如 Runnable。
- 对象保持时间超出所需时间的缓存。
查看内存分配
要检查分配记录，请按以下步骤操作：
- 浏览列表以查找堆计数异常大且可能存在泄漏的对象。 为帮助查找已知类，点击 Class Name 列标题以按字母顺序排序。 然后点击一个类名称。 此时在右侧将出现 Instance View 窗格，显示该类的每个实例，如图 下中所示。
- 在 Instance View 窗格中，点击一个实例。 此时下方将出现 Call Stack 标签，显示该实例被分配到何处以及哪个线程中。
- 在 Call Stack 标签中，点击任意行以在编辑器中跳转到该代码。
image.png
捕获堆转储
堆转储显示在您捕获堆转储时您的应用中哪些对象正在使用内存。 特别是在长时间的用户会话后，堆转储会显示您认为不应再位于内存中却仍在内存中的对象，从而帮助识别内存泄漏。 在捕获堆转储后，您可以查看以下信息：
- 您的应用已分配哪些类型的对象，以及每个类型分配多少。
- 每个对象正在使用多少内存。
- 在代码中的何处仍在引用每个对象。
- 对象所分配到的调用堆栈。 （目前，如果您在记录分配时捕获堆转储，则只有在 Android 7.1 及更低版本中，堆转储才能使用调用堆栈。）
实测内存泄漏
1. 内部类
new Handler().postDelayed(new Runnable() {
@Override
public void run() {
}
}, 15000);
跳转到新的LeakActivity里执行这段代码，然后退出这个LeakActivity。执行gc。
下图4处的 gc 是系统执行的，此时 postDelayed 执行完毕。选取5和4中间的时间节点查看内存，在下图1处按照 Arrange by package 分类,直接查看当前包名下的实例。
- Arrange by class：基于类名称对所有分配进行分组。
- Arrange by package：基于软件包名称对所有分配进行分组。
- Arrange by callstack：将所有分配分组到其对应的调用堆栈。
5是在LeakActivity结束后gc，此时还有LeakActivity的实例，说明LeakActivity不能被回收，发生了内存泄漏。在3处可以看到，他dealloc time 没有时间，也说明内存并没有被重新分配，也就是没有被回收。
把时间节点选取到4后面，就没有LeakActivity的实例了。
可以看到，在5和4直接的时间，已经退出了LeakActivity，但是没有被 gc 回收，因为 handler 还在执行。他持有着 acitvity 的引用。
image.png
重新操作一遍上述流程，在退出LeakActivity后dump内存：
image.png
右边的3处Depth 是3，表示这个实例被引用的步进是3，当引用为0时才能被回收。
image.png
在上图右键，跳到代码里，定位的地方就是实例被引用的地方，正是这个方法。这个runnable被装进Messagerqueue里。等待执行。而handler 是匿名内部类 ，匿名内部类的构造方法不再是默认的无参的构造方法，而是有一个参数（外部类）的构造方法，runnable也是匿名内部类，又持有handle，所以Depth=3。静态内部类才不会持有外部类，所以我们把这两个类改为静态内部类：
private static final Runnable run = new Runnable() {
@Override
public void run() {
}
};
另外，handle一般需要context去执行操作，所以我们传递进去context：
static class MyHandle extends Handler {
WeakReference<Context> weakReference;
public MyHandle(Context context) {
weakReference = new WeakReference<>(context);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
if (weakReference.get() != null) {
// ((LeakActivity) weakReference.get()).showToast();
}
}
}
如果不想这么麻烦怎么办？我们知道哪些情况引起的内存泄漏，一般都是持有引用的实例比activity的生命周期长，所以我们可以在onDestroy里，执行 handle.removeCallbacksAndMessages(null)，这样也不会造成内存泄漏了。
2. 线程
class MyThread extends Thread {
@Override
public void run() {
super.run();
while (true) {
try {
sleep(2000);
System.out.println("ssssssss");
} catch (InterruptedException e) {
}
}
}
}
开启这个线程new MyThread().start();然后dump内存，也发生了内存泄漏，方法和上图一样，怎么避免呢？方法和上面一样有两种：
- 改为静态内部类
- onDestroy的时候停止这个线程
3. 监听
findViewById(R.id.btnDelay).getViewTreeObserver()
.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
//计算宽高等耗时操作
}
});
查看如下getViewTreeObserver源码发现，无论是否finish，ViewTreeObserver都不会为空，所以它的生命周期比activity长。但是如果没有耗时操作的话，getViewTreeObserver就不再被引用，也会被回收。如果有耗时操作，add后要remove. 一般有add 记得 让remove 成对出现。
public ViewTreeObserver getViewTreeObserver() {
if (mAttachInfo != null) {
return mAttachInfo.mTreeObserver;
}
if (mFloatingTreeObserver == null) {
mFloatingTreeObserver = new ViewTreeObserver(mContext);
}
return mFloatingTreeObserver;
}
4. 单例
如下我们常见的一个单例,单例和app的生命周期一样长，所以register的时候持有context，知道app运行结束，所以在activity销毁的时候，记得移除单例持有的context，下图的unRegister。
class MySingleton {
private static final MySingleton ourInstance = new MySingleton();
private Context context;
static MySingleton getInstance() {
return ourInstance;
}
private MySingleton() {
}
void register(Context context) {
this.context = context;
}
void unRegister() {
this.context = null;
}
}
4. 静态成员变量
静态成员变量 的生命周期也比activity长，所以如果静态成员变量持有context，activity也无法回收。
static NorClass sNorClass;
public class NorClass {
Context context;
public NorClass(Context context) {
this.context = context;
}
}
网友评论