前言
[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
