-
Notifications
You must be signed in to change notification settings - Fork 27.6k
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
NSBundle bundleWithIdentifier causes slowdown when creating FlutterEngine #37826
Comments
Internally we wanted to support having multiple bundles and not rely on the main bundle when looking up Flutter assets. (I'm still trying to refresh my memory about exactly why... I think we considered it a burden for add2app?) The Anyway, I'm happy to ponder this and assist however I can, but I currently am no longer set up to make and test changes, so this probably would be better owned by someone else. |
For context, the original feature request was b/112004455 |
FWIW [FlutterDartProject init] takes 4ms on iPhone SE. Debug build at dd77b73 Edit: This was recorded on a full Flutter app, not Add-to-app. |
Could have been fixed already. Feel free to close this. Previous observations with https://github.com/flutter/engine/pull/5986/files |
The [discussion on
|
@gaaclarke Our project use engineGroup, and there are some watchdog crash when create engine. |
It seems like this could be proportionate to the size of the app. For example, |
Tested with build_engine=1 internally - as a quick experiment, removing the call to |
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 |
The addition of traversing the bundles by searching for an identifier added in https://github.com/flutter/engine/pull/5986/files#diff-8e54aca7e9d4fd69a57fb86d6ec3dee2R36 adds a 100ms latency when instantiating a FlutterEngine (7ms -> 106ms on an iPod).
It's hard to figure out the original feature request from the PR. Can we revise the approach?
The text was updated successfully, but these errors were encountered: