[Flutter] Native memory usage keeps increasing after repeatedly creating and disposing SpineWidget on Android and Windows

[xXYxxdMC-GH]

Environment

• Android: 16
• Windows: 10 x64
• Flutter: 3.44.6
• spine_flutter: 4.2.36

Steps to reproduce

1. Create a page containing a SpineWidget.
2. Open the page and initialize the Spine animation.
3. Leave the page and dispose the widget.
4. Repeat this process many times.

Expected behavior

After disposing the SpineWidget, native memory usage should return close to the original level.

Actual behavior

Native memory usage keeps increasing after repeatedly creating and disposing SpineWidget.

On Android, after around 300-400 open/close cycles:
Native Heap: Pss: ~881 MB Rss: ~884 MB

Meanwhile:
Dalvik Heap: Alloc: ~2.9 MB

Graphics memory also remains relatively stable:
Graphics: ~64 MB

This suggests that the memory increase is not caused by Dart/Java heap growth, but likely by native resources.

The same behavior can also be observed on Windows: repeatedly creating and destroying SpineWidget instances causes process memory usage to continuously increase.

On Windows, the working set can be reduced by memory trimming, but Android native heap allocation remains high.

This issue does not occur when using normal Flutter widgets without SpineWidget.

Additional notes

Could you please check whether native resources inside the Spine Flutter runtime are properly released when SpineWidget is disposed?

Thanks.

[lukeeingram]

Thanks for the report. I tested this with spine_flutter 4.2.36 on Android 16/API 36 and Windows.

I reproduced native growth when the page was removed before the asynchronous asset load completed:

• On 4.2.36, the late load initializes the controller after the widget has been disposed and then attempts setState.
• Because there was no drawable when _SpineWidgetState.dispose() originally ran, the late drawable is never disposed.
• This retains its atlas, skeleton data, skeleton, animation state, renderer, and associated native allocations.

With a controlled delayed load on Android, 100 cycles increased native heap RSS by approximately 56 MiB using Spineboy. A Windows allocation-tracking run left 18,320 live Spine allocation records after five stale completions.

The same test on current 4.3 completed every asset read with no late initialization callbacks, no lifecycle exceptions, and no leaked Spine allocations.

This is the memory consequence of #3038. It was fixed in 4.3 by commit 516518b (516518b), which invalidates stale loads and explicitly disposes their resulting drawables.

Recommendation

The preferred solution is to upgrade to spine_flutter 4.3 and re-export the skeleton data with Spine 4.3.

If you must remain on 4.2, avoid letting SpineWidget.fromAsset own an in-flight load on a page that can be removed. Instead:

1. Load SkeletonDrawable.fromAsset yourself.
2. After the await, verify that the owning state is still mounted and that the request is still current.
3. If not, call drawable.dispose().
4. Otherwise, render it with SpineWidget.fromDrawable.
5. Dispose the retained drawable when its owner is disposed.

A plain if (!mounted) return is insufficient because the newly loaded drawable must also be disposed, and a generation check is needed if loads can be replaced.

Could you confirm whether the page can be closed before the controller’s onInitialized callback? You may also see setState() called after dispose() in debug mode or Null check operator used on a null value in profile mode.

If navigation always occurs after onInitialized and memory still grows, please provide a minimal project and the affected assets. That would indicate a different lifecycle or asset-specific path from the one reproduced here.