使用ConnectivityManager的内存泄漏隐患

Android里面内存泄漏问题最突出的就是Activity的泄漏，而泄漏的根源大多在于单例的使用，也就是一个静态实例持有了Activity的引用。静态变量的生命周期与应用（Application）是相同的，而Activity生命周期通常比它短，也就会造成在Activity生命周期结束后，还被引用导致无法被系统回收释放。

生成静态引用内存泄漏可能有两种情况：

1. 应用级：应用程序代码实现的单例没有很好的管理其生命周期，导致Activity退出后仍然被引用。
2. 系统级：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);

文／kkmoving（简书作者）
原文链接：http://www.jianshu.com/p/7d4b55f7ed9f
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。