那里有多个进程的线程转储。要到达有用的部分，您可以搜索“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)
所以你的主线程被阻塞等待CountDownLatch inside SharedPreferences代码。我们可以查看SharedPreferences的源代码来了解更多信息。在某个时刻，当你打电话时SharedPreferences.Editor.apply() https://github.com/android/platform_frameworks_base/blob/6fb921a61b0ca6bac8002e0fdbeb521453dce408/core/java/android/app/SharedPreferencesImpl.java#L361, the SharedPreferences代码将写入磁盘的操作排队到工作线程中。它也被称为QueuedWork.add(awaitCommit) https://github.com/android/platform_frameworks_base/blob/6fb921a61b0ca6bac8002e0fdbeb521453dce408/core/java/android/app/QueuedWork.java#L69, where awaitCommit is a Runnable等待写操作（通过CountDownLatch), and QueuedWork.add()是一种将待完成的工作排队的方法在主线程上当活动的onPause方法被调用。这就是发生的事情：onPause被调用，现在主线程陷入等待工作线程完成其写入操作。
现在的问题是你发布的日志不完整。缺少几个线程，包括从未调用过的工作线程CountDownLatch.countDown()，因此无法判断是什么导致了死锁。如果您发布整个日志（对于您的过程，我认为其他日志不会有用），我们可能可以提供更多帮助。
编辑：我注意到这里还有其他人 https://stackoverflow.com/questions/36905415/how-to-analyze-anr-in-sharedpreferences遇到了同样的问题。对于他们来说，工作线程被困在fsync(2). fsync如果文件很大和/或磁盘很忙，速度可能会非常慢（如几秒钟）。我想这可能是导致 ANR 的原因。我不确定这是否会被归类为错误SharedPreferences...在主线程上触发可能很长的阻塞操作似乎有点奇怪，即使是从onPause...如果这确实是你的问题，我能想到的唯一解决方法是使用commit()代替apply()，因为这将同步进行写入。您应该从后台线程执行此操作，因为在您的特定设置中，似乎可能需要相当长的时间才能刷新到磁盘！
或者也许是你的SharedPreferences文件太大了，在这种情况下，您可以尝试缩小它（例如使用数据库）。
