search

dart-lang / sdk

The Dart SDK, including the VM, dart2js, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
9.94k stars 1.53k forks source link

[native_assets][resource_identifiers] Deferred loading and assets #55809

Open dcharkes opened 1 month ago

dcharkes commented 1 month ago

@mosuem and I had a bunch of discussions around loading units and native assets.

Tree shaking whole native assets if they're completely unused is kind of a special case of loading units. E.g. the asset doesn't end up in any of the loading units.

One of the main questions is whether we can let the Dart&Flutter SDK do this, or whether this needs to be part of the native_asset_cli protocol.

If assetLoadBytes has a must be const assetId (and @Native already has a const asset id), then we might be able to do it in the SDK and avoid ever having to add loading units to the build and link hook protocols.

If making the assetId being const in loadBytes is too restrictive, we could consider having an AssetReference(String assetId) implements RecordReference which can be sprinkled on methods.

However, if even that turns out to be too restrictive (because some const string arguments are passed to some method, and there is some arbitrary mapping to asset Ids which is easily implemented in build or link hooks), then the loading units should be part of the (build and) link hook protocol.

Currently, the tree-shaking of whole assets must also be implemented by a package author in their link hook. We have an open issue for automatically not bundling it based on the @Native annotations (https://github.com/dart-lang/sdk/issues/52970#issuecomment-1641455612).

dcharkes commented 1 month ago

@mosuem suggested that instead of assetLoadBytes with a param mustBeConst, we can have

@Data(String assetId)
external Future<Unint8List> myAssetBytes;

This would fully align it with with how @Native() external FFI calls are working. The assetId is forced to be const.

We would need to see if this covers all the use cases, or whether we do need to provide some way of providing abstraction on top of it.

dcharkes commented 1 month ago

We would need to see if this covers all the use cases, or whether we do need to provide some way of providing abstraction on top of it.

We can enable abstraction by making assetId in the @Data annotation optional and requiring it is a param on the external:

@Data()
external Future<Unint8List> myAssetBytes(String assetId);

Longer explanation: https://github.com/dart-lang/sdk/issues/54003#issuecomment-2128761001