[native_assets_cli] Assets and deferred loading

[dcharkes]

For v1.0, we need to be convinced that we don't need to break the API later.

Dart and Flutter applications can be compiled with deferred loading.

For Dart standalone, the VM in AOT, and dart2js support deferred loading by compiling into separate "loading units".
The resources information from @ResourceIdentifier or @pragma('dart2js:resource-identifier') is organized via loading units as well.

In Flutter (for Android and web), multiple "loading units" can be assigned to a "deferred component" manually. Also assets are assigned to deferred components manually. https://docs.flutter.dev/perf/deferred-components

The question is how we should treat native code assets, wasm assets, and data assets with regards to applications being split up at runtime in multiple loading units // deferred components.

Communication from build and link hooks to Dart/Flutter

• Does the Flutter embedder have enough information to put dynamic libraries and data assets in the right "deferred component" in Flutter automatically?
• Do dart2js have enough information to put any wasm assets or data assets (read as bytes). In the right place? Is there even such thing as the right place? Or is anything loaded as HTTP requests as separate files anyway?

If the above answers are that embedders need not be supplied with information from users, then we can omit mentioning loading units (and deferred components) in the native_assets_cli Config/Output and protocol.

(If we want parity between data assets in the flutter pubspec.yaml and the native assets CLI, then we do need to output deferred components. But of course those don't say anything for Dart standalone, because there is no such concept in Dart. Dart only knows about "loading units" which are automatic.)

Communication from Dart/Flutter to build and link hooks

When running build / link hooks, would it be useful to know in what loading unit (and/or deferred component) assets are used?

Since the Dart code accessing the asset is fixed, splitting an asset up in multiple parts per bundle wouldn't work. If the asset is split up into two (or more) parts, one might as well use different asset IDs in the first place.

Side note: The current dart: API (https://dart-review.googlesource.com/c/sdk/+/351140/6/sdk/lib/ffi/assets.dart) does have no concept about deferred loading. So this might not work with deferred loading.

Bigger questions

Maybe a bigger question is whether once we start adding data assets to dart2js (which is currently the only used dart standalone configuration with deferred loading), whether we need to add a concept of "deferred components" as well, or whether "loading units" is the right abstraction.

[dcharkes]

For v1.0, we need to be convinced that we don't need to break the API later.

From an offline discussion:

• We'd want this to work for arbitrary asset types. For code assets we should support having a non-const string if the link-mode is dynamic. Data assets need to work. And probably we'd want this to work for icon assets, font assets, etc.
• It's unlikely that this has to work with link-mode not enabled. So any output would likely be only from the link hook.
• It's likely we can add this in a non-breaking change later. All assets would be considered to be in the main component without support in hooks.
• The record-use input would contain the loading units in which the annotations are.
• Flow would be: link hook gets record use annotations, link output contains in which (Dart) loading unit an asset needs to be, Flutter maps that to it's deferred components.