DartNative's memory management strategy is strongly discouraged by the official Dart team :(

Hi, I was implementing the fully automatic memory management between Dart/Flutter and Rust (see https://github.com/fzyzcjy/flutter_rust_bridge/issues/243), so I asked some questions to the Dart team, and I find the following reply also applies to your case (http://yulingtianxia.com/blog/2020/08/22/DartNative-Automatic-Memory-Management/):

> I would strongly discourage anyone from using GC to manage non-Dart objects. If you want to manage native object lifetimes, have an explicit method like close or dispose to release native resources. GC might not ever run, or run too late.

> The VM can be aware of external object size, but GC pressure comes from new allocations. It's really not that hard to get into a scenario where you have an external object that takes up very close to a ceiling of memory you want to use, but not enough to trigger a GC. Then, new allocations happen quickly and kick off a GC, but you then run out of memory (or file handles, or some other native limited resource) before the GC can finish.

> Flutter had this problem with images for example - we were relying on the GC to clean them up, which works pretty often but does not work so well when you try to load larger images in memory constrained environments. The more we tried to make the GC clean this up for us, the worse it got - the GC sometimes couldn't work fast enough (so new images could get allocated before the GC-able ones got cleaned up, leading to OOMs), and we also were artificially running the GC too often (Because it saw these huge objects it thought it was responsible for cleaning up). So now we explicitly and eagerly dispose images/graphics resources, and you can't get into that race anymore (and we don't need as many GCs, which are pretty resource intensive to run).

Link: https://github.com/dart-lang/language/issues/1847#issuecomment-1002860171