Reduce Android startup critical path work

[danielchalmers]

Summary

Focus this issue on the measured startup critical path that keeps Android users on the native splash / Blazor Getting things ready... screen. The latest debug launch logs show that the biggest known delay is database preparation and seeding work performed before the MAUI app is built, not the home page render or font loading.

This issue should stay measurement-led: optimize the work we can see in launch timings, re-measure, then decide whether broader Blazor rendering or app responsiveness work deserves separate follow-up issues.

Current evidence

From the Android debug launch captured after the lightweight logging work:

• PrepareDatabase took 1042ms.
  • CheckPendingMigrations took 911ms even though pending migrations: False.
• SeedCategories took 443ms.
  • added: 0, existing: 14, save changes calls: 14.
• SeedDebugDays took 1140ms in DEBUG.
  • requested: 1833, existing: 1793, 40 new days, 360 points.
• Created MAUI app logged at 3610ms.
• Home initialization was much smaller by comparison.
  • Home initialized in 113ms.
  • Loaded day took 111ms.
• Android Choreographer skipped-frame and Davey! duration=1157ms lines are real responsiveness symptoms, but they line up with startup work plus WebView/Blazor/debug loading.
• The log was a Debug/FastDev/debugger run, so it is useful for finding app-level work but is not a Release cold-start baseline.

Primary work

• Add lightweight startup and home-load logging using the existing Microsoft.Extensions.Logging setup. Add targeted startup logging #93
• Capture a true Release Android cold-start baseline on device.
  • Normal launch with an existing database.
  • First launch after clean install.
  • First launch after an app/schema upgrade.
• Avoid paying GetPendingMigrations().Any() on every normal launch.
  • Consider an app/schema version gate, migration marker, or equivalent cheap check before invoking EF migration discovery.
• Batch or gate category seeding.
  • Avoid one query/save cycle per default category.
  • Make an unchanged database do near-zero seed work.
• Make Debug day seeding opt-in or empty-database-only.
  • It should not dominate normal Debug startup or obscure Release behavior.
• Re-measure with the same logging after each startup-path change.

Secondary work after startup is remeasured

Only pursue these if the updated measurements show they are still material:

• Move any remaining database preparation or seed work off the CreateMauiApp() critical path.
• Optimize GetOrCreateDayAndAddPoints() if home load becomes a significant startup contributor.
• Review EF lazy loading and Razor query enumeration in hot render paths.
• Remove synchronous save calls from navigation/window lifecycle paths where they affect interaction latency.
• Make calendar and trends load/render incrementally if those screens show measurable latency.

Not pursuing as a startup fix right now

• Google Fonts removal as a standalone Android startup optimization.
  • We want Roboto on all platforms.
  • On Android, Roboto is already the platform font.
  • Removing the Google Fonts stylesheet without a WebView-visible local @font-face changes typography on non-Android platforms.
  • Remove external Google Fonts dependency from Blazor host page #92 was closed instead of merged.
• Debug/FastDev assembly-load warnings.
• libpenguin.so, Chromium DNS, Bluetooth/media, and similar WebView/platform warnings unless they appear in Release traces with measurable impact.
• Broad Blazor rendering cleanup before the startup database work has been addressed and remeasured.

Measurement notes

Track separate timings for:

• process start to MAUI app built
• database context creation
• migration check / migration application
• category seeding
• Debug sample-data seeding
• Blazor WebView first document load
• home page initialization and first render
• first interaction latency after load

Compare Debug vs Release, clean install vs existing database, and first launch after upgrade vs normal launch.

References reviewed

• .NET MAUI runtimes and compilation: https://learn.microsoft.com/en-us/dotnet/maui/deployment/runtimes-compilation?view=net-maui-10.0
• .NET MAUI profiling: https://learn.microsoft.com/en-us/dotnet/maui/fundamentals/profiling?view=net-maui-10.0
• Blazor rendering performance: https://learn.microsoft.com/en-us/aspnet/core/blazor/performance/rendering?view=aspnetcore-10.0
• EF Core efficient querying: https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying
• EF Core tracking/no-tracking: https://learn.microsoft.com/en-us/ef/core/querying/tracking
• EF Core migrations: https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying
• Microsoft.Data.Sqlite async limitations: https://learn.microsoft.com/en-us/dotnet/standard/data/sqlite/async
• .NET MAUI fonts: https://learn.microsoft.com/en-us/dotnet/maui/user-interface/fonts?view=net-maui-10.0
• Blazor Hybrid static files: https://learn.microsoft.com/en-us/aspnet/core/blazor/hybrid/static-files?view=aspnetcore-10.0

