作者：王小二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
扫码或长按关注
