-
Notifications
You must be signed in to change notification settings - Fork 27.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unmount everything and dispose States when host activity dies #19358
Comments
One thing that needs to be considered here is the possibility that Flutter is used across Activitys. I haven't looked much at that use-case, so I'm not sure how much of that scenario is about persisting the Dart process vs persisting Flutter hierarchy. But let's not immediately assume that Flutter should disappear when an Activity or FlutterView is destroyed - if that's what is being suggested, then someone needs to make that case very carefully and deeply. Don't forget, for example, that not all Widgets are UI. Consider an AudioPlayer widget. The UI may have disappeared, but the audio should probably keep playing. Now, half of that story is on the platform side, but it doesn't necessarily mean you want to lose the Flutter state related to that Widget/Element. A middle ground here might be an explicit signal sent to the FlutterView that you truly want to destroy the entire Flutter system. Then the developer can opt-in/opt-out. |
WRT to #19159 - if the true problem of that ticket is a failure to unregister, why would the ticket require 20 Activity restarts to develop the issue? I might expect a memory leak in that scenario, but #19159 says the issue is an ANR which is a CPU lockup, not a memory pressure issue. I'd like to understand more clearly why this disposal problem is supposedly causing that other issue... |
https://github.com/flutter/engine/pull/5640/files seems to be making the case of calling out backgroundable 'hosts' explicitly but making the Flutter side disposal an explicit signal (which may be auto-hooked) sounds great. |
Generally speaking you can't rely on the OS doing anything graceful to your app anyway, FWIW, so depending on dispose being called is asking for trouble. Consider what happens when the user pulls the battery, or the OS kills your app for using too much memory, or whatnot. |
I think with add-to-app, we should start to change how we think about platform interactions and pull parts out from the "OS doing things to your app" group into "mixed navigation" group. Related discussion (internal). In your pulling the battery scenario, we'd be in the same situation as Flutter to Flutter navigation (no automatic calls to dispose) and native to native navigation (no automatic calls to onDestroy). But otherwise, I think we should make mixed navigation API convenience a first class citizen too as opposed to our present alternative (which would involve an encapsulated Flutter view logic handling Whether they both trigger the same function ( |
@xster would you mind putting together a few sequence diagrams to show what we have now vs what you're recommending? I'm having a difficult time comprehending the recommendation in paragraph form. |
To clarify, I definitely agree that we should be calling dispose methods and so on during shutdown (otherwise I'd have suggested closing the bug!). I'm just saying that we shouldn't encourage people to rely on it. |
I'd like to reiterate that resolving this is very important for add-to-app use cases, since it would allow plugins that acquire per-widget resources to release them gracefully when widgets are disposed of. Specifically, |
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. (#739) Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
Hi Flutter Team, did you find time to work on this issue, yet? I have been running into similar issues rgd. the App State while Androids' debug setting "Don't keep activities" is turned on. |
…terView is being destroyed. Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. (flutter#739) Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…terView is being destroyed. (#739) Otherwise the exoplayer MediaPlayer objects continue generating frames after FlutterNativeView is destroyed and onFrameAvailableListener for the video target SurfaceTexture tries to access a missing engine instance. This is a workaround for widgets not receiving dispose signals when FlutterView is destroyed (flutter/flutter#19358). flutter/flutter#20989 tracks ensuring that resources are released.
…dFromEngine (#6501) In the `onDetachedFromEngine` function, the `onDestroy` method should be called instead of the `initialize` method, even though the implementation of the two functions is no different. ```java private void onDestroy() { // The whole FlutterView is being destroyed. Here we release resources acquired for all // instances // of VideoPlayer. Once flutter/flutter#19358 is resolved this may // be replaced with just asserting that videoPlayers.isEmpty(). // flutter/flutter#20989 tracks this. disposeAllPlayers(); } public void initialize() { disposeAllPlayers(); } ```
…dFromEngine (flutter#6501) In the `onDetachedFromEngine` function, the `onDestroy` method should be called instead of the `initialize` method, even though the implementation of the two functions is no different. ```java private void onDestroy() { // The whole FlutterView is being destroyed. Here we release resources acquired for all // instances // of VideoPlayer. Once flutter/flutter#19358 is resolved this may // be replaced with just asserting that videoPlayers.isEmpty(). // flutter/flutter#20989 tracks this. disposeAllPlayers(); } public void initialize() { disposeAllPlayers(); } ```
…dFromEngine (#6501) In the `onDetachedFromEngine` function, the `onDestroy` method should be called instead of the `initialize` method, even though the implementation of the two functions is no different. ```java private void onDestroy() { // The whole FlutterView is being destroyed. Here we release resources acquired for all // instances // of VideoPlayer. Once flutter/flutter#19358 is resolved this may // be replaced with just asserting that videoPlayers.isEmpty(). // flutter/flutter#20989 tracks this. disposeAllPlayers(); } public void initialize() { disposeAllPlayers(); } ```
…dFromEngine (flutter#6501) In the `onDetachedFromEngine` function, the `onDestroy` method should be called instead of the `initialize` method, even though the implementation of the two functions is no different. ```java private void onDestroy() { // The whole FlutterView is being destroyed. Here we release resources acquired for all // instances // of VideoPlayer. Once flutter/flutter#19358 is resolved this may // be replaced with just asserting that videoPlayers.isEmpty(). // flutter/flutter#20989 tracks this. disposeAllPlayers(); } public void initialize() { disposeAllPlayers(); } ```
Looking at #19159, it seems reasonable looking at the API doc to expect the State.dispose to be called when the FlutterActivity is finishing/being destroyed. Yet it never gets called and there's an inbalance between things registered and/or created during initState() and things unregistered and/or released during dispose().
Should we:
or at least have the State.dispose() API doc reference AppLifecycleState if we don't want to do this automatically?
cc @Hixie @jason-simmons
also cc @matthew-carroll since this scenario will surface more frequently with add-to-app
The text was updated successfully, but these errors were encountered: