The memory increases after the Lottie animation playback ends, and it cannot be reclaimed by GC

[Cool-PKY]

When a Lottie animation ends, instances increase and memory rises, especially the instances of the class PathInterpolator. After reading the source code, I found that it is cached in a static map, which cannot be released. Can this issue be fixed?

[xvrh]

@Cool-PKY thanks. Can you open a PR with an alternative implementation?
You can have a look at how other implementations are doing it (lottie-android etc..).

[Cool-PKY]

OK I will try.

[nekomaruh]

I noticed that my Mac started heating up significantly while running Lottie animations, and the battery drained much faster. I'm not sure if it's directly related to this issue. For now, the solution is to disable Lottie in my projects.

[hjxyyds]

same

[WeiJun0507]

I have this issue too. May I know how I can fix this?

[c1s1x1]

Has the RSS memory growth issue not been resolved yet?😖

[delfme]

Provide a reproducible sample.

[hjxyyds]

I think

Root Cause: This is caused by the native memory occupied by ui.Image not being released. The Lottie library uses Flutter's imageListener to obtain ui.Image and implements animation effects through transform transformations. However, after the animation component is unmounted, ui.Image is not manually disposed of (which is reasonable, as the author likely set shareLottieCache to avoid reloading the composition, and the composition holds the ui.Image).

Flutter's ImageCache: Additionally, Flutter itself has an ImageCache. The Image instance passed to the upper layer through imageListener is cloned, meaning that some images actually have two handles (one held by Lottie and one held by Flutter's underlying cache). Only by cleaning up both references can the native memory be reclaimed. However, this is also reasonable, as Flutter enforces keeping certain image references in its ImageCache to optimize subsequent loading performance.

Summary
Memory Not Released: ui.Image is not manually disposed of, but this is for performance optimization (shareLottieCache).
Dual References: Some images have references in both Lottie and Flutter's ImageCache, and only by cleaning up both can memory be released, but Flutter's caching mechanism is designed to improve performance.
image1:

image2:

so ，i think ，if you want to reduce memory usage, you should clear the ImageCache at appropriate times and dispose of the composition.image in ShareLottieCache

[delfme]

This doesn’t appear to be a bug, nor can I imagine it causing a crash under normal usage conditions - even with dozens of Lottie animations in the same scene - unless you’re using many abnormally large custom Lotties in an infinitely scrolling list.

[delfme]

Also, no one has provided sample code yet, so we still don’t know the exact context. For example, if the person is using RenderCache, they ofc might be running into an out-of-memory (OOM) issue. RenderCache should only be used for a single, very small animation—otherwise, it can consume up to 2GB of memory. It’s not the preferred caching solution, but rather an advanced option for specific, uncommon use cases. Stick with the standard caching method, and with a proper implementation, OOM errors should never occur.

Please "always" provide code when opening an issue (unless not feasible).

[hjxyyds]

This doesn’t appear to be a bug, nor can I imagine it causing a crash under normal usage conditions - even with dozens of Lottie animations in the same scene - unless you’re using many abnormally large custom Lotties in an infinitely scrolling list.

yes, I believe this should not be considered a bug in the Lottie library. The high memory usage is primarily due to the fact that certain Lottie animations inherently require loading images that consume a significant amount of memory. The desired outcome is for this memory to be reclaimed after the Lottie component is disposed（https://github.com/xvrh/lottie-flutter/issues/384，like this，It is still necessary to synchronously clean up Flutter's built-in ImageCache in order to release the dual references）. However, even if the Lottie library itself does not cache the composition, these images will still be referenced by Flutter's ImageCache. By using the ui.Image.debugGetOpenHandleStackTraces method (in debug mode), you can observe the reference stack traces of these images.

[lsfern]

This issue has example code code

[iosephmagno]

Answered there, please kindly do not paste chinese texts, no one has time to play with translators.

[lsfern]

@iosephmagno This issue has example code #404

Can you take the time to see it?