Optimize App Startup by Background Loading of Firebase Remote Config #697
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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