最近适配Android P时，发现我的应用在网络切换时会导致应用被系统进程杀死，然后重启。在查看日志后看到如下：
12-20 16:16:10.948 1000 1232 1299 E ActivityManager: Uid 10038 sent too many Binders to uid 1000
12-20 16:16:10.949 1000 1232 1299 I ActivityManager: Killing 6814:com.xxxx.xxxxxxxu0a38 (adj 200): Too many Binders sent to SYSTEM
12-20 16:16:10.952 1000 1232 1299 W ActivityManager: Scheduling restart of crashed service com.xxxx.xxxxx/.xxxx.X in 1000ms
意思大概是应用对系统的跨进程调用次数太多，经过搜索发现日志在Android P源码的ActivityManagerService.java的15327行左右：
BinderInternal.nSetBinderProxyCountWatermarks(6000,5500);
BinderInternal.nSetBinderProxyCountEnabled(true);
BinderInternal.setBinderProxyCountCallback(
new BinderInternal.BinderProxyLimitListener() {
@Override
public void onLimitReached(int uid) {
Slog.wtf(TAG, "Uid " + uid + " sent too many Binders to uid "
+ Process.myUid());
if (uid == Process.SYSTEM_UID) {
Slog.i(TAG, "Skipping kill (uid is SYSTEM)");
} else {
killUid(UserHandle.getAppId(uid), UserHandle.getUserId(uid),
"Too many Binders sent to SYSTEM");
}
}
}, mHandler);
这是Android P新增的代码，目的是对Binder的创建与销毁进行管理，第一行代码是给整个Android系统所能创建的Binder数量的最大值进行了限制，如果超过了6000，就会回调第三行设置的接口回调。
native层的实现如下：
// file name：BpBinder.cpp
BpBinder* BpBinder::create(int32_t handle) {
int32_t trackedUid = -1;
if (sCountByUidEnabled) {
trackedUid = IPCThreadState::self()->getCallingUid();
AutoMutex _l(sTrackingLock);
uint32_t trackedValue = sTrackingMap[trackedUid];
if (CC_UNLIKELY(trackedValue & LIMIT_REACHED_MASK)) {
if (sBinderProxyThrottleCreate) {
return nullptr;
}
} else {
if ((trackedValue & COUNTING_VALUE_MASK) >= sBinderProxyCountHighWatermark) {
ALOGE("Too many binder proxy objects sent to uid %d from uid %d (%d proxies held)",
getuid(), trackedUid, trackedValue);
sTrackingMap[trackedUid] |= LIMIT_REACHED_MASK;
if (sLimitCallback) sLimitCallback(trackedUid);
if (sBinderProxyThrottleCreate) {
ALOGI("Throttling binder proxy creates from uid %d in uid %d until binder proxy"
" count drops below %d",
trackedUid, getuid(), sBinderProxyCountLowWatermark);
return nullptr;
}
}
}
sTrackingMap[trackedUid]++;
}
return new BpBinder(handle, trackedUid);
}
可以看到随着Binder的创建成功，trackedUid所对应的Binder创建数会自增 sTrackingMap[trackedUid]++;
然后一旦发现Binder数量超过开始设置的值（6000） if ((trackedValue & COUNTING_VALUE_MASK) >= sBinderProxyCountHighWatermark) 就会触发回调 if (sLimitCallback) sLimitCallback(trackedUid);
我们知道四大组件都是使用Binder来与系统交互，那么到底是那种Binder被滥用导致被杀呢。
继续查看日志发现在Binder超过上限后会打印如下日志：
BinderProxy descriptor histogram (top 10 ):
#1: broadcastBinder
...
在知道了是广播的问题之后，查找代码，发现在一处网络状态监听器的工具类实现中，有如下代码实现：
while (true) {
BroadcastWaiter broadcastWaiter = new BroadcastWaiter();
mContext.registerReceiver(
broadcastWaiter, new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION));
try {
if (available(mContext, mWifiOnly)) { break; }
broadcastWaiter.waitTimeout(DateUtils.MINUTE_IN_MILLIS * 1);
} finally {
mContext.unregisterReceiver(broadcastWaiter);
}
}
broadcastWaiter是一个监听网络状态的BroadcastReceiver，调用waitTimeout会阻塞当前线程，等待网络改变。这段代码看似没有问题，其实在调用waitTimeout时阻塞当前线程根本没有开始长时间的阻塞。实际情况是：由于ConnectivityManager.CONNECTIVITY_ACTION是sticky广播，在刚注册了广播之后，就立即收到了这个广播，从而结束了阻塞，回到循环，然而此时并没有恢复网络连接，我们只是收到了网络状态改变的sticky广播，所以这个BroadcastWaiter的实现并没有起到监听作用，从而导致无限注册广播监听，最后被系统杀死。
分析至此，对于这个问题，我的解决方案是在onReceive回调中通过判断isInitialStickyBroadcast()过滤sticky广播。
最后，不得不说Android P的binder数量检查机制确实是一个好的新特性，可以发现应用中滥用Binder的代码，帮助改进，减少手机功耗。