android内存泄露学习与总结

最近事情不多，一直在看java的数据结构，感觉学到了很多的东西，之前一直认为数据结构没有什么用，看了书才发现，不是数据结构没有用，而是它已经非常深入的融入到了所有的代码中，以至于变得自然而然，变得不需要提这是数据结构告诉我们应该是这样的，等看完后再写一个关于数据结构的系列文章。

 

中间也看了一些别的文章，内存泄露的文章比较多，先来总结一下吧。

 

Android的内存泄露情况并不多见，主要有以下几种：

1. 使用cursor结束后，没有将cursor关闭，这个cursor越大，占用内存越多，小型的数据库还看不出什么，如果数据库比较大，如果不关就会变得非常的卡，所有注意在finally里边调用cursor.close();
2. 在使用adapter时，使用缓存convertView。大部分使用Adapter的是已经封装好的，比如SimpleAdapter之类的，这些都已经在getView的时候已经使用convertView，但是如果是自己重写BaseAdapter的话，就需要在getView里加入convertView缓存了，不然每次都会去实例化一个View对象，浪费资源也浪费时间
3. 使用Bitmap对象后没有调用recycle()方法来释放内存。bitmap对象时非常占用内存的，所以当不再需要的时候调用Bitmap.recycle()方法来释放掉该内存。
4. 释放掉不再使用的对象的引用。这种情况比较复杂，总的来说就是，如果一个生命周期比较短的对象A被另外一个生命周期比较长的对象B引用的时候，在A生命周期结束时，需要在B中清除掉对A的引用，简单来说就是，一个东西不用了就把引用它的变量置空。
5. Android的activity使用非常的频繁，他有onPause()、onStop()、onDestroy()三个方法来控制资源的释放，可以用来释放相应的内存。

 

以上是在写代码中需要注意的事项，可以基本达到不存在内存泄露的情况，不过总会有没有注意到而导致内存泄漏的情况，这时我们就需要用到工具了，ADT中的DDMS就可以检测到。

在Devices中选中机器，并且选中程序，点击上边的 Update Heap按钮，在Heap窗口点击 Cause GC按钮，就相当于调用了一次System.gc().产看其中的data object的Total Size那一项，在不断操作的时候看看这个值是不是相对稳定的，如果不断变大而不会减小，那就说明存在了内存泄漏的情况。

 

其他工具以后再填坑