android内存泄露

android避免内存泄露的一些注意点：
1，Bitmap对象不使用时候注意采用recycle()来释放内存
2，我们知道java语言中内存泄露的原因是这样的，java中对内存对象的访问使用的是引用的方式，当对象没有任何的引用后
会被垃圾回收器所回收，但是如果这个对象还存在引用，那么它将不会被垃圾回收器所回收，哪怕是虚拟机抛了异常。所以当
我们的内存中有的对象在不需要的时候，可是依然保留着这块内存和它的引用。鉴于以上我们说的原因，我们在使用Activity中
对象的时候，注意不要让它的生命周期大于此Activity
3,数据库的Cursor没有关闭造成资源的浪费
4，充分使用contentview,减少创建view的对象，可以使用静态类来处理优化getview的过程

调试方法：ddms->heapsize->adtaobject->total size

在Android上，Context常用于许多操作，更多的时候是加载和访问资源。这就是为什么所有的Widget在它们的构造函数里接受一个Context的参数。在一个正常的Android应用程序里，你会看到两种Context类型，Activity和Application。而一般在需要一个Context的类和方法里，往往传入的是第一种，这意味着，View拥有对整个Activity的引用以及Activity自身拥有的所有内容；一般是整个的View层次和它的所有资源。因此，如果你“泄露”了Context（“泄露”指你保留了一个引用，阻止了GC的垃圾回收），你将泄露很多的内存。如果你不够仔细的话，很容易就能泄露一个Activity。
当屏幕的方向发生改变时，一般系统会销毁当前的Activity并创建一个新的，并保存它的状态。当系统这样做时，Android会从资源中重新加载应用程序的UI。假设你写的应用程序拥有大的位图，而你又不想在每次旋转时重新加载它。这里有最简单的方式，那就是在一个静态的字段里进行保存。


当一个Drawable附加到一个View上时，View会将其作为一个callback设定到Drawable上。上述的代码片段，意味着Drawable拥有一个TextView的引用，而TextView又拥有Activity（Context类型）的引用，换句话说，Drawable拥有了更多的对象引用（依赖于你的代码）。
这是最容易泄露Context的例子之一，你可以看看Home Screen源代码里是如何处理的（搜索unbindDrawables()方法）：当Activity销毁时，设定存储的Drawable的callback为null。有趣的是，还有很多一连串的Context泄露情况，并且是非常糟糕的。这些情况会使得应用程序很快耗尽内存。
这里，有两种简单的方式可以避免与Context相关的内存泄露。最显而易见的一种方式是避免将Context超出它自己的范围。上面的例子代码给出的静态引用，还有内部类和它们对外部类的隐式引用也是很危险的。第二种解决方案是使用Applicatio

n这种Context类型。这种Context拥有和应用程序一样长的生命周期，并且不依赖Activity的生命周期。如果你打算保存一个长时间的对象，并且其需要一个Context，记得使用Application对象。你可以通过调用Context.getApplicationContext()或Activity.getApplication()轻松得到Application对象。
概括一下，避免Context相关的内存泄露，记住以下事情：
不要保留对Context-Activity长时间的引用（对Activity的引用的时候，必须确保拥有和Activity一样的生命周期）
尝试使用Context-Application来替代Context-Activity
如果你不想控制内部类的生命周期，应避免在Activity中使用非静态的内部类，而应该使用静态的内部类，并在其中创建一个对Activity的弱引用。这种情况的解决办法是使用一个静态的内部类，其中拥有对外部类的WeakReference，如同ViewRoot和它的Winner类那样
GC（垃圾回收）不能解决内存泄露问题