国内优秀的网站,软文自助发稿平台oem,无锡制作网站公司,wordpress翻页函数作者#xff1a;王小二C 2019/09/06前言[011]一个看似是系统问题的应用问题的解决过程[1]中我们解决了一个注册过多的BroadcastReceiver导致的某一次发送广播失败的问题。我这边遇到了一个类似的问题#xff0c;但是我用了一个可能网络上从来没有提出过的方法#xff0c;解… 作者王小二C 2019/09/06前言[011]一个看似是系统问题的应用问题的解决过程[1]中我们解决了一个注册过多的BroadcastReceiver导致的某一次发送广播失败的问题。我这边遇到了一个类似的问题但是我用了一个可能网络上从来没有提出过的方法解决了这个问题写下这个文章记录一下如果三年前的我肯定想不出这种解决手段。问题简单看了一下log发现和[011]一个看似是系统问题的应用问题的解决过程[2]的root cause是一样的还是在这次发广播的Binder通信中无法申请足够的buffer。1143 1297 W BroadcastQueue: Cant deliver broadcast to com.android.systemui (pid 2107). Crashing it.
1143 1297 W BroadcastQueue: Failure sending broadcast Intent { actandroid.intent.action.BATTERY_CHANGED flg0x60000010 (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: Cant 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扫码或长按关注
