如何解决Binder泄漏问题

作者：王小二C  2019/09/06

前言

[011]一个看似是系统问题的应用问题的解决过程^[1]中我们解决了一个注册过多的BroadcastReceiver导致的某一次发送广播失败的问题。我这边遇到了一个类似的问题，但是我用了一个可能网络上从来没有提出过的方法，解决了这个问题，写下这个文章记录一下，如果三年前的我肯定想不出这种解决手段。

问题

简单看了一下log，发现和[011]一个看似是系统问题的应用问题的解决过程^[2]的root cause是一样的，还是在这次发广播的Binder通信中无法申请足够的buffer。

1143 1297 W BroadcastQueue: Can't deliver broadcast to com.android.systemui (pid 2107). Crashing it.	
1143 1297 W BroadcastQueue: Failure sending broadcast Intent { act=android.intent.action.BATTERY_CHANGED flg=0x60000010 (has extras) } 	
1143 1297 W BroadcastQueue: android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died	
1143 1297 W BroadcastQueue: at android.os.BinderProxy.transactNative(Native Method)	
1143 1297 W BroadcastQueue: at android.os.BinderProxy.transact(Binder.java:1129)	
1143 1297 W BroadcastQueue: at android.app.IApplicationThread$Stub$Proxy.scheduleRegisteredReceiver(IApplicationThread.java:1237)	
1143 1297 W BroadcastQueue: at com.android.server.am.BroadcastQueue.performReceiveLocked(BroadcastQueue.java:496)	
1143 1297 W BroadcastQueue: at com.android.server.am.BroadcastQueue.deliverToRegisteredReceiverLocked(BroadcastQueue.java:715)	
1143 1297 W BroadcastQueue: at com.android.server.am.BroadcastQueue.processNextBroadcastLocked(BroadcastQueue.java:875)	
1143 1297 W BroadcastQueue: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:834)	
1143 1297 W BroadcastQueue: at com.android.server.am.BroadcastQueue$BroadcastHandler.handleMessage(BroadcastQueue.java:172)	
1143 1297 W BroadcastQueue: at android.os.Handler.dispatchMessage(Handler.java:106)	
1143 1297 W BroadcastQueue: at android.os.Looper.loop(Looper.java:193)	
1143 1297 W BroadcastQueue: at android.os.HandlerThread.run(HandlerThread.java:65)	
1143 1297 W BroadcastQueue: at com.android.server.ServiceThread.run(ServiceThread.java:44)	
1143 1297 W BroadcastQueue: Can't deliver broadcast to com.android.systemui (pid 2107). Crashing it.

初步分析

首先我按照之前解决问题的思路，看systemui是否注册了过多的BATTERY_CHANGED的广播，但是排查了好多遍代码，好像systemui并没有注册过多的广播，这条路走不通。

查看内存信息

通过反复的测试，我发现systemui中存在大量的Local Binder，这个代表systemui创建了2207个Binder的Server端，这明显是不正常的。

** MEMINFO in pid 2558 [com.android.systemui] **	
 Objects	
               Views:     4976         ViewRootImpl:        5	
         AppContexts:      201           Activities:        1	
              Assets:       21        AssetManagers:        0	
       Local Binders:     2207        Proxy Binders:      267	
       Parcel memory:       91         Parcel count:      434	
    Death Recipients:      196      OpenSSL Sockets:        0	
            WebViews:        0

如果找到Binder对象莫名增长的原因？

方案1：抓Hprof的文件

通过抓Hprof的文件，想查看Binder这个类的引用名，发现都是临时变量，并没有引用名，这条路走不通。

方案2：纯看代码

由于这个模块不是我负责的，我也不是特别熟悉，这条路也走不通

重要发现

正当我一筹莫展的时候，同事发现反复进行某个操作的时候，会导致Binder增加，这个给了我一些线索，这个时候其实如果去反复看这个操作的代码，我相信肯定可以找到原因，但是这个也只是把大海捞针变成了游泳池捞针，还是挺费时间的，对于代码不熟悉的我来说，这个难度有点大。

