Long monitor contention with owner

安卓Activity在finish後出現黑屏, 大概率是因爲主線程卡死。 抓trace和logcat。
04-16 16:18:17.359 W/m.lianjia.beik(30714): Long monitor contention with owner Binder:30714_6 (32307) at void java.lang.Object.wait(long, int)(Object.java:-2) waiters=0 in android.content.ComponentName com.ke.ljplugin.component.service.server.PluginServiceServer$Stub.startService(android.content.Intent, android.os.Messenger) for 5.996s
04-16 16:18:17.360 W/m.lianjia.beik(30714): Current owner stack:
04-16 16:18:17.360 W/m.lianjia.beik(30714):   (no managed stack frames)
04-16 16:18:17.360 W/m.lianjia.beik(30714): Contender stack:
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.ke.ljplugin.component.service.server.PluginServiceServer$Stub.startService(PluginServiceServer.java:554)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.ke.ljplugin.component.service.PluginServiceClient.startService(PluginServiceClient.java:106)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.ke.loader2.PluginContext.startService(PluginContext.java:516)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.lianjia.sdk.im.service.IMService.startIMService(link:100)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.lianjia.sdk.im.IMManager.initIMService(link:316)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.lianjia.sdk.im.IMManager.syncData(link:263)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.lianjia.sdk.im.IMManager.access$200(link:51)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.lianjia.sdk.im.IMManager$2.call(link:250)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.lianjia.sdk.im.IMManager$2.call(link:240)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at rx.internal.util.ActionSubscriber.onNext(ActionSubscriber.java:39)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at rx.observers.SafeSubscriber.onNext(SafeSubscriber.java:134)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at rx.internal.operators.OperatorObserveOn$ObserveOnSubscriber.call(OperatorObserveOn.java:224)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at rx.android.schedulers.LooperScheduler$ScheduledAction.run(LooperScheduler.java:107)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at android.os.Handler.handleCallback(Handler.java:873)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at android.os.Handler.dispatchMessage(Handler.java:99)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at android.os.Looper.loop(Looper.java:201)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at android.app.ActivityThread.main(ActivityThread.java:6806)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at java.lang.reflect.Method.invoke(Native method)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
04-16 16:18:17.360 W/m.lianjia.beik(30714):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)
04-16 16:18:17.360 W/m.lianjia.beik(30714): 
04-16 16:18:17.388 I/Choreographer(30714): Skipped 361 frames!  The application may be doing too much work on its main thread.

二、原因分析

Cpu Time/Call: 函數平均佔CPU時長
Real Time/Call: 函數真正執行時長,包括切換、阻塞時間。

例如圖片裏startService的Cpu Time等於12.964ms, 但Real Time等於6013.609ms, 差距非常大。 原因在於startService使用了同步機制,即阻塞等待。 Logcat的第一句java.lang.Object.wait…, 當主線程卡死但沒到ANR程度時, logcat裏提示丟幀“too much work on its main thread"。

打印日誌後可以搜索“too much”關鍵字。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章