[danielchalmers]

I reviewed the Android debug launch logs after adding the lightweight startup/home logging.

Key findings from this capture:

• PrepareDatabase took 1042ms, with 911ms spent in GetPendingMigrations().Any() even though there were no pending migrations. This is the biggest production-relevant startup concern from the app-level timings.
• SeedCategories took 443ms with added: 0, existing: 14, and save changes calls: 14. We are paying for no-op category updates and saving once per category during launch.
• SeedDebugDays took 1140ms. This is DEBUG only, so it likely does not affect production, but it makes debug startup feel much worse and can obscure release behavior.
• Home initialization is much smaller by comparison: Home initialized in 113ms, with Loaded day at 111ms. I would not optimize the home page first based on this run.
• The Choreographer skipped-frame messages and the Davey! duration=1157ms line are real responsiveness symptoms, but they line up with startup work plus WebView/Blazor/debug loading.
• The many FastDev assembly warnings, libpenguin.so, Chromium DNS/Bluetooth/media warnings, and sensitive-data warning look like debug/platform/WebView noise rather than app bugs.

Suggested next implementation steps:

1. Batch or gate category seeding so unchanged default categories do almost no launch-time work.
2. Avoid checking EF pending migrations on every normal launch, or gate it behind an app/schema version change.
3. Make debug day seeding opt-in or only run when the debug database is empty.
4. Re-measure on a Release Android build after the logging PR lands.

[danielchalmers]

I rewrote the title and description to re-align this issue with what the latest evidence actually supports.

What changed:

• Narrowed the title from broad app responsiveness to the Android startup critical path.
• Replaced the original broad list of possible optimizations with the measured timings from the raw Android debug launch.
• Moved #93 into the right category: instrumentation/logging, not a true Release cold-start baseline.
• Removed the Google Fonts work as a completed optimization because #92 was closed and because we want Roboto on all platforms.
• Moved Blazor rendering, lazy-loading, calendar, trends, and lifecycle-save work into a secondary bucket until new measurements show they are material.
• Added an explicit “not pursuing right now” section for debug/platform/WebView noise and speculative font work.

Reasoning:

The raw launch logs showed the clearest startup costs in database work before the app is built: PrepareDatabase at about 1.0s, SeedCategories at about 0.44s, and DEBUG sample-data seeding at about 1.14s. Home initialization was only about 113ms in that run. That means the next performance PRs should target the measured startup database path first, then re-measure before expanding into broader rendering or asset changes.

[danielchalmers]

Next step plan: optimize category seeding first.

Reasoning:

• The latest Debug launch log measured SeedCategories at 443ms.
• It is production-relevant, unlike SeedDebugDays.
• It is low risk compared with migration gating.
• The current implementation does one category query and one SaveChanges() per default category, even when the database is unchanged.

Implementation plan:

1. Replace the repeated AddOrUpdate(...) execution pattern with an ordered in-memory list of seed definitions.
2. Open one AppDbContext.
3. Load categories once with one query, then build:
   • existingByGuid for seeded category lookup.
   • next index counters per group so new seeded categories preserve existing AddCategory ordering behavior.
4. For each seed definition:
   • If the category exists:
     • Preserve current behavior by always updating Guid, Group, and ReadOnly.
     • Do not reset Enabled.
     • Do not overwrite user-editable fields unless the category is ReadOnly.
     • For ReadOnly categories, continue restoring seeded fields and Deleted = false.
   • If the category is missing:
     • Create it with all seeded fields.
     • Set Enabled from the seed definition.
     • Assign its Index in memory using the group’s next index.
     • Add it with db.Categories.Add(category).
5. Call SaveChanges() once, and only if db.ChangeTracker.HasChanges() is true.
6. Keep the startup log useful by reporting:
   • added count
   • existing count
   • changed/pending count
   • save calls as 0 or 1
   • elapsed milliseconds

Expected result on an existing database:

• Before: SeedCategories around 443ms, save changes calls: 14.
• After: one category query, normally no save, save changes calls: 0.

Test plan:

• Fresh DB: SeedCategories() creates all default categories with unique indexes per group.
• Existing DB: running SeedCategories() twice does not duplicate categories.
• Existing non-readonly category: preserves user-editable fields and Enabled.
• Existing readonly category: restores seeded fields and clears Deleted.

I would avoid adding a seed-version/preference gate in this step. One query plus zero saves is simpler and safer; we can add a gate later only if remeasurement shows category seeding is still material.