☂️ Lightweight Flutter Engines #72009
Comments
This comment has been minimized.
This comment has been minimized.
|
As a preliminary check on the current state on the engine repo head, on a Pixel 3 with 5 runs with a mixture of force gc before each step and not, using the default create counter app as a test sample, creating 10 engines vs 1 engine costs 0.83mb extra per engine, with the first normal engine costing an average of 35.3mb in my setup. |
|
Looking like iOS will be 1.13MB per additional engine on engine repo master head |
|
On the latest master head, the per engine overhead is just 180kB now for both Android and iOS. This matches our prototype more correctly. |
|
The memory is still increased by 32M（not ～180K ），when new Flutter instance in new FlutterViewController by FlutterEngineGroup（ios） each additional Flutter instance in new FlutterViewController beyond the first instance ， |
|
Running again on stable 2.0.1: 1 engine: 2 engines: The 2 engine case happens to be smaller than the 1 engine case since it's within the margin of error. We took the 180kB measurement by taking many runs and taking the median number. Also on the VM tracker: 1 engine: 2 engines: It takes a bit of work to get the right number (and then de-noise it again by taking multiple runs). We have to remove the "Performance tool data" memory from both the before and after's dirty size to get the real application memory consumption. But you can see the ballpark at least. Also note, the measured memory is the cost of the Flutter Engine supporting a second engine (which includes the Java/Obj-C bootstrapping classes, a second instance of the core C++ engine, a second Dart isolate etc) and the cost of a second Flutter Framework instance (all the Flutter Dart layers from Foundation to Material) in a minimal app. If you have a full Flutter application which consumes memory itself (such as reading files, downloading network resources etc) and then create a second instance of your application, it'll likely consume 2x the memory. It would be upon you, the user, to modularize your code to run separate code (such as via different entrypoints) to show separate UI on multiple Flutter instances as needed. Also follow dart-lang/sdk#36097 for future plans on sharing Dart data between isolates and #72033 for potentially sharing image caches between Flutter instances. If you share a simple reproduction project for your case, we can take a look to debug as well. It's very possible we have a bug as well. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
hi folks, according to the https://flutter.dev/docs/development/add-to-app/multiple-flutters
is it planned to remove the limitation above? |
|
now I have found few problems by used multi engine with android/ios:
|
|
Hello @gaaclarke can you please help us or am I wrong in this thread? We have the following scenario:
Could be use the multiple Flutters feature for this? Your help would be much appreciated. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
android FlutterEngineGroup destroyEngine false, open FlutterActivity with this engine multi times, SystemChrome.setSystemUIOverlayStyle only first time open FlutterActivity work |
|
I needed to share data between multiple flutter instances in an add-to-app scenario. Created a package to help with it: synced_bloc. A bloc that is synced across platform channels. Snippet from the readme:
|
|
Hello @gaaclarke, I found an interesting issue with the EngineGroups that is actually easy to reproduce and would like to understand if it's a known behavior or not. On the MultipleFlutters example project, when adding any platform view (WebView, GoogleMaps) to the Flutter screen, everything works normally. But there's a bug happening when the first engine of the group was never loaded into a ViewController, when moving from one screen with PlatformView to another screen with/without platform view, the next engine crashes with EmptyScreen, and no logs on Native neither on Flutter. To give a bit more context, in our project, we have a UI Less Engine that is always alive like an API to get some information from Flutter. We usually load it in the app startup to check if the deep link is available or not on the Flutter side before opening an engine, that's why this engine has no view controller attached to it. I'm working to provide the minimum reproducible code soon. |
|
About FlutterEngineGroup + PlatfromView Crash, may be same issue #127168 |
|
This issue is marked P1 but has had no recent status updates. The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub. Please consider where this bug really falls in our current priorities, and label it or assign it accordingly. This allows people to have a clearer picture of what work is actually planned. Thanks! |
|
This issue is marked P1 but has had no recent status updates. The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub. Please consider where this bug really falls in our current priorities, and label it or assign it accordingly. This allows people to have a clearer picture of what work is actually planned. Thanks! |
|
Given that most work has been complete here I think the meta issue has outlived its usefullness and I'm closing it. remaining work can be tracked in the individual bugs. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Description
This meta issue proposes an array of improvements to Flutter for supporting customers who want to use multiple Flutter instances in an app, focused on the Add-to-app use case. It includes improvements for performance and ease-of-use.
Design doc
http://flutter.dev/go/multiple-engines
Phase 1
Share Engine Components
iOS
Android
Shared
Phase 2
Share Engine Components
More performance tightening
FlutterView / FlutterEngine integration
Tests
Cleanup
Phase 3
The text was updated successfully, but these errors were encountered: