- GC的原理：
- GC（垃圾回收机制），我们知道Java是自带GC的语言，在Android中也同样是由VM帮助程序员管理内存；
- 常见的GC算法由引用计数法、根节点遍历可达性分析等方法，引用计数的方式容易出现循环引用的问题，如a引用b，b引用a，这个时候出现循环引用的情况，即使a、b已经成为垃圾对象，但是引用计数都不为0，JVM将无法回收；
在Java中主要使用的是GC Root遍历的方式来进行内存回收，从根节点出发，遍历引用的路径，将有用的对象标记为可达，有用的对象，实现内存回收的做法。
- Android常见内存泄漏情况分析：
- 内存泄漏，指的是一个对象或者内存块，对于程序员来说已经不需要，但是由于程序员的编码或者是代码逻辑，导致JVM无法回收指定的内存区域，而导致的内存leak问题。
2.1 内存泄漏常见情景：
2.1.1: 不合理的单例模式：
单例模式，通常用于全局唯一的，如统一的网络请求、Toast等情况中，单例模式有助于节省内存等开销；
public class ToastUtil {
private static Toast toast;
public static void showMessage(Context context, String text) {
showMessage(context, text, Toast.LENGTH_SHORT);
}
public static void showMessage(Context context, int resId, int durationFlag) {
showMessage(context, context.getResources().getString(resId), durationFlag);
}
public static void showMessage(Context context, String text, int durationFlag) {
View vToast = LayoutInflater.from(context).inflate(R.layout.toast, null);
TextView textView = vToast.findViewById(R.id.tv_toast);
if (toast != null) {
toast.cancel();
}
// Reference: Avoid Memory Leak Problem.
// https://github.com/EddieRingle/hubroid/blob/master/src/net/idlesoft/android/apps/github/utils/ToastUtil.java
toast = Toast.makeText(context.getApplicationContext(), text, durationFlag);
toast.setView(vToast);
textView.setText(text);
toast.show();
}
}
如上的ToastUtil的代码中，如果showMessage传入的是Activity/Fragment等的Context，因为在Android中，单例的生命周期和ApplicationContext的生命周期一样长，容易出现内存泄漏的问题，即是生命周期长的内存对象引用短的内存对象，导致在短生命的对象无法被GC。
2.1.2 Handler导致内存泄漏：
Handler机制作为Android中的消息机制，如果使用不当，如在https://www.androiddesignpatterns.com/2013/01/inner-class-handler-memory-leak.html
文中提到一个建议：
In Android, Handler classes should be static or leaks might occur.
首先是消息机制：
- 当Android中的App启动时候，Framework层会创建一个主线程的Looper，在消息循环中有一个简单的消息队列，Message Queue，消息队列中存储着很多的Message，Looper开启消息循环。主线程的Looper同整个App的生命周期一样。
- 当Handler在主线程中创建的时候，它会与Looper关联，被post到消息队列中的消息会持有Handler的引用，从而framework层可以在消息处理的时候去调用
Handler#handleMessage(Message)方法。 - 在Java中，非静态内部类或者匿名类会默认持有一个外部类的引用，而静态内部类不会。
为啥会有内存泄漏的问题呢？
考虑如下代码：
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mLeakyHandler.postDelayed(new Runnable() {
@Override
public void run() { /* ... */ }
}, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
在App跪了后，这个延迟的消息会一直在主线程的消息队列中存活10min才处理，而message持有了Handler的引用，Handler又持有SampleActivity的引用，这个引用得等到消息被处理后才消失。此时就出现了内存泄漏的问题。
如何修复？
一般而言，将Handler定义为static或者是去持有一个Activity的WeakReference，如
private static class MyHandler extends Handler {
private final WeakReference<SampleActivity> mActivity;
public MyHandler(SampleActivity activity) {
mActivity = new WeakReference<SampleActivity>(activity);
}
@Override
public void handleMessage(Message msg) {
SampleActivity activity = mActivity.get();
if (activity != null) {
// ...
}
}
}
-- 题外话
-
引用介绍：
在JDK 1.2以前的版本中，若一个对象不被任何变量引用，那么程序就无法再使用这个对象。也就是说，只有对象处于可触及（reachable）状态，程序才能使用它。从JDK 1.2版本开始，把对象的引用分为4种级别，从而使程序能更加灵活地控制对象的生命周期。这4种级别由高到低依次为：强引用、软引用、弱引用和虚引用。
1). 强引用（StrongReference）
强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。 ps：强引用其实也就是我们平时A a = new A()这个意思。
2). 软引用（SoftReference）
如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存（下文给出示例）。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
3). 弱引用（WeakReference）
弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
4). 虚引用（PhantomReference）
“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。
