If no source files were changed by a hot reload, do not send the reload sources RPC. This slightly speeds up the no-op reloads and gives users a faster way to force a re-render.
Performs some small cleanup on the hot reload code path.
- Combines nested try/catch into single try catch, update on clause now that package:vm_service is used and Map does not need to be caught.
- Cache FlutterViews for the lifetime of the hot reload method handler
- Set asset directory path once during startup and remove conditional set during hot reload
A change which sped up hot restart locally caused many of the devicelab measures to regress. I think this is because we do not measure when the isolate is actually "ready", so starting a reload or restart prematurely can cause time spent doing initialization to be registered as part of the reload operation.
A fix for this would be to have the framework include some sort of "initialization complete" event ... but it is not clear what the correct trigger would be. Perhaps after the first frame is successfully registered?
(9a3a0dc caused the benchmark regression - possibly since we spend less time syncing files now so we start the restart earlier)
For historical reasons, the flutter tool uploads dill files to paths based on the entrypoint URI. This isn't actually necessary, and the tool can use specific files : main.dart.incremental.dill for incremental dills, and main.dart.dill/main.dart.swap.dill for full dills. This allows hot restarting applications with an entrypoint outside of lib/ and simplifies the devFS code.
Fixes#63243
If the vm of an attached device rejects a hot reload, pretty print the reason. Suggest a hot restart so that users are aware that they do not have to detach and rebuild. Also resets the last compilation time, so a subsequent restart would still apply the last change. Adds an integration test for the const field removal.
Fixes#64027
Improve our ability to measure the performance of hot restart. Also flush all UI thread tasks before calling the hot restart "complete" in benchmark mode.
If this is successful at stabilizing the benchmarks, this should be enabled for "normal" hot restart so that we can accurately track execution time.
The embedder requires that the isolate is unpaused, because the runInView method requires interaction with dart engine APIs that are not thread-safe. These APIs must be run on the same thread that would be blocked by the pause. Simply unpausing is not sufficient, because this does not prevent the isolate from immediately hitting a breakpoint, for example if the breakpoint was placed in a loop or in a frequently called method. Instead, all breakpoints are first disabled and then the isolate resumed.
To support #61407 , the tool needs to check if a single widget reload is feasible, and then conditionally perform a fast reassemble.
To accomplish this, the FlutterDevice class will have a WidgetCache injected. This will eventually contain the logic for parsing the invalidated dart script. Concurrent with the devFS update, the widget cache will be updated/checked if a single widget reload is feasible. If so, an expression evaluation with the target type is performed and the success is communicated through the devFS result. An integration test which demonstrates that this works is already present in https://github.com/flutter/flutter/blob/master/packages/flutter_tools/test/integration.shard/hot_reload_test.dart#L86
Finally, when actually performing the reassemble the tool simply checks if this flag has been set and calls the alternative reassemble method.
Cleanups:
Remove modules, as this is unused now.
The flutter daemon unconditionally waits for the appFinished signal, even if startup failed. Ensure this future is correctly completed if there is a failure in ResidentRunner.run and not just ResidentRunner.attach. Adds regression tests for run release, debug, debug web, and release web. Adds missing try catch in cold runner startup.
Manually tested with release/debug on Android and release/debug on web.
Fixes#60613
The global packages path could cause tests to fail when it would be overriden to unexpected (in test setup) values. Remove most usage and make it a configuration on buildInfo, along with most other build information. Cleanup the asset builder to require the .packages path and the resident runners to no longer require it, since they already have the information in build_info.
It needs to stick around for the fuchsia deps we do not control.
Filled #60232 for remaining work.
Remove copying from the shutdown stage since that seems risky. If the tool copies the first compilation there will still be a decent dill for initialization.
Remove caching of FlutterView. Perhaps the FlutterView RPC might return an empty list if the VM is not quite up yet? We had some old logic to poll the flutter views RPC for up to 200ms. That doesn't seem like a great approach, so instead we could forgo it entirely and trust that either the views come up before the developer tries to interact, or we crash.
Move FlutterView and related RPCs to the package:vm_service implementation. Update some getIsolate calls with catchError to match previous behavior.
- Updates tests that were previously mocking FlutterViews to use real views
- Moves the FlutterView cache from VM to FlutterDevice
- Catch SentinelException during Isolate.kill
