内存泄露方式有哪些和如何查询内存泄露？

内存泄露的方式

1、查询数据库而没有关闭Cursor

在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。通常，在Activity中，我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。但需要注意的是，当Activity介绍后，Cursor将不再可用！若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。除此之外，以下也是比较常见的Cursor不会被关闭的情况：虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。

导致内存泄露的地方：

try { 

Cursor c = queryCursor(); 
int a = c.getInt(2); 
...... 
} catch (Exception e) { 
} 

所以，我们的代码应该以如下的方式编写：

Cursor c = queryCursor(); 
try { 
int a = c.getInt(2); 
...... 
} catch (Exception e) { 
} finally { 
c.close(); //在finally中调用close(), 保证其一定会被调用 

}

2. 调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后，若未调用unregisterReceiver，其所占的内存是相当大的。
而我们经常可以看到类似于如下的代码：
这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
registerReceiver(new BroadcastReceiver() { 
... 
}, filter); ... 

3. 未关闭InputStream/OutputStream

在使用文件或者访问网络资源时，使用了InputStream/OutputStream也会导致内存泄露。

4. Bitmap使用后未调用recycle()

根据SDK的描述，调用recycle并不是必须的。但在实际使用时，Bitmap占用的内存是很大的，所以当我们不再使用时，尽量调用recycle()以释放资源。

5. Context泄露

这是一个很容易的内存泄露的情况。

看一下以下代码：

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); 
}

在这段代码中，我们使用了一个static的Drawable对象。这通常发生在我们需要经常调用一个Drawable，而其加载又比较耗时，不希望每次加载Activity都去创建这个Drawable的情况。此时，使用static无疑是最快的代码编写方式，但是其也非常的糟糕。当一个Drawable被附加到View时，这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。这就意味着，这个Drawable拥有一个TextView的引用，而TextView又拥有一个Activity的引用。这就会导致Activity在销毁后，内存不会被释放。

如何查询内存泄露

1、首先确定是否有内存泄露及哪个程序造成。

a、内存泄露已弹出out of memory对话框的情况。

这种情况很简单，直接看对话框就知道是哪个应用的问题了。然后再分析该应用是否是因为内存泄露造成的out of memory对话框。

b、对于有内存泄露，但没造成弹出out of memory对话框的情况

使用《Android中如何查看内存》中介绍的各种方法进行分析，确定是否有内存泄露以及是哪个进程造成的内存泄露。

2、生成hprof文件，用MAT进行分析。

生成hprof文件可以在DDMS选中进程点击窗口左上角的"dump hprof file"按钮来直接生成，也可以通过在程序加代码中来生成

代码2：

    void generateHprof()

    {

            String packageName=getApplicationInfo().packageName;

            String hpFilePath="/data/data/"+packageName+"/input.hprof";

            try {

                  //Debug.dumpHprofData("/sdcard/input.hprof");

                  Debug.dumpHprofData(hpFilePath);

            } catch (IOException e) {

                  // TODO Auto-generated catch block

                  e.printStackTrace();

            }

    }

建议使用代码生成hprof，然后使用《Android内存泄露利器（hprof篇）》中的工具自动提取多个hprof文件，然后用MAT进行比较分析。在MAT导入.hprof文件以后，MAT会自动解析并生成报告，点击Dominator Tree，并按Package分组，选择自己所定义的Package类,比较各个类在不同时期的Retained Heap,找出可疑类，然后选择该类，点右键，选中show retained Set 项,参看Retained Heap的详细信息，进一步找出嫌疑项。

3、在代码中查找内存泄露。

 根据在MAT找到的内存泄露信息，参照《Android内存泄漏简介》进一步在内存中查找内存泄露的原因并解决。另外如果代码很简单，可以直接参照《Android内存泄漏简介》在内存中查找内存泄露的原因并解决。

如果您有更好的方式我们一起完善。。。。3q