一般内存泄漏(traditional memory leak)的原因是： 由忘记释放分配的内存导致的。（如Cursor忘记关闭等） 逻辑内存泄漏(logical memory leak)的原因是： 当应用不再需要这个对象，当仍未释放该对象的所有引用。 **如果持有对象的强引用，垃圾回收器是无法在内存中回收这个对象。** 在Android中，导致潜在内存泄漏的陷阱不外乎两种： > 1）全局进程(process-global)的static变量。这个无视应用的状态，持有Activity的强引用的怪物。 > 2）活在Activity生命周期之外的线程。没有清空对Activity的强引用。 具体有以下几种： #### 1.Static Activities **在类中定义了静态Activity变量，把当前运行的Activity实例赋值于这个静态变量。** 如果这个静态变量在Activity生命周期结束后没有清空，就导致内存泄漏。**因为static变量是贯穿这个应用的生命周期的，所以被泄漏的Activity就会一直存在于应用的进程中，不会被垃圾回收器回收**。 #### 2.Static Views View在内存中也是比较耗资源的，如果把View定义为static，加载到视图树上(View Hierachy)，也会造成内存泄漏。 #### 3.Inner Classes 内部类的优势之一就是可以访问外部类，不幸的是，导致内存泄漏的原因，就是内部类持有外部类实例的强引用。 #### 4.Anonymous Classes 相似地，匿名类也维护了外部类的引用。所以内存泄漏很容易发生，当你在Activity中定义了匿名的AsyncTsk。当异步任务在后台执行耗时任务期间，Activity不幸被销毁了（译者注：用户退出，系统回收），这个被AsyncTask持有的Activity实例就不会被垃圾回收器回收，直到异步任务结束。 #### 5.Handler 同样道理，定义匿名的Runnable，用匿名类Handler执行。Runnable内部类会持有外部类的隐式引用，被传递到Handler的消息队列MessageQueue中，在Message消息没有被处理之前，Activity实例不会被销毁了，于是导致内存泄漏。 #### 6.Threads #### 7.TimerTask 只要是匿名类的实例，不管是不是在工作线程，都会持有Activity的引用，导致内存泄漏。 #### 8.Sensor Manager 最后，通过Context.getSystemService(int name)可以获取系统服务。这些服务工作在各自的进程中，帮助应用处理后台任务，处理硬件交互。如果需要使用这些服务，可以注册监听器**，这会导致服务持有了Context的引用，如果在Activity销毁的时候没有注销这些监听器，会导致内存泄漏。**