🛑 [Android] Stop using async void! How we crushed our ANR rate from 18% to near 0%

[kubaflo]

Originally posted by @Transis-Felipe in #35991. Copied here to continue the conversation in Discussions rather than the bug tracker. The original post is preserved below with attribution.

---

Hi everyone,

If your application is suffering from high ANR (Application Not Responding) rates and mysterious freezes, I want to share a massive lesson we learned after months of intense investigation: avoid async void like the plague.

Take a look at our user-perceived ANR rate over time:

(The orange line represents the moving average, showing the drastic drop after we eliminated async void from our codebase.)

🔍 The Problem with async void
In the .NET asynchronous model, async void is a "fire-and-forget" mechanism. While it might seem harmless for event handlers or quick background operations, it introduces critical issues in production:

Uncaught Exceptions & Crashes: Exceptions thrown in an async void method cannot be caught by a standard try-catch block wrapping the call. They are raised directly on the SynchronizationContext, which often crashes the app or leaves it in a corrupted, frozen state.

Thread Pool Starvation & Deadlocks: Because the caller cannot await an async void method, it has no way of knowing when the operation starts, yields, or finishes. This frequently leads to race conditions, blocked main threads (UI freezing), and unmanaged context switching that triggers ANRs.

🛠️ How to Fix It
The golden rule of async programming in C# is: Use async Task instead of async void. * Bad (Fire-and-forget that blocks/freezes):

public async void LoadDataAsync()
{
    // If an error happens here, the app might freeze or crash silently
    var data = await _repository.FetchHeavyData(); 
    UpdateUI(data);
}

Good (Proper Task tracking):

public async Task LoadDataAsync()
{
    try
    {
        var data = await _repository.FetchHeavyData();
        UpdateUI(data);
    }
    catch (Exception ex)
    {
        // Handle your exceptions safely here
        Log.Error(ex);
    }
}

⚠️ Not even use async void in top-level event handlers (like button clicks, e.g., private async void OnButtonClick(object sender, EventArgs e)).

📈 The Result
As you can see in the chart, our ANR rate was consistently hovering at an unacceptable 18%. After a thorough refactoring to replace async void with proper Task-based patterns and explicit error handling, the ANRs plummeted to near 0%.

If you are dealing with unexplained UI freezes, do yourself a favor: global-search your solution for async void and start refactoring.

I'd even suggest that MAUI should implement a warning for async void methods. These Android freezes make it look like MAUI itself is to blame, when it's actually an async misuse issue.

Your users will thank you!

[kubaflo]

Existing follow-up from @rokmeglicbit (original comment, copied here to preserve the conversation):

@Transis-Felipe what about public MAUI methods?

public interface IQueryAttributable
{
	void ApplyQueryAttributes(IDictionary<string, object> query);
}

does not implement interface member 'IQueryAttributable.ApplyQueryAttributes(IDictionary<string, object>)'. 'ApplyQueryAttributes(IDictionary<string, object>)' cannot implement 'IQueryAttributable.ApplyQueryAttributes(IDictionary<string, object>)' because it does not have the matching return type of 'void'.

[Mistofs]

you can use async void + exception handling inside