Android应用调用Calendar.getInstance()时出现ANR问题求助

Ah, I’ve seen this issue pop up before—Calendar.getInstance() might seem harmless, but under the hood, initializing a GregorianCalendar can sometimes block the main thread longer than expected, especially if the system is busy loading locale or time zone data when your app resumes. That’s exactly what’s triggering your ANR, since the main thread can’t respond to user input while stuck in that constructor.

Here’s how to fix it:

1. Move Calendar Initialization to a Background Thread #

The main thread should only handle UI work—heavy operations like date calculation should be offloaded. For modern Android apps, Kotlin Coroutines are the cleanest way to do this:

override fun onResume() {
    super.onResume()
    lifecycleScope.launch(Dispatchers.IO) {
        val cal = Calendar.getInstance()
        // Do your date calculations here
        withContext(Dispatchers.Main) {
            // Update UI with results if needed
        }
    }
}

If you’re using Java, use an ExecutorService (avoid deprecated AsyncTask):

@Override
protected void onResume() {
    super.onResume();
    ExecutorService executor = Executors.newSingleThreadExecutor();
    executor.execute(() -> {
        Calendar cal = Calendar.getInstance();
        // Perform date calculations
        runOnUiThread(() -> {
            // Update UI if required
        });
    });
}

2. Cache the Calendar Instance (If Possible) #

If your date calculation doesn’t need a fresh instance every time onResume is called, cache it to avoid reinitializing repeatedly:

private var cachedCalendar: Calendar? = null

override fun onResume() {
    super.onResume()
    lifecycleScope.launch(Dispatchers.IO) {
        val cal = cachedCalendar ?: Calendar.getInstance().also { cachedCalendar = it }
        // Use cal for calculations
    }
}

Just remember to invalidate the cache if you need fresh date/time data (e.g., when the device time changes).

3. Switch to Modern Date/Time APIs (Java Time) #

The old java.util.Calendar is notoriously slow and error-prone. If you’re targeting API 26+, or using core library desugaring for older APIs, switch to java.time classes like ZonedDateTime for a more efficient alternative:

// For API 26+ or desugared apps
val now = ZonedDateTime.now()

These modern APIs are optimized and less likely to cause blocking on the main thread.

Quick Stack Trace Context #

Your stack trace shows the app is stuck in GregorianCalendar.<init>—this is where the library loads time zone rules and locale-specific data, which can take longer than expected on busy systems. Offloading this work to a background thread eliminates the main thread freeze that triggers ANR.

内容的提问来源于stack exchange，提问作者anvesh boddupalli