对mkdirs()和exists()的ANR

Question

我对我从我的申请中得到的ANR相当困惑，因为我不知道它是如何发生的。

我得到了这些密码的多重ANR：

1. File(applicationContext.filesDir).mkdirs()
2. File(applicationContext.filesDir).exists()

我得到了以下ANR报告：

1.

main (native): tid=1 systid=30195 
#00 pc 0xc57c8 libc.so 
#01 pc 0x21580 libopenjdk.so 
       at java.io.UnixFileSystem.createDirectory0(UnixFileSystem.java)
       at java.io.UnixFileSystem.createDirectory(UnixFileSystem.java:354)
       at java.io.File.mkdir(File.java:1325)
       at java.io.File.mkdirs(File.java:1352)

1. ​

#01 pc 0x21fc0 libjavacore.so 
       at libcore.io.Linux.access(Linux.java)
       at libcore.io.ForwardingOs.access(ForwardingOs.java:131)
       at libcore.io.BlockGuardOs.access(BlockGuardOs.java:76)
       at libcore.io.ForwardingOs.access(ForwardingOs.java:131)
       at android.app.ActivityThread$AndroidOs.access(ActivityThread.java:8068)
       at java.io.UnixFileSystem.checkAccess(UnixFileSystem.java:281)
       at java.io.File.exists(File.java:813)

我的应用程序目标从Android 5到Android 12，只有Android 11和Android 12获得这些ANR。

你们知道怎么解决这个问题吗？我应该在不同的IO线程上使用File(applicationContext.filesDir).mkdirs()来避免阻塞吗？

Answer 1

无论发生什么，您都应该在主线程上执行所有文件操作。这绝对不是权限问题--如果是的话，你只会被拒绝权限，而不是ANR。

话虽如此，您通常不会仅仅通过查看应用程序的fileDir，甚至在主线程上就可以获得ANR。但我的猜测是，无论是从哪里来的，设备的内部存储速度都很慢，或者你的应用程序可能被移到了外部存储。检查外部存储可用性需要更长的时间。

不管是哪种情况，就像我前面说的，它发生的原因其实并不重要。您应该在一个单独的线程上执行所有的文件IO。