Android Embedding unconditionally calls NotifyLowMemory in onTrimMemory

[dnfield]

Specifically, here:

https://github.com/flutter/engine/blob/dd28b6f1c8e68089dab16ebce9f629f309690027/shell/platform/android/io/flutter/embedding/android/FlutterActivityAndFragmentDelegate.java#L781-L786

Whereas we only notify the application code if the memory level is RUNNING_LOW, which also seems like a bug.

It seems like we should also notify the application if we have RUNNING_CRITICAL or if it's the LOW/CRITICAL for not running.

It also seems like we should check at least for RUNNING_LOW/RUNNING_CRITICAL before telling the Dart VM to potentially GC. On lower end devices, I've observed this particular codepath triggering a 250ms during the critical path to first frame.

[dnfield]

/cc @blasten @xster fyi

[dnfield]

One thought is that if we have not yet rendered a frame, we should avoid notifying unless the memory is *CRITICAL.

[dnfield]

Added a little instrumentation and this may be appropriate in the specific case of the trace I'm seeing, even if our level detection is a little suspicious.

[blasten]

right. Do you know where the 250ms are spent? is it in performDeferredCleanup ? https://github.com/flutter/engine/blob/825c409164c1c78cef1e9e3ee3f47b066c1294e7/shell/common/rasterizer.cc#L130

0ms for the LRU cache seems very low, isn't it?

[dnfield]

It's ~250ms in a dart GC. e.g.

Where that CollectOldGeneration is taking 256 CPU/321ms wall time.

[dnfield]

Here's another example though, where the app was definitely not in the background. At the end of the first Choreographer#doFrame, Android calls trimMemory, which immediately triggers a GC when we'd want to be more focused on producing the first frame:

[dnfield]

(This time the trim memory was almost certainly a RUNNING_LOW rather than a RUNNING_CRITICAL or UI_HIDDEN)

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.