Android里面内存泄漏问题最突出的就是Activity的泄漏，而泄漏的根源大多在于单例的使用，也就是一个静态实例持有了Activity的引用。静态变量的生命周期与应用（Application）是相同的，而Activity生命周期通常比它短，也就会造成在Activity生命周期结束后，还被引用导致无法被系统回收释放。
生成静态引用内存泄漏可能有两种情况：
- 应用级：应用程序代码实现的单例没有很好的管理其生命周期，导致Activity退出后仍然被引用。
- 系统级：Android系统级的实现的单例，被应用不小心错误调用（当然你也可以认为是系统层实现地不太友好）。
这个主要讲下系统级的情况，这样的情况可能也有很多，举个最近发现的问题ConnectivityManager。
通常我们获取系统服务时采用如下方式：
context.getSystemService()
在Android6.0系统上，如果这里的Context如果是Activity的实例，那么即使你什么也不干也会造成内存泄漏。
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
}
}
用LeakCanary可以直接看到内存泄漏：
D/LeakCanary: In com.kkmoving.main:1.0:1.
D/LeakCanary: * com.kkmoving.main.MainActivity has leaked:
D/LeakCanary: * GC ROOT static android.net.ConnectivityManager.sInstance
D/LeakCanary: * references android.net.ConnectivityManager.mContext
D/LeakCanary: * leaks com.kkmoving.main.MainActivity instance
D/LeakCanary: * Retaining: 3.5 KB.
D/LeakCanary: * Reference Key: 4a1b4c92-78f8-4233-b16f-8924e11cae9d
D/LeakCanary: * Device: LGE google Nexus 5 hammerhead
D/LeakCanary: * Android Version: 6.0 API: 23 LeakCanary: 1.4-beta1 02804f3
一步一步来分析下。
先从Context的getSystemService方法开始，我们知道Activity是从ContextWrapper继承而来的，ContextWrapper中持有一个mBase实例，这个实例指向一个ContextImpl对象，同时ContextImpl对象持有一个OuterContext对象，对于Activity来说，这个OuterContext就是Activity对象。所以调用getSystemService最终会调用到ContextImpl的getSystemService方法。
在6.0上ContextImpl的getSystemService方法调用SystemServiceRegistry来完成。
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
SystemServiceRegistry提供ConnectivityManager的实例。
public static Object getSystemService(ContextImpl ctx, String name) {
ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
return fetcher != null ? fetcher.getService(ctx) : null;
}
registerService(Context.CONNECTIVITY_SERVICE, ConnectivityManager.class,
new StaticOuterContextServiceFetcher<ConnectivityManager>() {
@Override
public ConnectivityManager createService(Context context) {
IBinder b = ServiceManager.getService(Context.CONNECTIVITY_SERVICE);
IConnectivityManager service = IConnectivityManager.Stub.asInterface(b);
return new ConnectivityManager(context, service);
}});
static abstract class StaticOuterContextServiceFetcher<T> implements ServiceFetcher<T> {
private T mCachedInstance;
@Override
public final T getService(ContextImpl ctx) {
synchronized (StaticOuterContextServiceFetcher.this) {
if (mCachedInstance == null) {
mCachedInstance = createService(ctx.getOuterContext());
}
return mCachedInstance;
}
}
public abstract T createService(Context applicationContext);
}
在6.0上，ConnectivityManager实现为单例：
private static ConnectivityManager sInstance;
精彩的部分来了，ConnectivityManager 持有了一个Context的引用：
private final Context mContext;
public ConnectivityManager(Context context, IConnectivityManager service) {
mContext = checkNotNull(context, "missing context");
mService = checkNotNull(service, "missing IConnectivityManager");
sInstance = this;
}
这个Context在ConnectivityManager 创建时传入，这个Context在StaticOuterContextServiceFetcher中由ContextImpl对象转换为OuterContext，与就是Activity对象，所以最终ConnectivityManager的单实例持有了Activity的实例引用。这样即使Activity退出后仍然无法释放，导致内存泄漏。
这个问题仅在6.0上出现，在5.1上ConnectivityManager实现为单例但不持有Context的引用，在5.0有以下版本ConnectivityManager既不为单例，也不持有Context的引用。
其他服务没认真研究，不确定有没有这个问题。不过为了避免类似的情况发生，最好的解决办法就是：
获取系统服务getSystemService时使用ApplicationContext
context.getApplicationContext().getSystemService(Context.CONNECTIVITY_SERVICE);