#这样的Binder对象对系统有威胁吗？假如我按照以下的代码，创建多个Binder对象，其实对系统没有威胁，因为这样子的Binder对象并不会在Binder驱动中创建Binder Node，说白了就是一个普通类，其他进程并不会持有这个Binder的BinderProxy对象。

while(true) {	
    Binder binder = new Binder();	
}

怎么的Binder对象对系统有威胁？

首先我们可以确认，systemui创建的Binder对象肯定是匿名的Binder对象，匿名的Binder对象只有通过Binder的接口传递的时候才会创建Binder Node，这样子才有威胁。既然要通过Binder的接口，必定要走以下代码，所以我在下面加了这个Debug Log，我前面所说的关键方法，这个Debug Log。

Parcel.java	
public final void writeStrongBinder(IBinder val) {	
    if(Binder.getCallingUid() == 10049) {//10049是systemui的uid	
       android.util.Log.v("kobewang", "writeStrongBinder", new Exception("kobewang"));	
    }	
    nativeWriteStrongBinder(mNativePtr, val);	
}

发现了异常的log

从下面的异常堆栈，发现一个问题不管是addCallback，还是removeCallback，都会调用registerSoftApCallback，这不是明显的错误了吗，不应该是removeCallback调用unregisterSoftApCallback才对嘛。

kobewang: writeStrongBinder	
kobewang: java.lang.Exception: kobewang	
kobewang:     at android.os.Parcel.writeStrongBinder(Parcel.java:738)	
kobewang:     at android.net.wifi.IWifiManager$Stub$Proxy.registerSoftApCallback(IWifiManager.java:2341)	
kobewang:     at android.net.wifi.WifiManager.registerSoftApCallback(WifiManager.java:2664)	
kobewang:     at com.android.systemui.statusbar.policy.HotspotControllerImpl.updateWifiStateListeners(HotspotControllerImpl.java:128)	
kobewang:     at com.android.systemui.statusbar.policy.HotspotControllerImpl.addCallback(HotspotControllerImpl.java:94)	
kobewang:     at com.android.systemui.statusbar.policy.HotspotControllerImpl.addCallback(HotspotControllerImpl.java:35)	
kobewang:     at com.android.systemui.qs.tiles.HotspotTile.handleSetListening(HotspotTile.java:84)	
kobewang:     at com.android.systemui.qs.tileimpl.QSTileImpl.handleSetListeningInternal(QSTileImpl.java:401)	
kobewang:     at com.android.systemui.qs.tileimpl.QSTileImpl.access$700(QSTileImpl.java:70)	
kobewang:     at com.android.systemui.qs.tileimpl.QSTileImpl$H.handleMessage(QSTileImpl.java:544)	
kobewang:     at android.os.Handler.dispatchMessage(Handler.java:106)	
kobewang:     at android.os.Looper.loop(Looper.java:193)	
kobewang:     at android.os.HandlerThread.run(HandlerThread.java:65)	
kobewang: writeStrongBinder	
kobewang: java.lang.Exception: kobewang	
kobewang:     at android.os.Parcel.writeStrongBinder(Parcel.java:738)	
kobewang:     at android.net.wifi.IWifiManager$Stub$Proxy.registerSoftApCallback(IWifiManager.java:2341)	
kobewang:     at android.net.wifi.WifiManager.registerSoftApCallback(WifiManager.java:2664)	
kobewang:     at com.android.systemui.statusbar.policy.HotspotControllerImpl.updateWifiStateListeners(HotspotControllerImpl.java:128)	
kobewang:     at com.android.systemui.statusbar.policy.HotspotControllerImpl.removeCallback(HotspotControllerImpl.java:105)	
kobewang:     at com.android.systemui.statusbar.policy.HotspotControllerImpl.removeCallback(HotspotControllerImpl.java:35)	
kobewang:     at com.android.systemui.qs.tiles.HotspotTile.handleSetListening(HotspotTile.java:88)	
kobewang:     at com.android.systemui.qs.tileimpl.QSTileImpl.handleSetListeningInternal(QSTileImpl.java:407)	
kobewang:     at com.android.systemui.qs.tileimpl.QSTileImpl.access$700(QSTileImpl.java:70)	
kobewang:     at com.android.systemui.qs.tileimpl.QSTileImpl$H.handleMessage(QSTileImpl.java:544)	
kobewang:     at android.os.Handler.dispatchMessage(Handler.java:106)	
kobewang:     at android.os.Looper.loop(Looper.java:193)	
kobewang:     at android.os.HandlerThread.run(HandlerThread.java:65)

