All app assemblies are loaded on startup

[kzu]

Steps to Reproduce

Given code like the following:

// Some static dictionary somewhere:
public static Dictionary<string, Func<object>> Services { get; } = new Dictionary<string, Func<object>>();

// From MainActivity.cs;
Services.Add(nameof(BarServices.Bar), CreateBar);
Services.Add(nameof(FooServices.Foo), CreateFoo);

And given that the two methods are defined to explicitly not be inlined or otherwise loaded until invoked:

[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]
static object CreateBar() => new BarServices.Bar();

[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]
static object CreateFoo() => new FooServices.Foo();

And given FooServices.dll and BarServices.dll are two completely independent assemblies from the main app's, it would be highly desirable for the assemblies to only be loaded when the dictionary entry is accessed and the delegate is invoked, instead of happening on app start, which slows down the process "unnecessarily".

The ~same code in a .NET app properly lazy loads the assemblies as needed:

        public static Dictionary<string, Func<object>> Services { get; } = new Dictionary<string, Func<object>>(StringComparer.OrdinalIgnoreCase);

        static void Main(string[] args)
        {
            // Both this approach as well as the inline lambda properly delay-load the assemblies
            //Services.Add(nameof(BarServices.Bar), CreateBar);
            //Services.Add(nameof(FooServices.Foo), CreateFoo);

            Services.Add(nameof(BarServices.Bar), () => new BarServices.Bar());
            Services.Add(nameof(FooServices.Foo), () => new FooServices.Foo());

            var line = "";
            while ((line = Console.ReadLine()).Length > 0)
            {
                Console.WriteLine(Services[line.Trim()].Invoke().ToString());
            }
        }

        [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]
        static object CreateBar() => new BarServices.Bar();

        [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]
        static object CreateFoo() => new FooServices.Foo();

This is important for apps that use assembly-partitioning to split logic across modules, which should only be loaded whenever needed (i.e. when the UI that consumes them is navigated to, say).

Expected Behavior

Assemblies are lazy-loaded.

Actual Behavior

Both assemblies are loaded up-front:

03-19 15:36:33.243    nexus_5x    Debug    13769    Mono    Assembly FooServices[0x9de4ed60] added to domain RootDomain, ref_count=1

Version Information

Currently verified against 15.7 pre2

[kzu]

Related: https://gitter.im/mono/mono?at=5ab00b4327c509a7747ed888

[jonpryor]

Related: https://github.com/xamarin/xamarin-android/blob/8c210a0b5d4b3bd33c6bd2cfb010260c65fed1b3/src/monodroid/jni/monodroid-glue.c#L3684-L3700

From the original commit introducing the register_packages() function:

During app startup, check assemblies to see if they contain the
Java.Interop.__TypeRegistrations type. If present, invoke
__TypeRegistrations.RegisterPackages().

This allows better type mappings to be done from
Java.Interop.TypeManager.CreateInstance(): instead of always returning
a wrapper type from Mono.Android.dll, we can use a "best fit" wrapper
type from any assembly containing Java.Interop.__TypeRegistrations,
including Mono.Android.GoogleMaps.dll.

For example, previously activity.FindViewById(id) would return a
ViewGroupInvoker for a MapView. With this change, it will return a
MapView instance. See also: f0dad0a3.

This isn't ideal, as we check every assembly during startup to see if
it contains a Java.Interop.__TypeRegistrations type.

The mentioned f0dad0a3 commit has this to say:

[Mono.Android] Fix View.FindViewById<T>() for 3rd party libraries.

View.FindViewById<T>() needs to use JavaCast<T>(), just as
Activity.FindViewById<T>() does (see commit ec965bd0).

Why? So that it actually works properly with 3rd party libs:

    http://lists.ximian.com/pipermail/monodroid/2012-February/009030.html

The odd thing is that the user is reporting that null is being
returned instead of throwing an InvalidCastException, but the problem
is the same: we shouldn't be using a runtime cast, we need to use
JavaCast<T>().

[jonpryor]

Summarizing the above, here's the scenario:

1. You have a Java library which exports a com.example.MyView type which inherits android.view.View.

2. The type from (1) is bound into an Example.MyView type in Example.dll

3. The type from (1) is used in Resources\layout\Main.axml within the App, a'la

   <LinearLayout ...>
     <com.example.MyView android:id="@+id/myView" .../>

4. The App has code which calls:

   var boundView = FindViewById (Resource.Id.myView);

   Note: non-generic Activity.FindViewById() invocation.

The expectation is that Activity.FindViewById() will return the Example.MyView binding type. In order for that to happen, Xamarin.Android needs to know that the Example.MyView type exists, possibly before it is instantiated from C# code (which may never happen; all use could be via Activity.FindViewById()!).

The chosen implementation strategy was to load all assemblies during process startup, look for the Java.Interop.__TypeRegistrations type within the assembly, and -- if found -- invoke Java.Interop. __TypeRegistrations.RegisterPackages(). This allows Mono.Android.dll to know that Example.MyView exists and use it for type mappings.

[jonpryor]

I believe that the previous description is now -- and has been! -- moot, since the introduction of "type maps" in 2015-Apr-22 and subsequent fixes.

The typemap.jm and typemap.mj files should address the scenario described, without requiring any startup assembly loading.

Additionally, allow assemblies to be loaded on-demand -- instead of all at once, during process startup -- should help with our startup times.

[jonpryor]

Related: #1829

[jonpryor]

The fix for "all assemblies are loaded on startup" is to remove register_packages(), and make sure that nothing breaks. :-)

[kzu]

Awesome news @jonpryor 💯 . I think this could have quite an impact in terms of app startup!

[claudioredi]

@jonpryor Was this already released on stable channel?

[jonpryor]

@claudioredi: yes, this was released as part of Visual Studio 16.1 / Xamarin.Android 9.2. See also:

• https://docs.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-properties#androidenablepreloadassemblies
• b90d3ab
• e0da1f1

Note that $(AndroidEnablePreloadAssemblies) is True by default in "Classic" Xamarin.Android, and False by default in .NET 6.