-
-
Notifications
You must be signed in to change notification settings - Fork 51
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
Optimize App Startup by Background Loading of Firebase Remote Config #697
Conversation
To view this pull requests documentation preview, visit the following URL: docs.page/sharezoneapp/sharezone-app~697 Documentation is deployed and generated using docs.page. |
Visit the preview URL for this PR (updated for commit 787a3e0): https://sharezone-test--pr697-fetch-remote-config-tqkxc9kh.web.app (expires Wed, 02 Aug 2023 11:14:42 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 4cb3ae61e1e018abfd9841fd3239f5b49ccc034b |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, see comments
lib/remote_configuration/lib/src/implementation/firebase_remote_configuration.dart
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I like the new approach.
Couldn't initialize be synchronous now? void initialize(...)
Yes, good catch! |
Description
In this pull request, we made significant changes to the way our application fetches and activates the Firebase Remote Config data to improve app start-up times.
Previously, our app fetched Firebase Remote Config data during its start-up sequence. This fetch-and-activate approach was a major contributor to the 11 seconds startup time our app was experiencing.
We have now moved the Firebase Remote Config fetch process to execute in the background after the application has started. This ensures that the app is not blocked waiting for these config values during startup. The fetched config values are activated on the next app launch.
This change has led to a considerable improvement in app startup times. Initial tests show startup times have dropped to just 2 seconds, down from 11 seconds - a more than 5x improvement.
Disadvantages in this strategy
The disadvantage in this strategy is that the values activated on the next launch. When there is a critical change, the user doesn't receive the values immediately. However, since we started Sharezone, 5 years ago, we never had this case. Therefore, I think it's overkill to trade bad app start times against the possibility to update critical values maybe someday.
Benchmarks
The app start is now 5,5x faster than before when using an EDGE connection.
Demo
(In the benchmarks table, I removed the time I needed to open the emulator and click the "stop" button)
Before
Screen.Recording.2023-07-21.at.12.20.44.mov
After
Screen.Recording.2023-07-21.at.12.24.15.mov
Using the values for the next start
Screen.Recording.2023-07-21.at.12.54.26.mov
Related Tickets
Fixes #696