Android点击EditText触发OutOfMemoryError问题求助

Hey there, let's dig into this OOM issue you're facing when clicking on EditTexts. The error log gives a key clue: the OOM is happening while the system tries to print a stack trace for an uncaught exception. That means there's an underlying problem causing repeated exceptions—and each time the exception is thrown, the system generates massive amounts of string data (from stack traces) that quickly eats up your memory.

Let's break down actionable steps to fix this:

1. Find the real root exception (not the OOM crash) #

The log you shared is the OOM that happens when reporting a crash, which hides the actual error that started the chain reaction. To get the original exception:

• Connect your device to your computer
• Run adb logcat -v time in your terminal before clicking the EditText
• Watch for the first exception that appears right before the memory spikes and OOM crash. That's the trigger you need to fix.

2. Check for infinite loops in EditText listeners #

You mentioned commenting out the onTextChange lambda—was that extension function doing something that could trigger another text change? For example:

• If queryUsers updates LiveData that in turn modifies the EditText's text
• Or if selecting a result from the recycler view sets the EditText content, which re-triggers the search

Even with that lambda commented, double-check for other listeners attached to EditTexts (in XML, global application code, or other fragments/activities). An infinite loop of text changes → actions → text changes would flood memory with objects and logs.

3. Deep dive into your heap dump #

You saw lots of String, char[], and StringBuilder instances in Profiler—let's get specific:

• When memory starts climbing after clicking the EditText, take a Heap Dump (click the "Dump heap" button in Android Profiler)
• Filter for String in the class list, then sort by "Retained Size" to find the largest memory hogs
• If you see thousands of identical stack trace strings or extremely long text blocks, that confirms repeated exception logging is the culprit.

4. Verify ViewModel and LiveData interactions #

Your queryResults LiveData is observed by the fragment—could updating this LiveData trigger code that interacts with the EditText? For example:

• Does selecting a user from the recycler view set text in search_input? If so, does that accidentally re-trigger the search logic?
• Double-check your ViewModelFactory to ensure it's not creating unexpected references to fragments or EditTexts that could cause leaks or unintended loops.

5. Rule out global issues #

Since the problem happens with any EditText (even in dialogs or plain activities), it might be a global setup issue:

• Do you have custom styles applied to all EditTexts via your theme?
• Are you using any third-party input libraries or custom EditText subclasses?
• Check your Application class or base activity/fragment for global EditText listeners or initialization code that could misbehave.

6. Test with a minimal reproduction case #

Create a brand new empty Activity with just a plain EditText (no ViewModel, no fragments). If the OOM still happens, the issue is in your global app setup (themes, libraries, or application class). If not, gradually add code from your SearchFragment to the test Activity until the issue reappears—this will help you isolate exactly which part of your code is causing the problem.

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