前言
[011]一个看似是系统问题的应用问题的解决过程中我们解决了一个注册过多的BroadcastReceiver导致的某一次发送广播失败的问题。我这边遇到了一个类似的问题，但是我用了一个可能网络上从来没有提出过的方法，解决了这个问题，写下这个文章记录一下，如果三年前的我肯定想不出这种解决手段。
问题
简单看了一下log，发现和[011]一个看似是系统问题的应用问题的解决过程的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和你的应用跨进程通信就只需要一次。
