内存泄露的检测和修复一直是每个APP的重点和难点，也有很多文章讲述了如何检测和修复。本篇文章

结合最近开发的项目遇到的实例，讲述下Android Binder导致的内存泄露的一个案例。

发现问题

参与的项目在最近的版本接入了一个开源的内存检测工具LeakCanary，在提交给QA测试验证后。

瞬间检测出来N多的内存泄露，XXXActivity泄露，XXXActivity泄露…坑爹的是，这种泄露还不是必现的。好在堆栈都基本一样，随便拉一个出来分享吧

* com.ui.theme.ThemeListActivity has leaked:

* GC ROOT com.business.netscene.NetSceneBase1.this0 (anonymous class extends com.data.network.framework.INetworkCallbackStub)∗referencescom.common.util.image.SceneBitmapDownload.info∗referencescom.common.util.image.BitmapDownloadInfo.imageLoadInterface∗referencescom.ui.common.RoundedImageView4.this$0 (anonymous class implements com.common.util.image.ImageLoadInterface)

* references com.ui.common.RoundedImageView.mContext

* leaks com..ui.theme.ThemeListActivity instance

定位问题

通过堆栈信息可以清楚的看到Activity到GCRoot的完整引用链，最终泄露是由于继承INetworkCallbackStub的匿名类没有被释放。通过函数名就可以知道INetworkCallbackStub是Android自动生成的用于跨进程通信的框架，到对应的NetSceneBase查看对应的代码：

private INetworkCallback.Stub networkCallback = new INetworkCallback.Stub()

@Override

public void onResult(int errType, int respCode, WeMusicCmdTask task)

throws RemoteException {

NetSceneBase.this.onResult(errType, respCode, task);

}

@Override

public void onWorking(long progress, long total) throws RemoteException {

NetSceneBase.this.onProgress( progress, total );

}

};

接着再查找networkCallback的引用发现，除了跨进程传递给网络进程外没有其他任何地方引用了networkCallback。

而网络进程在完成相应的网络请求后，便将networkCallback置null，那这里的GC ROOT又是怎么回事呢？

继续看代码，networkCallback是跨进程传递给网络进程的，所以查看AIDL自动生成的代码：

@Override public boolean send(com.data.network.WeMusicCmdTask task, com.data.network.framework.INetworkCallback callback) throws android.os.RemoteException

{

android.os.Parcel _data = android.os.Parcel.obtain();

android.os.Parcel _reply = android.os.Parcel.obtain();

boolean _result;

try {

_data.writeInterfaceToken(DESCRIPTOR);

if ((task!=null)) {

_data.writeInt(1);

task.writeToParcel(_data, 0);

}

else {

_data.writeInt(0);

}

_data.writeStrongBinder((((callback!=null))?(callback.asBinder()):(null)));

mRemote.transact(Stub.TRANSACTION_send, _data, _reply, 0);

_reply.readException();

_result = (0!=_reply.readInt());

if ((0!=_reply.readInt())) {

task.readFromParcel(_reply);

}

}

finally {

_reply.recycle();

_data.recycle();

}

return _result;

}

跨进程传输必须用到Parcel，在这段代码里有这句_data.writeStrongBinder((((callback!=null))?(callback.asBinder()):(null)));

而这个_data就是Java层的Parcel对象。PS：这里的callback其实是一个Binder对象，而Binder对象构造函数里面有如下这段代码

public Binder() {

init();

if (FIND_POTENTIAL_LEAKS) {

final Class extends Binder> klass = getClass();

if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&

(klass.getModifiers() & Modifier.STATIC) == 0) {

Log.w(TAG, "The following Binder class should be static or leaks might occur: " +

klass.getCanonicalName());

}

}

}

可以看到如果Binder对象是匿名类、内部成员类或者是局部类就有可能出现内存泄露。

接着往下看

public final void writeStrongBinder(IBinder val) {

//调用native方法

nativeWriteStrongBinder(mNativePtr, val);

}

static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jint nativePtr, jobject object)

{

Parcel* parcel = reinterpret_cast(nativePtr);

if (parcel != NULL) {

//ibinderForJavaObject,这里的object就是对应java层IBinder也就是networkCallback

const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));

if (err != NO_ERROR) {

signalExceptionForError(env, clazz, err);

}

}

}

sp ibinderForJavaObject(JNIEnv* env, jobject obj)

{

if (obj == NULL) return NULL;

//这里obj是Java层的Binder对象，走下面这部分逻辑。最后调用jbh->get获得native层的IBinder对象指针。

if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) {

JavaBBinderHolder* jbh = (JavaBBinderHolder*)env->GetIntField(obj, gBinderOffsets.mObject);

return jbh != NULL ? jbh->get(env, obj) : NULL;

}

if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {

return (IBinder*)env->GetIntField(obj, gBinderProxyOffsets.mObject);

}

ALOGW("ibinderForJavaObject: %p is not a Binder object", obj);

return NULL;

}

sp get(JNIEnv* env, jobject obj)

{

AutoMutex _l(mLock);

sp b = mBinder.promote();

if (b == NULL) {

b = new JavaBBinder(env, obj);

mBinder = b;

ALOGV("Creating JavaBinder %p (refs %p) for Object %p, weakCount=%d\n",

b.get(), b->getWeakRefs(), obj, b->getWeakRefs()->getWeakCount());

}

return b;

}

JavaBBinder(JNIEnv* env, jobject object)

: mVM(jnienv_to_javavm(env)), mObject(env->NewGlobalRef(object))

//here,创建了一个全局引用，如不主动调用env->DeleteGlobalRef(object),Java层的对象也就是networkCallback就不会被释放。

{

ALOGV("Creating JavaBBinder %p\n", this);

android_atomic_inc(&gNumLocalRefs);

incRefsCreated(env);

}

解决问题

定位到问题之后就好办，这里networkCallback是由于nativ层引用了导致无法释放，那系统什么时候才能释放这部分内存呢。

结论是当网络进程的netwCallback执行finalize()，也就是网络进程对其进行垃圾回收的时候，native层才不会引用到主进程的networkCallback。所以，主进程也不是每次检测都会泄露，过段时间网络进程进行GC后，对应的Activity也就被回收了。但其实网络进程用到的内存资源是很少的也是比较稳妥，网络进程可能会很长一段时间不进行GC。那么我们能做的就是，在网络请求完成后切断networkCall与上层的引用，避免Activity的泄露。查看上面的引用链，networkCall是网络进程和主进程通讯的接口，imageLoadInterface是业务层和UI的接口。切断这两个引用的任何一个都可以避免底层的内存泄露进一步导致Activity的泄露，从这里也是看出RoundedImageView这个控件编码也有问题。

最后解决方法是，networkCallback不再以匿名内部类实现，而是单独以一个类实现然后将NetSceneBase以参数的形式传递给NetworkCallback，在网络请求结束后将netSceneBase置null。

总结

以上就是这个case从发现到解决的全部过程，可以看出导致内存泄露的原因有两个 1.忽略了Android底层组件的工作机制以及各个对象的生命周期。 2.上层逻辑编码问题，imageLoadInterface接口没有及时注销。 PS：文章中使用的工具LeakCanary，DDMS和MAT还是很强大的，具体用法google即可。