[core] use factory methods for registering services

[jonathanpeppers]

In .NET 8 Preview 7, we noticed a regression in startup around:

.NET 8 Preview 6:
45.35ms microsoft.maui!Microsoft.Maui.Hosting.MauiAppBuilder.Build()
.NET 8 Preview 7:
62.17ms microsoft.maui!Microsoft.Maui.Hosting.MauiAppBuilder.Build()

This may have been related to:

dotnet/runtime#87183

Which should be improved by:

dotnet/runtime#89964

In reviewing the traces, we noticed several places where MAUI was registering services like:

services.AddTransient<IFoo, Foo>();

Where we could instead do:

services.AddTransient<IFoo>(_ => new Foo());

Where this registration avoids any System.Reflection work at startup. Microsoft.Extensions.DI can just call the factory method instead.

I expanded upon BannedSymbols.txt like we did in e7812b0, to ban cases of AddTransient and AddScoped that might be used accidentally.

This resulted in banning the slow versions of these APIs like:

Microsoft.Maui.Hosting.ImageSourceServiceCollectionExtensions.AddService
Microsoft.Maui.Hosting.MauiHandlersCollectionExtensions.AddHandler
Microsoft.Maui.Hosting.MauiHandlersCollectionExtensions.TryAddHandler

I also introduced public, fast versions of methods in MauiHandlersCollectionExtensions.

With this change in place, I could see the difference in:

Before:
11.24ms microsoft.extensions.dependencyinjection!Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine..ctor
After:
 6.29ms microsoft.extensions.dependencyinjection!Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine..ctor

Which resulted in an overall faster startup of a dotnet new maui app on a Pixel 5:

Average(ms): 691
Std Err(ms): 3.00370142028502
Std Dev(ms): 9.49853789918334
Average(ms): 687.8
Std Err(ms): 4.04365071576553
Std Dev(ms): 12.7871463239892

This is an average of 10 runs. Note that this was built with main, and so we have an out-of-date AOT profile compared to the net8.0 branch.

[Eilon]

Looks good. At least with your updated change there should be no behavior regression at all, even if perhaps it turns out the CellRenderer is not needed a tall.

[mattleibow]

Besides the removal of the Cell registration, this is good to go! And maybe a rebase/merge from main to fix the CI builds.

[rmarinho]

What does this do?

[jonathanpeppers]

This disables the BannedApis analyzer for certain projects, added in: e7812b0

It's fine to use these in tests.

[rmarinho]

Should we add a overload that doesn't use this ? And use it ourselfs ?

[jonathanpeppers]

If we use the wrong one, it's a "banned API" and we'd get a build error. This one doesn't seem to be highly used, but I'm open.

[PureWeen]

@jonathanpeppers @mattleibow so one thing I realized about this PR is that this will disable our ability to do dependency injection with handlers. I was more hoping we were going to move to instantiating all the handlers via DependencyInjection.ActivatorUtilities.CreateInstance or service resolution vs moving to factories.

#4129

I realize users could re-register the handler but that's a bit awkward.

Will we eventually be able to move these back once the issue that regressed with runtime is fixed?

[jonathanpeppers]

this will disable our ability to do dependency injection with handlers

@PureWeen no, it shouldn't. There is an example how to do this in e7812b0:

maui/src/Core/src/Hosting/HandlerMauiAppBuilderExtensions.cs

Line 19 in 862fa07

services.TryAddSingleton<IMauiHandlersFactory>(sp => new MauiHandlersFactory(sp.GetServices<HandlerRegistration>()));

If you want to do constructor injection, you just have to pass the parameters in.

Keep in mind customers won't have to do any of this in their apps. They can register things however they like.

[jonathanpeppers]

Will we eventually be able to move these back once the issue that regressed with runtime is fixed?

We should avoid DI features that use System.Reflection -- if we want a fast startup time. They might have a source generator one day, but that is some future .NET 9 thing.

[PureWeen]

this will disable our ability to do dependency injection with handlers

@PureWeen no, it shouldn't. There is an example how to do this in e7812b0:

maui/src/Core/src/Hosting/HandlerMauiAppBuilderExtensions.cs

Line 19 in 862fa07

services.TryAddSingleton<IMauiHandlersFactory>(sp => new MauiHandlersFactory(sp.GetServices<HandlerRegistration>()));

If you want to do constructor injection, you just have to pass the parameters in.

Keep in mind customers won't have to do any of this in their apps. They can register things however they like.

yea, I was thinking from our performance analysis work in NET6 we'd mostly determined it didn't really matter. I was just hopeful we'd be able to avoid needing to be prescriptive about how to register.

If this is something users need to be aware of in general, we might also look at updating our docs https://learn.microsoft.com/en-us/dotnet/architecture/maui/dependency-injection#registration

Or eventually adding to the queue of things that would be neat for a MAUI analyzer :-)