Android内存泄漏——常见的内存泄露
JAVA是垃圾回收语言的一种，开发者无需特意管理内存分配。但是JAVA中还是存在着许多内存泄露的可能性，如果不好好处理内存泄露，会导致APP内存单元无法释放被浪费掉，最终导致内存全部占据堆栈(heap)挤爆进而程序崩溃。
Java的内存
JAVA是在JVM所虚拟出的内存环境中运行的，JVM的内存可分为三个区：堆(heap)、栈(stack)和方法区(method)。
- 栈(stack)：是简单的数据结构，但在计算机中使用广泛。栈最显著的特征是：LIFO(Last In, First Out, 后进先出)。比如我们往箱子里面放衣服，先放入的在最下方，只有拿出后来放入的才能拿到下方的衣服。栈中只存放基本类型和对象的引用(不是对象)。
- 堆(heap)：堆内存用于存放由new创建的对象和数组。在堆中分配的内存，由java虚拟机自动垃圾回收器来管理。JVM只有一个堆区(heap)被所有线程共享，堆中不存放基本类型和对象引用，只存放对象本身。
- 方法区(method)：又叫静态区，跟堆一样，被所有的线程共享。方法区包含所有的class和static变量。
内存泄露
说到内存泄露，就不得不提到内存溢出，这两个比较容易混淆的概念，我们来分析一下
- 内存泄露：程序在向系统申请分配内存空间后(new)，在使用完毕后未释放。结果导致一直占据该内存单元，我们和程序都无法再使用该内存单元，直到程序结束，这是内存泄露。
- 内存溢出：程序向系统申请的内存空间超出了系统能给的。比如内存只能分配一个int类型，我却要塞给他一个long类型，系统就出现oom。又比如一车最多能坐5个人，你却非要塞下10个，车就挤爆了
大量的内存泄露会导致内存溢出(OOM)。
内存泄露原因分析
栈(stack)可以自行清除不用的内存空间。但是如果我们不停的创建新对象，堆(heap)的内存空间就会被消耗尽。所以JAVA引入了垃圾回收(garbage collection，简称GC)去处理堆内存的回收，但如果对象一直被引用无法被回收，造成内存的浪费，无法再被使用。所以对象无法被GC回收就是造成内存泄露的原因。
垃圾回收(garbage collection，简称GC)可以自动清空堆中不再使用的对象。在JAVA中对象是通过引用使用的。如果再没有引用指向该对象，那么该对象就无从处理或调用该对象，这样的对象称为不可到达（unreachable）。垃圾回收用于释放不可到达的对象所占据的内存。
常见的内存泄漏
1、非静态内部类的静态实例容易造成内存泄漏
public class MainActivity extends AppCompatActivity {
static Demo sInstance = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if (sInstance == null) {
sInstance = new Demo();
}
sInstance.doSomething();
}
class Demo {
void doSomething() {
System.out.print("doSomething...");
}
}
}上面的代码中的sInstance实例类型为静态实例，在第一个MainActivity act1实例创建时，sInstance会获得并一直持有act1的引用。当MainAcitivity销毁后重建，因为sInstance持有act1的引用，所以act1是无法被GC回收的，进程中会存在2个MainActivity实例（act1和重建后的MainActivity实例），这个act1对象就是一个无用的但一直占用内存的对象，即无法回收的垃圾对象。所以，对于lauchMode不是singleInstance的Activity， 应该避免在activity里面实例化其非静态内部类的静态实例。
2、activity使用静态成员
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}由于用静态成员sBackground 缓存了drawable对象，所以activity加载速度会加快，但是这样做是错误的。因为在Android 2.3系统上，它会导致activity销毁后无法被系统回收。
label .setBackgroundDrawable函数调用会将label赋值给sBackground的成员变量mCallback。
上面代码意味着：sBackground（GC Root）会持有TextView对象，而TextView持有Activity对象。所以导致Activity对象无法被系统回收。
下面看看android4.0为了避免上述问题所做的改进。
先看看android 2.3的Drawable.Java对setCallback的实现：
public final void setCallback(Callback cb){
mCallback = cb;
}再看看android 4.0的Drawable.Java对setCallback的实现：
public final void setCallback(Callback cb){
mCallback = newWeakReference (cb);
} 在android 2.3中要避免内存泄漏也是可以做到的, 在activity的onDestroy时调用sBackgroundDrawable.setCallback(null)。
以上2个例子的内存泄漏都是因为Activity的引用的生命周期超越了activity对象的生命周期。也就是常说的Context泄漏，因为activity就是context。
想要避免context相关的内存泄漏，需要注意以下几点：
- 不要对activity的context长期引用(一个activity的引用的生存周期应该和activity的生命周期相同)
- 如果可以的话，尽量使用关于application的context来替代和activity相关的context
- 如果一个activity的非静态内部类的生命周期不受控制，那么避免使用它；正确的方法是使用一个静态的内部类，并且对它的外部类有一WeakReference，就像在ViewRootImpl中内部类W所做的那样。
3、使用handler时的内存问题
public class HandlerActivity extends Activity {
private final Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
};
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler.sendMessageDelayed(Message.obtain(), 60000);
finish();
}
}这样写没有问题？
AndroidStudio给我们有这样的提示
Handler 的生命周期与Activity 不一致
- 当Android应用启动的时候，会先创建一个UI主线程的Looper对象，Looper实现了一个简单的消息队列，一个一个的处理里面的Message对象。主线程Looper对象在整个应用生命周期中存在。
- 当在主线程中初始化Handler时，该Handler和Looper的消息队列关联（没有关联会报错的）。发送到消息队列的Message会引用发送该消息的Handler对象，这样系统可以调用 Handler#handleMessage(Message) 来分发处理该消息。
handler 引用 Activity 阻止了GC对Acivity的回收
- 在Java中，非静态(匿名)内部类会默认隐性引用外部类对象。而静态内部类不会引用外部类对象。
如果外部类是Activity，则会引起Activity泄露 。 - 当Activity finish后，延时消息会继续存在主线程消息队列中1分钟，然后处理消息。而该消息引用了Activity的Handler对象，然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完，这样就导致该Activity对象无法被回收，从而导致了上面说的 Activity泄露。
修改代码如下：
public class HandlerActivity2 extends Activity {
private static final int MESSAGE_1 = 1;
private static final int MESSAGE_2 = 2;
private static final int MESSAGE_3 = 3;
private final Handler mHandler = new MyHandler(this);
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler.sendMessageDelayed(Message.obtain(), 60000);
// just finish this activity
finish();
}
public void todo() {
};
private static class MyHandler extends Handler {
private final WeakReference mActivity;
public MyHandler(HandlerActivity2 activity) {
mActivity = new WeakReference(activity);
}
@Override
public void handleMessage(Message msg) {
System.out.println(msg);
if (mActivity.get() == null) {
return;
}
mActivity.get().todo();
}
}
} 4、注册某个对象后未反注册
注册广播接收器、注册观察者等等
5、构造Adapter时，没有使用缓存的convertView
以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法public View getView(int position,View convertView,ViewGroup parent)
来向ListView提供每一个item所需要的View对象。初始化时ListView会从BaseAdapter中根据当前屏幕布局实例
化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的
list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()
方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的View对象
由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪
费时间，也造成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给应用进程分配更
多的内存，造成内存泄露。
6、Bitmap使用不当
6.1、及时的销毁
虽然，系统能够确认Bitmap分配的内存最终会被销毁，但是由于它占用的内存过多，所以很可能会超过Java堆的限制。因此，在用完Bitmap时，要及时的recycle掉。recycle并不能确定立即就会将Bitmap释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。
6.2、设置一定的采样率
有时候，我们要显示的区域很小，没有必要将整个图片都加载出来，而只需要记载一个缩小过的图片，这时候可以设置一定的采样率，那么就可以大大减小占用的内存。如下面的代码：
ImageView preview;
BitmapFactory.Options options = newBitmapFactory.Options();
//图片宽高都为原来的二分之一，即图片为原来的四分之一
options.inSampleSize = 2;
Bitmap bitmap =BitmapFactory.decodeStream(cr.openInputStream(uri), null, options);
preview.setImageBitmap(bitmap);6.3、巧妙的运用软引用（SoftReference）
有些时候，我们使用Bitmap后没有保留对它的引用，因此就无法调用Recycle函数。这时候巧妙的运用软引用，可以使Bitmap在内存快不足时得到有效的释放。如下：
SoftReference bitmap_ref = new SoftReference(BitmapFactory.decodeStream(inputstream));
……
……
if (bitmap_ref .get() != null){
bitmap_ref.get().recycle();
}