内存泄露分析

1.1 Java对象导致的泄漏

当一个对象的被引用数为0时，就会被JVM的GC回收。对象有不同的引用级别，从最强到最弱，不同的引用（可到达性）级别反映了对象的生命周期。

1. Strong Ref(强引用)：通常我们编写的代码都是Strong Ref，于此对应的是强可达性，只有去掉强可达，对象才被回收。
2. Soft Ref(软引用)：对应软可达性，只要有足够的内存，就一直保持对象，直到发现内存吃紧且没有Strong Ref时才回收对象。一般可用来实现缓存，通过java.lang.ref.SoftReference类实现。
3. Weak Ref(弱引用)：比Soft Ref更弱，当发现不存在Strong Ref时，立刻回收对象而不必等到内存吃紧的时候。通过java.lang.ref.WeakReference和java.util.WeakHashMap类实现。
4. Phantom Ref(虚引用)：根本不会在内存中保持任何对象，你只能使用Phantom Ref本身。一般用于在进入finalize()方法后进行特殊的清理过程，通过 java.lang.ref.PhantomReference实现。

Java对象的泄漏，可分为暂时不释放，长期不释放，无法释放几种。

1.1 底层导致的泄露

上层Java很多功能需要依赖于系统底层的c库来提供，设计不够好的jni接口在正常使用时可能没有什么问题，但是很多时候，在稍微不注意的情况下，就算上层的java对象释放了，如果没有显式的调用jni的释放接口，也会导致底层c库中的泄漏问题。

1.1 注册没取消造成的内存泄漏

一些Android程序可能引用我们的Android程序的对象（比如注册机制）。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。常见的有：

BraodcastReceiver，ContentObserver，FileObserver。　　

对于上述两种常见的内存泄漏，我们在开发中需要记住以下2点： 

1. 对activity的持久引用，对activity的引用应该和activity本身有相同的生命周期，尽量使用application代替activity作为Context来获取资源，或者构造Dialog或Toast。 

2. 如果不能控制非静态的内部类的生命周期，尽量在activity中避免有非静态的内部类。同时在activity中使用静态的类时如果需要引用activity,应该采用WeakReference弱引用来引用Activity。

1.1 底层系统资源的泄漏

比如PowerManager.WakeLock，MemoryFile等很多os对象。