このANRログから有用なものを得るには

Question

私は今数週間ANRに苦労していますが、今でもthisのようなログを見ていません。それはstackoverflowのためには長すぎるので、どの部分が役に立つかもわかりません。 バックグラウンドで処理されているネットワーク要求が大量にある（そして、私はほぼ100％がメインスレッドに含まれていないことがわかります）、私はUIのようなものもたくさん作っています私はSharedPreferencesの大きな変更を観察し、可能な背圧を処理するためにsampleメソッドを使用しているので、RxJava観測値を介して共有プリファレンスからrecyclerviewsを設定しています。ヒントありがとう、私は完全に失われています。

Answer 1

複数のプロセスのスレッドダンプがあります。便利な部分に到達するには、プロセスを見つけるまで "Cmd line"を検索することができます（ "cz.vcelka.androidapp"、pidは21574）。

メインスレッドが何とかブロックされていることを意味するANRが表示された場合は、そのスタックトレースを確認する必要があります。ここでは、次のとおりです。

"main" prio=5 tid=1 Waiting 
    | group="main" sCount=1 dsCount=0 obj=0x74bc2fa0 self=0xb4db6500 
    | sysTid=21574 nice=0 cgrp=default sched=0/0 handle=0xb6fc1b34 
    | state=S schedstat=(0 0 0) utm=785 stm=88 core=1 HZ=100 
    | stack=0xbe29a000-0xbe29c000 stackSize=8MB 
    | held mutexes= 
    at java.lang.Object.wait!(Native method) 
    - waiting on <0x05853836> (a java.lang.Object) 
    at java.lang.Thread.parkFor$(Thread.java:1220) 
    - locked <0x05853836> (a java.lang.Object) 
    at sun.misc.Unsafe.park(Unsafe.java:299) 
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) 
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:810) 
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:971) 
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1278) 
    at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:203) 
    at android.app.SharedPreferencesImpl$EditorImpl$1.run(SharedPreferencesImpl.java:366) 
    at android.app.QueuedWork.waitToFinish(QueuedWork.java:88) 
    at android.app.ActivityThread.handleStopActivity(ActivityThread.java:3560) 
    at android.app.ActivityThread.-wrap20(ActivityThread.java:-1) 
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1373) 
    at android.os.Handler.dispatchMessage(Handler.java:102) 
    at android.os.Looper.loop(Looper.java:148) 
    at android.app.ActivityThread.main(ActivityThread.java:5417) 
    at java.lang.reflect.Method.invoke!(Native method) 
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) 

だからあなたのメインスレッドがCountDownLatchSharedPreferences内のコード上で待機してブロックされています。 SharedPreferencesのソースコードを見て、もっと詳しく調べることができます。ある時点でSharedPreferences.Editor.apply()を呼び出すと、SharedPreferencesコードがディスクへの書き込みをワーカースレッドにエンキューしました。またawaitCommitは（CountDownLatchによって）書き込み動作を待機Runnableであり、そしてQueuedWork.add()アクティビティのメソッドが呼び出されたときにメインスレッドにが行われる作業をエンキューする方法であり、QueuedWork.add(awaitCommit)呼ばれます。それが起こったのです：が呼び出されました。そして、メインスレッドはワーカースレッドで書き込み操作を完了するのを待っています。

問題は、投稿したログが不完全であることです。 CountDownLatch.countDown()を一度も呼び出さなかったワーカースレッドを含むいくつかのスレッドが存在しないため、デッドロックの原因を特定することはできません。ログ全体（あなたのプロセスのために、私は他のものが有用であるとは思わない）を投稿すれば、おそらくもっと助けることができます。

編集：私はsomeone else hereが同じ問題に遭遇したことに気付きました。彼らのために、ワーカースレッドはfsync(2)でスタックされていました。 fsyncは、ファイルが大きくてディスクがビジーの場合は、実際には遅くなることがあります（複数秒間など）。私はそれがANRを引き起こしていると思います。私はそれがSharedPreferencesのバグとして分類されるかどうかは分かりません... から呼び出されたとしても、メインスレッドで長いブロック操作を引き起こすのはちょっと変わったようです...これが本当に問題であれば、唯一の回避策です私はapply()の代わりにcommit()を使用することが考えられます。これは同期書き込みを行うためです。ディスクにフラッシュするのにかなり時間がかかるような特別な設定では、バックグラウンドスレッドから実行する必要があります。

またはSharedPreferencesファイルが大きすぎます（この場合、データベースを使用してスリム化することもできます）。