Android常见内存泄漏

1.什么是内存泄露

内存泄漏(Memory Leak)是指程序中已动态分配的堆内存由于某种原因未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃(内存溢出OOM)等严重后果。
内存泄露的危害:

用户对单次的内存泄漏并没有什么感知，但是当泄漏积累到内存都被消耗完，就会导致卡顿，甚至崩溃;
gc回收频繁造成应用卡顿ANR：
当内存不足的时候,gc会主动回收没用的内存.但是,内存回收也是需要时间的.
内存回收和gc回收垃圾资源之间高频率交替的执行.就会产生内存抖动.
很多数据就会污染内存堆，马上就会有许多GCs启动，由于这一额外的内存压力，也会产生突然增加的运算造成卡顿现象，
任何线程的任何操作都会需要暂停，等待GC操作完成之后，其他操作才能够继续运行,所以垃圾回收运行的次数越少，对性能的影响就越少;

2.内存泄漏的原因

Android虚拟机有垃圾回收机制，会回收掉大部分的内存空间，但是有一些逻辑上已经不再使用的对象，被GC Root直接或间接引用，导致垃圾回收器不能回收它们。

2.1.虚拟机内存模型

Jvm(Java虚拟机)主要管理两种类型内存：堆和非堆。堆是运行时数据区域，所有类实例和数组的内存均从此处分配。非堆是JVM留给自己用的，包含方法区、虚拟机栈、本地方法栈、程序计数器。

对于绝大多数应用来说，堆内存是 JVM 所管理的内存中最大的一块。线程共享，主要是存放对象实例和数组。内部会划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。堆内存由垃圾回收器的自动内存管理系统回收，出现内存泄漏也主要在这个区域

2.2.可回收对象的判定

可达性分析算法：从GC Roots（每种具体实现对GC Roots有不同的定义）作为起点，向下搜索它们引用的对象，可以生成一棵引用树，树的节点视为可达对象，反之视为不可达。即使循环引用了，只要没有被GC Roots引用了依然会被回收。但是，这个GC Roots的定义就要考究了，Java语言定义了如下GC Roots对象：

虚拟机栈（帧栈中的本地变量表）中引用的对象。方法区中静态属性引用的对象。方法区中常量引用的对象。本地方法栈中JNI引用的对象。

3.内存泄漏检测工具

3.1.LeakCanary

通过集成 LeakCanary ，一旦检测到内存泄漏，LeakCanary 就会 dump Memory 信息，并通过另一个进程分析内存泄漏的信息并展示出来，随时发现和定位内存泄漏问题，极大地方便了Android应用程序的开发。

3.1.1.原理

LeakCanary 是通过在 Application 的 registerActivityLifecycleCallbacks 方法实现对 Activity 销毁监听的，在 Activity 在销毁时，将 Activity 包装到 WeakReference 中，被 WeakReference 包装过的 Activity 对象如果能够被回收，则说明引用可达，垃圾回收器就会将该 WeakReference 引用存放到 ReferenceQueue 中。相反就可能发生了内存泄漏。

3.1.2.接入

dependencies {// debugImplementation because LeakCanary should only run in debug builds.debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.7'
}

通过过滤 Logcat 中的 LeakCanary 标签来确认 LeakCanary 在启动时正在运行：

D/LeakCanary: LeakCanary is running and ready to detect memory leaks.

在 LeakCanary2.0 之前我们接入的时候需要在 Application.onCreate 方法中显式调用 LeakCanary.install(this); 开启 LeakCanary 的内存监控。
从 LeakCanary2.0 开始通过库里注册的 ContentProvier 自己开启 LeakCanary 的内存监控，无需用户手动再添加初始化代码。

3.1.3使用

安装测试应用后，手机上会出现如下两个图标：左侧的是测试应用的图标，右侧是自动安装的 LeakCanary 的图标。
打开可能存在内存泄漏页面，返回退出页面。等待大概10秒，LeakCanary 就会检测到，并进行分析。在通知栏可以看到进度。

分析完成后，然后在通知栏会收到通知。

点开通知，会打开 LeakCanary 的界面

另外，在 Logcat 中也可以看到 LeakCanary 的相关信息。LeakCanary 将应用中发现的泄漏分为两类：应用程序泄漏和库泄漏。

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS
......
====================================
0 LIBRARY LEAK
————————————————

3.2.Profiler

android studio自带的Profiler MEMORY工具，通过Capture heap dump抓取堆内存快照分析内存泄漏。

如存在泄漏，会提示相应泄漏对象：

根据泄漏对象references查看对象在哪里被引用，一般看是否被长生命周期对象（单例、静态对象、handler等）引用导致无法回收

4.常见内存泄漏场景

4.1.单列、静态变量导致内存泄漏

单例模式在Android开发中会经常用到，但是如果使用不当就会导致内存泄露。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄露。
常见的有：

Context：单例持有Activity、Service的Context。正确的做法是在单列、静态变量中如果需要用到Context可以用Application的Context替换
反例：

public class UpdateManager {private static volatile UpdateManager mInstance;private Context mContext;private UpdateManager(Context context) {mContext = context;}public static UpdateManager getInstance(Context context) {if (mInstance == null) {synchronized (UpdateManager.class) {if (mInstance == null) {mInstance = new UpdateManager(context);}}}return mInstance;}
}public class StaticClass {// 定义1个静态变量private Static Context mContext;//...// 引用的是Activity或Service的contextmContext = context; // 当Activity或Service需销毁时，由于mContext = 静态 & 生命周期 = 应用程序的生命周期，故 Activity无法被回收，从而出现内存泄露
}

