Closed Jaehwa-Noh closed 3 weeks ago
AppStartup is no magic. Here, it even increases the complexity because more code needs to be executed. The main goal of this library is to merge ContentProvider
s (which are heavy objects to create) into a single one.
The metrics displayed here do not show any meaningful improvement, and the new API choices are questionable 😕
Thanks for your comment.
Yes, I know the app startup library isn't magic. As you said, this is for expensive object initialization. Initialize as fast as possible as app is starting up.
Actually I disappoint from results, it improve a little bit the startup time. It looks like not expensive to initialize the ProfileVerifierLogger
.
I would just. do one more test manual initialize WorkManager
, then if there's no improved results then this, I will consider close this PR.
It seems no different even apply custom initialize WorkManager. I close this PR.
What I have done and why
Apply App startup library to optimize startup time.
I think the
StartupBenchmark_startupPrecompiledWithBaselineProfile
is the main factor. See theStartupBenchmark_startupPrecompiledWithBaselineProfile
's median, It reduces 5%(1,769.8 -> 1,680.1) startup time.StartupBenchmark_startupPrecompiledWithBaselineProfile
StartupBenchmark_startupWithoutPreCompilation
StartupBenchmark_startupWithPartialCompilationAndDisabledBaselineProfile
StartupBenchmark_startupFullyPrecompiled