- 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 mActivity;
public MyHandler(SampleActivity activity) {
mActivity = new WeakReference(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)联合使用。当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象的内存之前,把这个虚引用加入到与之 关联的引用队列中。