Background / Context:
In enterprise-level applications (such as banking super-apps or large-scale Server-Driven UI architectures), dynamic resource injection is a core requirement. Teams frequently load custom assets and fonts over the network at runtime for specific marketing campaigns, micro-frontends, or dynamic theming.
The Problem:
Currently, FontLoader and dart:ui allow loading font bytes into the engine (loadFontFromList), but there is no mechanism to unload or clear them from memory once the dynamically injected UI is disposed.
As the application navigates through different dynamic experiences, the memory footprint continuously grows. This lack of lifecycle management leads to severe memory leaks and eventual OOM crashes, especially on low to mid-tier Android devices, making long-running Flutter applications unstable in production.
Proposed Solution:
Introduce an unload() or dispose() method in the FontLoader class (and subsequently expose a counterpart in dart:ui) to explicitly clear previously loaded fonts from the engine's typographic buffer (Skia/Impeller).
// Proposed API addition
final FontLoader fontLoader = FontLoader('DynamicCampaignFont');
fontLoader.addFont(fetchFontBytes());
await fontLoader.load();
// ... later when the dynamic UI is disposed ...
await fontLoader.unload(); // Frees up engine memory
Impact:
Resolving this provides a much-needed enterprise-grade resource management tool, preventing memory leaks for any application utilizing dynamic theming, remote widgets, or modular architectures.
I am willing to contribute the PR for the framework side if the core team agrees on the engine implementation approach.
Background / Context:
In enterprise-level applications (such as banking super-apps or large-scale Server-Driven UI architectures), dynamic resource injection is a core requirement. Teams frequently load custom assets and fonts over the network at runtime for specific marketing campaigns, micro-frontends, or dynamic theming.
The Problem:
Currently, FontLoader and dart:ui allow loading font bytes into the engine (loadFontFromList), but there is no mechanism to unload or clear them from memory once the dynamically injected UI is disposed.
As the application navigates through different dynamic experiences, the memory footprint continuously grows. This lack of lifecycle management leads to severe memory leaks and eventual OOM crashes, especially on low to mid-tier Android devices, making long-running Flutter applications unstable in production.
Proposed Solution:
Introduce an unload() or dispose() method in the FontLoader class (and subsequently expose a counterpart in dart:ui) to explicitly clear previously loaded fonts from the engine's typographic buffer (Skia/Impeller).
Impact:
Resolving this provides a much-needed enterprise-grade resource management tool, preventing memory leaks for any application utilizing dynamic theming, remote widgets, or modular architectures.
I am willing to contribute the PR for the framework side if the core team agrees on the engine implementation approach.