什么是内存泄露
Java使用有向图机制，通过GC自动检查内存中的对象，如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收。
内存泄露的原因
1.资源对象没关闭造成的内存泄漏
资源性对象比如 （Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏。因为有些资源性对象，比如 SQLiteCursor（在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时 也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序
退出时一定要确保我们的资源性对象已经关闭。
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
示例代码：
Cursor cursor = getContentResolver().query(uri...);
if (cursor.moveToNext()) {
... ...
}
修正示例代码：
Cursor cursor = null;
try {
cursor = getContentResolver().query(uri...);
if (cursor != null &&cursor.moveToNext()) {
... ...
}
} finally {
if (cursor != null) {
try {
cursor.close();
} catch (Exception e) {
//ignore this
}
}
}
2.构造Adapter时，没有使用缓存的convertView
以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法：
public View getView(int position, ViewconvertView, ViewGroup parent)
来 向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。由此可以看出，如果我们不去使用
convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。 ListView回收list item的view对象的过程可以查看:
Android.widget.AbsListView.java --> voidaddScrapView(View scrap) 方法。
示例代码：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代码：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
3.Bitmap对象不在使用时调用recycle()释放内存
有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：
/**
* Free up the memory associated with thisbitmap‘s pixels, and mark the
* bitmap as "dead", meaning itwill throw an exception if getPixels() or
* setPixels() is called, and will drawnothing. This operation cannot be
* reversed, so it should only be called ifyou are sure there are no
* further uses for the bitmap. This is anadvanced call, and normally need
* not be called, since the normal GCprocess will free up this memory when
* there are no more references to thisbitmap.
*/
4.试着使用关于application的context来替代和activity相关的context
这是一个很隐晦的内 存泄漏的情况。有一种简单的方法来避免context相关的内存泄漏。最显著地一个是避免context逃出他自己的范围之外。使用 Application context。这个context的生存周期和 的应用的生存周期一样长，而不是取决于activity的生存周期。如果 想保持一个长期生存的对象， 并且这个对象需要一个context,记得使用application对象。 可以通过调用 Context.getApplicationContext() or Activity.getApplication()来获得。更多的请看这篇文章如何避免Android内存泄漏
（见 http://www.linuxidc.com/Linux/2012-02/52951.htm ）。
5.注册没取消造成的内存泄漏
一些Android 程序可能引用我们的Anroid程序的对象（比如注册机制）。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android 程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。调用registerReceiver后未调用unregisterReceiver。
比如:假设我们希望 在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界 面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不 断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。
虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。
6.集合中对象没清理造成的内存泄漏
我们通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
7.Android中使用Handler造成内存泄露
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity的引用）。而Handler通常会伴随着一个耗 时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后 Handler把图片更新到界面。然而，如果用户在网络请求过程中关闭了Activity，正常情况下，Activity不再被使用，它就有可能在GC检 查时被回收掉，但由于这时线程尚未执行完，而该线程持有Handler的引用，这个Handler又持有
Activity的引用，就导致该Activity无法被回收（即内存泄露），直到网络请求结束（例如图片下载完毕）。另外，如果 执行了Handler 的postDelayed（）方法，该方法会将Handler装入一个Message，并把这条Message推到MessageQueue中，那么 在设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致Activity被持有引用而无法被回收。
内存泄露的危害
虚拟机占用内存过高，导致OOM（内存溢出），程序出错。对于Android应用来说，就是用户打开一个Activity，使用完之后关闭它，内存泄露；又打开，又关闭，又泄露；几次之后，程序占用内存超过系统限制，FC。
使用Handler导致内存泄露的解决方法
1.通过程序逻辑来进行保护。
（1）在关闭Activity的时候停掉 的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。
（2）如果 的Handler是被delay的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行了。
2.将Handler声明为静态类。
静态类不持有外部类的对象，所以 的Activity可以随意被回收。代码如下：
static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
但是这样还是有问题由于Handler不再持有外部类对象的引用，导致程序不允许 在Handler中操作Activity中的对象了。所以 需要在Handler中增加一个对Activity的弱引用（WeakReference）：
static class MyHandler extends Handler {
WeakReference<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}
延伸：什么是WeakReference？
WeakReference弱引用，与强引用（即我们常说的引用）相对，它的特点是，GC在回收时会忽略掉弱引用，即就算有弱引用指向某对象，但只 要该对象没有被强引用指向（实际上多数时候还要求没有软引用，但此处软引用的概念可以忽略），该对象就会在被GC检查到时回收掉。对于上面的代码，用户在 关闭Activity之后，就算后台线程还没结束，但由于仅有一条来自Handler的弱引用指向Activity，所以GC仍然会在检查的时候把 Activity回收掉。这样，内存泄露的问题就不会出现了。
那么，Android开发中，有什么有效的方法可以检测内存使用情况以及内存泄漏呢？
这里主要介绍三种方法：
1. 程序的Log信息
程序在进行垃圾回收的时候，会打印一条Log信息（logcat窗口），例如：
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
注意这条信息中的 “ 3571K/9991K” 值，这代表着程序使用的heap大小，如果这个值一直在增加，而从来不减小，那么就代表着 的程序存在着内存泄漏。
2. DDMS的Heap信息
Eclipse开发环境还提供了一种更加直观的方法来查看App的Heap信息，操作方式如下：
Android开发实践：检测App的内存占用和泄漏
（1） 连接手机，运行程序，假设是 com.ticktick.test 程序
（2） 点击DDMS按钮，在左侧的Device窗口选中 要检测的程序（com.ticktick.test ）
（3） 点击Device窗口工具栏的第二个图标（Update Heap），
（4） 点击右边的窗口的Cause GC按钮，即可得到当前程序的Heap信息
同样，随着程序的运行，多次点击得到的Heap大小，如果只增不减的话，也昭示着 的程序有内存泄漏。
3. adb命令查看内存信息
其实，最全面最简单的方式还是用adb命令来查看程序的内存占用和内存泄漏情况，打开命令行窗口，adb命令的格式如下：
adb shell dumpsys meminfo <package_name>
其中，package_name 也可以换成程序的pid，pid可以通过 adb shell top | grep app_name 来查找。
（1） Native/Dalvik 的 Heap 信息
具体在上面的第一行和第二行，它分别给出的是JNI层和Java层的内存分配情况，如果发现这个值一直增长，则代表程序可能出现了内存泄漏。
（2） Total 的 PSS 信息
这个值就是 的应用真正占据的内存大小，通过这个信息， 可以轻松判别手机中哪些程序占内存比较大了。
欢迎关注公众账号