正例：

public class UpdateManager {//...省略代码private UpdateManager(Context context) {mContext = context.getApplicationContext();}//...省略代码
}

监听回调：单例中只提供了添加监听的方法，无法取消监听。正确的做法是添加监听后在适当的位置取消监听
反例：

public class UpdateManager {public void addUpdateListener(UpdateListener listener) {if (mUpdateListener.contains(listener)) {return;}mUpdateListener.add(listener);}
}

正例：

public class UpdateManager {public void addUpdateListener(UpdateListener listener) {if (mUpdateListener.contains(listener)) {return;}mUpdateListener.add(listener);}public void removeUpdateListener(UpdateListener listener) {mUpdateListener.remove(listener);}
}

4.2.非静态内部类、匿名类导致内存泄漏

非静态类和匿名类默认会持有外部类的引用，所以在长生命周期的类中引用了非静态内部类、匿名类就会导致内存泄漏。常见的解决方式是静态内部类+WeakReference

Handler：使用非静态内部类或匿名类定义Handler变量，由于使用的getMainLooper，那发送的Message回被添加在主线程的Looper中，其生命周期 = 应用的生命周期，Message又持有mHandler，mHandler是非静态内部类又持有外部类TestActivity，从而导致TestActivity无法回收
反例：

public class TestActivity extends Activity {private Handler mHandler = new Handler(Looper.getMainLooper()) {@Overridepublic void handleMessage(Message msg) {super.handleMessage(msg);if (msg.what == 1) {showContent();}}};//使用mHandler.sendEmptyMessageDelayed(5000,1)发送消息，并未清理
}

正例一：在适当的位置情况已发送的Message

@Override
protected void onDestroy() {super.onDestroy();mHandler.removeCallbacksAndMessages(null);
}

正例二：使用静态内部类+WeakReference

private MyHandler mHandler;@Override
protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);mHandler = new MyHandler(this);
}private static class MyHandler extends Handler {private final WeakReference<TestActivity> mWeakActivity;public MyHandler(TestActivity testActivity) {super();mWeakActivity = new WeakReference<>(testActivity);}@Overridepublic void handleMessage(Message msg) {super.handleMessage(msg);TestActivity testActivity = mWeakActivity.get();if (testActivity == null) {return;}if (msg.what == 1) {testActivity.showContent();}}
}

多线程：AsyncTask、实现 Runnable 接口、继承 Thread 类，当工作线程正在处理任务时，如果外部类销毁，由于工作线程实例持有外部类引用，将使得外部类无法被垃圾回收器（GC）回收，从而造成内存泄露。
反例：

public class TestActivity extends Activity {private void execute() {new Thread() {@Overridepublic void run() {doSomething();}}.start();}private void doSomething(){//Do time-consuming operations}
}

正例：同样可以使用静态内部类+WeakReference处理，但一般不直接new Thread进行异步操作，而是使用线程池，最好是用RxJava、kotlin协程，这样可以更好管理线程，并且可以在组件销毁时停止异步操作

public class TestActivity extends Activity {private static class MyThread extends Thread {private final WeakReference<TestActivity> mWeakActivity;public MyThread(TestActivity activity) {mWeakActivity = new WeakReference<>(activity);}@Overridepublic void run() {super.run();if (mWeakActivity.get() == null) {return;}doSomething();}private void execute() {new MyThread(this).start();}
}

4.3.资源对象使用后未关闭

反例：未释放资源

public static void writeFile(File file, String content) {try {BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(file), StandardCharsets.UTF_8));bw.write(content);bw.flush();} catch (IOException e) {e.printStackTrace();}
}

正例：在finally中close

public static void writeFile(File file, String content) {BufferedWriter bw = null;try {bw = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(file), StandardCharsets.UTF_8));bw.write(content);bw.flush();} catch (IOException e) {e.printStackTrace();} finally {if (bw != null) {try {bw.close();} catch (IOException e) {e.printStackTrace();}}}
}

4.4.系统服务

Android中有很多服务，比如PowerManager,AlarmManager，NotificationManager等，通常使用起来也很方便，就是使用Context.getSystemService方法来获得。但部分Manager会持有调用的Context，例如：PowerManager

public PowerManager(Context context, IPowerManager service, IThermalService thermalService,Handler handler) {mContext = context;mService = service;mThermalService = thermalService;mHandler = handler;
}

所以如果获取PowerManager的时候使用的是Activity或Service的Context，并且在单例或static类中保存了PowerManager，就会导致内存泄漏。泄漏分析过程可参考：https://cloud.tencent.com/developer/article/1328418
解决方案：

不使用静态持有Manager，就算Manager中持有Activity或Service的Context，只要生命周期与Activity或Service保存一致，也不会出现内存泄漏
使用Application Context获取系统服务。但注意和UI相关的服务在Activity或ContextThemeWrapper中会做了优化，如果全部都使用Application Context将会得不偿失，所有需要试情况而定

//ContextThemeWrapper也优先处理了LayoutManager服务
@Override
public Object getSystemService(String name) {if (LAYOUT_INFLATER_SERVICE.equals(name)) {if (mInflater == null) {mInflater = LayoutInflater.from(getBaseContext()).cloneInContext(this);}return mInflater;}return getBaseContext().getSystemService(name);
}

a. 如果服务和UI相关，则用Activity
b. 如果是类似ALARM_SERVICE,CONNECTIVITY_SERVICE建议有限选用Application Context
c. 如果出现出现了内存泄漏，排除问题，可以考虑使用Application Context

4.5.广播未注销

无论是系统广播还是本地广播，注册与反注册需成对出现