Delay initialization of Push
See original GitHub issuePerf folks: before working on this issue, check in with Jonathan on the status: this issue may be worked on by Jonathan and it may also be blocked on other changes.
Priority: 5-10% of startup spent here. Last big chunk of perf wins before jumping into view inflation.
Some thoughts from a conversation with @hawkinsw from reviewing https://github.com/mozilla-mobile/fenix/pull/6712/.
Since the consumers for Push are FxaAccountManager and Engine, we were initializing push immediately since that was required by the Firebase SDK.
What Will rightfully noticed, is that maybe we can delay this initialization to be done much later since the consumers are not lazily initialized through UI interactions or activity creation.
This needs investigations (mostly from me) before we do this:
- Where can be move to be initialized to that isn’t immediately on startup, but soon enough to receive push messages on “startup”.
- Can we safely do this since the black box is the Firebase SDK which assumes initialization is always done in
Application#onCreate
. - Will we cause any race conditions from our initialization, i.e. Push init’d and receives a message before our consumers have init’d.
┆Issue is synchronized with this Jira Task
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (5 by maintainers)
To keep a record for the ticket:
From what I understand, FxaAccountManager is a heavy start-up which happens because of push.
We experimented with moving Push to a separate component class that lazy init’s FxaAccountManager when needed, but this had one hitch in that it broke the feature since FxA needs to register for push subscriptions the first time, before push starts to notify FxA for updates.
Diff of a test patch
What I’ve been meaning to experiment with:
For LeanPlum integration, that needs the
PushService
(FirebasePush), so we can initialize the push service and provide it to LP without init’ing the push feature and therefore FxA.What this gives us is that we don’t have to initialize fxa via push, but instead the first use of fxa (or GV for that matter) will initialize push and if the PushService hasn’t been init’d by LeanPlum yet, we can do that then as well.
This also means we don’t have to necessarily move Push to a separate component class for perf, but we really should either way because
BackgroundServices
is too chunky.Probably not since QA can’t test perf fixes.