代码分析

从代码中可以发现removeCallback方法中updateWifiStateListeners(!mCallbacks.isEmpty());是有问题的。他这样子写代码会导致removeCallback，最后走的也是registerSoftApCallback。

frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/policy/HotspotControllerImpl.java	

	
   @Override	
    public void addCallback(Callback callback) {	
        synchronized (mCallbacks) {	
            if (callback == null || mCallbacks.contains(callback)) return;	
            if (DEBUG) Log.d(TAG, "addCallback " + callback);	
            mCallbacks.add(callback);	
            updateWifiStateListeners(!mCallbacks.isEmpty());	
        }	
    }	

	
    @Override	
    public void removeCallback(Callback callback) {	
        if (callback == null) return;	
        if (DEBUG) Log.d(TAG, "removeCallback " + callback);	
        synchronized (mCallbacks) {	
            mCallbacks.remove(callback);	
            //问题点：如果mCallbacks永远存在一个callback,	
            //那么!mCallbacks.isEmpty()就永远是true。	
            updateWifiStateListeners(!mCallbacks.isEmpty());	
        }	
    }	

	
    private void updateWifiStateListeners(boolean shouldListen) {	
        mWifiStateReceiver.setListening(shouldListen);	
        if (shouldListen) {	
            //永远只会走registerSoftApCallback	
            mWifiManager.registerSoftApCallback(	
                    this,	
                    Dependency.get(Dependency.MAIN_HANDLER));	
        } else {	
            mWifiManager.unregisterSoftApCallback(this);	
        }	
    }

查看了registerSoftApCallback的代码，发现这个接口，会创建不止一个Binder对象，而是两个Binder对象，一个Binder，一个SoftApCallbackProxy。

    public void registerSoftApCallback(@NonNull SoftApCallback callback,	
                                       @Nullable Handler handler) {	
        if (callback == null) throw new IllegalArgumentException("callback cannot be null");	
        Log.v(TAG, "registerSoftApCallback: callback=" + callback + ", handler=" + handler);	

	
        Looper looper = (handler == null) ? mContext.getMainLooper() : handler.getLooper();	
        Binder binder = new Binder();//一个binder对象	
        try {	
            //SoftApCallbackProxy也是一个Binder对象	
            mService.registerSoftApCallback(binder, new SoftApCallbackProxy(looper, callback),	
                    callback.hashCode());	
        } catch (RemoteException e) {	
            throw e.rethrowFromSystemServer();	
        }	
    }

总结

其实这是一个android 9.0的原生bug，所以有时候谷歌工程师也会犯错误，那如果来解决这个问题，其实这个问题已经在android 10上被谷歌工程师修复了，修复的方式，由于保密协议，我无法贴出android 10的代码，等代码正式释放了，你们可以看看如何修复这个问题，当然你们自己也可以想想如何解决这个bug，其实也不是特别难。

PS

经过解决了两个Binder申请buffer失败的问题，我觉得最近几年持续不断的研究Binder驱动是非常值得的，换做2年前的我，可能就会和测试扯皮了，让他monitor这些问题，然后然后最后无法复现或者低概率，这个bug就被close掉了。当然我现在还会遇到一些低概率input ANR难以解决的问题，以我现在的水平，还是无法解决这类问题，我相信在我不断的学习之下，肯定最后会被我攻克的。

应用开发的建议

1.register和unregister一定要成对出现

2.对于注册callback到system_server进程，一定要注意，因为一般这种callback就是一个binder对象，所以最好注册一次，如果多处代码需要注册这个callback，请在通过你的应用层注册一个callbackmanager到system_server，然后其他callback，都注册到你的callbackmanager，这样子system_server和你的应用跨进程通信就只需要一次。

References

[1] [011]一个看似是系统问题的应用问题的解决过程: /p/160290f38ee9

扫码或长按关注