[Android] Decouple runtime initialization and entry point execution for Android sample #111742

matouskozak · 2025-01-23T09:50:32Z

Problem Description

On Android, the startup is measured by scanning the logcat output for the following message:

Displayed <name> for user 0: <time>

In the case of dotnet/runtime sample app it would be e.g.:

Displayed net.dot.HelloAndroid/net.dot.MainActivity for user 0: +505ms

More information regarding startup measurements can be found at https://developer.android.com/topic/performance/vitals/launch-time#retrieve-TTID.

In the previous design, the onCreate method would finish before the runtime would get initialized (MonoRunner.initialize). This means that when we're reading the Displayed <name> for user 0: <time>, only the Java code had run, rendering all startup measurements useless as we couldn't measure any impact from our runtime.

Proposed Solution

By decoupling the initialization of runtime and execution of entry point, we can run the runtime initialization synchronously, forcing the onCreate callback to report the Displayed <name> for user 0: <time> after the runtime is fully initialized.

The execution of the entry point is still performed asynchronously to prevent the freeze of main thread for strenuous executables.

Note, this is solution doesn't replicate real-world scenarios, but it allows us to measure the startup time accurately with only the dotnet/runtime code.

Future Work

unify code style between the monodroid.c and monodroid-coreclr.c files
extract shared functionality ([mono] Unify mobile build integration files and sample apps for non-Mono runtimes #111923)
figure out appropriate hosting of CoreCLR (and Mono)

akoeplinger · 2025-01-23T11:08:43Z

If I remember correctly this was intentional since MonoRunner.initialize doesn't just initialize the runtime, it essentially runs the full managed program until it exits so doing that in onCreate would freeze the UI if the program takes too long.

matouskozak · 2025-01-23T11:22:49Z

If I remember correctly this was intentional since MonoRunner.initialize doesn't just initialize the runtime, it essentially runs the full managed program until it exits so doing that in onCreate would freeze the UI if the program takes too long.

Indeed, that is what I observed as well. The startup time reported would be more TTFD than TTID. We could probably split

runtime/src/tasks/AndroidAppBuilder/Templates/monodroid.c

Lines 308 to 318 in c74440f

    
           MonoDomain *domain = mono_jit_init_version ("dotnet.android", "mobile"); 
        
           assert (domain); 
        
           MonoAssembly *assembly = mono_droid_load_assembly (executable, NULL); 
        
           assert (assembly); 
        
           LOG_INFO ("Executable: %s", executable); 
        
           int res = mono_jit_exec (domain, assembly, managed_argc, managed_argv); 
        
           LOG_INFO ("Exit code: %d.", res); 
        
           mono_jit_cleanup (domain);

to a separate function call and call just this one asynchronously. (if the UI freeze is a problem for the dotnet/runtime sample app)

matouskozak · 2025-01-23T12:03:06Z

/azp run runtime-androidemulator

azure-pipelines · 2025-01-23T12:03:22Z

Azure Pipelines successfully started running 1 pipeline(s).

matouskozak · 2025-01-23T15:33:40Z

/azp run runtime-androidemulator

azure-pipelines · 2025-01-23T15:33:52Z

Azure Pipelines successfully started running 1 pipeline(s).

matouskozak · 2025-01-23T17:12:13Z

/azp run runtime-android

azure-pipelines · 2025-01-23T17:12:31Z

Azure Pipelines successfully started running 1 pipeline(s).

src/tasks/AndroidAppBuilder/Templates/monodroid.c

vitek-karas · 2025-01-24T10:11:47Z

Just curious: I understand that with this change we will now measure startup as "the time it takes for the runtime to init far enough to be able to run some code" - but it won't run "Main" yet. I'm afraid that comparing this to CoreCLR will be tricky, since the two runtimes will probably do different things in "init" versus "run main". For example, I'm pretty sure CoreCLR actually runs managed code during "init". It's possible mono delays it until "run main".

I think a much more representative measurement would be to log something from managed Main - and measure how long it takes to do that - in that case we're measuring the same behavior not relying on runtime specific implementation differences.

matouskozak · 2025-01-24T10:49:08Z

I think a much more representative measurement would be to log something from managed Main - and measure how long it takes to do that - in that case we're measuring the same behavior not relying on runtime specific implementation differences.

I would rather avoid any custom logging inside the dotnet/runtime sample. By using custom log message, we would have to frame the performance startup scripts around the custom logging. Currently the scripts work by detecting the Displayed <name> for user 0: <time> which is a default standard working with any APK file.

Just curious: I understand that with this change we will now measure startup as "the time it takes for the runtime to init far enough to be able to run some code" - but it won't run "Main" yet. I'm afraid that comparing this to CoreCLR will be tricky, since the two runtimes will probably do different things in "init" versus "run main".

I definitely agree with this part. Right now, I'm not 100% sure how to solve this other than synchronizing both runtime initialization and execution of main.

For example, I'm pretty sure CoreCLR actually runs managed code during "init". It's possible mono delays it until "run main".

After the #110471 gets merged I can run it locally for CoreCLR and see what numbers we get.

matouskozak · 2025-01-24T11:02:47Z

One posibility to explore is using TTFD for the dotnet/runtime sample instead of TTID. We could call the reportFullyDrawn() after the completion of main execution and use this time as "startup" for dotnet/runtime Android sample.

TTID: Displayed net.dot.HelloAndroid/net.dot.MainActivity for user 0: +433ms
TTFD: Fully drawn net.dot.HelloAndroid/net.dot.MainActivity: +1s397ms

ivanpovazan · 2025-01-24T11:49:27Z

Just curious: I understand that with this change we will now measure startup as "the time it takes for the runtime to init far enough to be able to run some code" - but it won't run "Main" yet. I'm afraid that comparing this to CoreCLR will be tricky, since the two runtimes will probably do different things in "init" versus "run main". For example, I'm pretty sure CoreCLR actually runs managed code during "init". It's possible mono delays it until "run main".

The comparison won't be 100% "fair" and that is fine. We use Hello* samples measurements to get the general idea about performance between runtimes, while the actual real measurement/comparison comes with dotnet new maui/ios/android samples, where full target-language interop is included. Additionally, we get Hello* measurements much sooner as we depend only on dotnet/runtime, so their "real" value is in early regression detection.

One example of another "unfair" measurement is for size for HelloiOS apps between NativeAOT and Mono where on Mono we can't strip symbols in the same way: and this gives us a comparison of: 1MB vs 5MB, which isn't really what we are getting in reality - MAUI apps :)

The only problem with TTID/TTFD and HelloAndroid is that we will have noise from system/Java in the numbers, but again with this change we will be in much better position than what we have currently.

Having said all this, I agree with the change. For more precise measurements of "when is the Main executed" we can execute measurement manually.

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c

Move mono_jit_init_version and mono_droid_load_assembly to mono_droid_runtime_init type safety around strings

matouskozak · 2025-02-03T13:43:31Z

/azp run runtime-android,runtime-androidemulator

azure-pipelines · 2025-02-03T13:43:50Z

Azure Pipelines successfully started running 2 pipeline(s).

AaronRobinsonMSFT · 2025-02-04T08:56:18Z

src/tasks/AndroidAppBuilder/Templates/MainActivity.java

@@ -41,11 +41,13 @@ protected void onCreate(Bundle savedInstanceState)
        }

        final Activity ctx = this;
+        MonoRunner.initializeRuntime(entryPointLibName, ctx);


Is this splitting these actions across two threads now? I guess it is also possible this thread is also executing the handler below post other actions. I'm not sure the Android Activity life cycle.

Based on my understanding, both initializeRuntime and the handler below will run on the same thread (cc: @jonathanpeppers). The motivation behind splitting and using the post handler is that the onCreate from MainActivity can finish and report "Displayed..." to the logcat which is captured for TTID measurement. Currently, the TTID should include all the Java parts + the initializeRuntime. The post handler below will execute with a delay (after onCreate finished) and run the executable.

I wondered if you should remove the new Handler(Looper.getMainLooper()).postDelayed(new Runnable() call completely. .NET for Android apps do not call post() to run user code on startup.

This also would make TTFD less important, and maybe you wouldn't even need to record that number. TTFD will include time Android spends doing things that we have little control over.

The reason you have for using postDelayed() is:

The execution of the entry point is still performed asynchronously to prevent the freeze of main thread for strenuous executables.

We are doing this in the product in customers' apps, so seems reasonable to do it in this sample as well.

Removing postDelayed() could be done in another PR, though.

Thanks @jonathanpeppers for the comment and insights.

Indeed, .NET Android follows a different approach to how the runtime is initialized and code ran but I wasn't sure if the effort to rewrite the dotnet/runtime sample is worth for our use case. Splitting the initialization and execution of managed code seemed like a good compromise to get some meaningful information from TTID and TTFD. However, we could definitely create a proposal for the re-work if that's wanted.

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c

AaronRobinsonMSFT · 2025-02-04T09:04:31Z

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c

+void
+Java_net_dot_MonoRunner_setEnv (JNIEnv* env, jobject thiz, jstring j_key, jstring j_value)
+{
+    LOG_INFO ("Java_net_dot_MonoRunner_setEnv:");


I would assert that coreclr hasn't been initialized yet. In fact, it might make sense to return a non-zero value if someone calls this and coreclr has been initialized. The setenv is a tricky API and rather untrustworthy from a threading perspective.

Why is it important that the runtime hasn't been initialized yet for setting env variables?

My assumption here is that this is primarily for setting environment variables for use during coreclr initialization, that could be wrong. The issue with that is there are some environment variables that aren't obvious when they are read/consumed and it can cause confusion if all DOTNET_ related variables are set a priori.

On a general note for setenv, it isn't thread safe. In coreclr we have a big lock around it for that very reason. However, we can't control other callers of that API and one can get into weird situation when reading the environment block and other threads are setting it. This could have been addressed by the Android system, but as far as I'm aware it is still a common issue with the API not being thread safe.

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c

AaronRobinsonMSFT

LGTM.

ivanpovazan

LGTM, nice work! :)

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c

ivanpovazan · 2025-02-04T09:40:10Z

src/tasks/AndroidAppBuilder/Templates/monodroid-librarymode.c

-Java_net_dot_MonoRunner_initRuntime (JNIEnv* env, jobject thiz, jstring j_files_dir, jstring j_cache_dir, jstring j_testresults_dir, jstring j_entryPointLibName, jobjectArray j_args, long current_local_time);
+Java_net_dot_MonoRunner_initRuntime (JNIEnv* env, jobject thiz, jstring j_files_dir, jstring j_cache_dir, jstring j_testresults_dir, jstring j_entryPointLibName, long current_local_time);
+
+// Signature for parity with monodroid.c (and monodroid-coreclr.c), entry point is not used


I think this comment is not correct, as we do call invoke_netlibrary_entrypoints from it.

Indeed, it was meant to hint that the signature arguments are not really used as we invoke the entry point from the library. I'll remove the comment to not introduce confusion there.

src/tasks/AndroidAppBuilder/Templates/monodroid.c

matouskozak · 2025-02-05T10:18:47Z

/azp run runtime-android,runtime-androidemulator

azure-pipelines · 2025-02-05T10:19:05Z

Azure Pipelines successfully started running 2 pipeline(s).

src/tasks/AndroidAppBuilder/Templates/monodroid-librarymode.c

Co-authored-by: Ivan Povazan <55002338+ivanpovazan@users.noreply.github.com>

matouskozak · 2025-02-05T13:01:31Z

/azp run runtime-android,runtime-androidemulator

azure-pipelines · 2025-02-05T13:01:44Z

Azure Pipelines successfully started running 2 pipeline(s).

* main: (23 commits) add important remarks to NrbfDecoder (dotnet#111286) docs: fix spelling grammar and missing words in clr-code-guide.md (dotnet#112222) Consider type declaration order in MethodImpls (dotnet#111998) Add a feature flag to not use GVM in Linq Select (dotnet#109978) [cDAC] Implement ISOSDacInterface::GetMethodDescPtrFromIp (dotnet#110755) Restructure JSImport/JSExport generators to share more code and utilize more Microsoft.Interop.SourceGeneration shared code (dotnet#107769) Add more detailed explanations to control-flow RegexOpcode values (dotnet#112170) Add repo-specific condition to labeling workflows (dotnet#112169) Fix bad assembly when a nested exported type is marked via link.xml (dotnet#107945) Make `CalculateAssemblyAction` virtual. (dotnet#112154) JIT: Enable reusing profile-aware DFS trees between phases (dotnet#112198) Add support for LDAPTLS_CACERTDIR \ TrustedCertificateDirectory (dotnet#111877) JIT: Support custom `ClassLayout` instances with GC pointers in them (dotnet#112064) Factor positive lookaheads better into find optimizations (dotnet#112107) Add ImmutableCollectionsMarshal.AsMemory (dotnet#112177) [mono] ILStrip write directly to the output filestream (dotnet#112142) Allow the NativeAOT runtime pack to be specified as the ILC runtime package (dotnet#111876) JIT: some reworking for conditional escape analysis (dotnet#112194) Replace HELPER_METHOD_FRAME with DynamicHelperFrame in patchpoints (dotnet#112025) [Android] Decouple runtime initialization and entry point execution for Android sample (dotnet#111742) ...

matouskozak added os-android area-Infrastructure-mono labels Jan 23, 2025

matouskozak self-assigned this Jan 23, 2025

This was referenced Jan 23, 2025

MSBuild crashing in the build #92290

Open

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

matouskozak force-pushed the synchronize-runtime-init-android branch 2 times, most recently from 83ea6f5 to f77a717 Compare January 23, 2025 15:24

matouskozak changed the title ~~[Android][wip] Synchronize onCreate and runtime init for Android~~ [Android] Decuple Android runtime initialization and entry point execution Jan 23, 2025

split init runtime and execution of entry point

c4e4b64

matouskozak force-pushed the synchronize-runtime-init-android branch from f77a717 to c4e4b64 Compare January 23, 2025 15:32

matouskozak changed the title ~~[Android] Decuple Android runtime initialization and entry point execution~~ [Android] Decuple runtime initialization and entry point execution for Android sample Jan 23, 2025

build-analysis bot mentioned this pull request Jan 23, 2025

ProcessTests.LongProcessNamesAreSupported test failure #111460

Closed

matouskozak added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Jan 24, 2025

matouskozak requested review from steveisok, akoeplinger and ivanpovazan January 24, 2025 09:24

matouskozak marked this pull request as ready for review January 24, 2025 09:24

akoeplinger reviewed Jan 24, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid.c Outdated Show resolved Hide resolved

src/tasks/AndroidAppBuilder/Templates/monodroid.c Outdated Show resolved Hide resolved

src/tasks/AndroidAppBuilder/Templates/monodroid.c Show resolved Hide resolved

AaronRobinsonMSFT reviewed Jan 31, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Outdated Show resolved Hide resolved

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Outdated Show resolved Hide resolved

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Outdated Show resolved Hide resolved

apply review feedback

d2f611e

Move mono_jit_init_version and mono_droid_load_assembly to mono_droid_runtime_init type safety around strings

matouskozak requested a review from vitek-karas as a code owner January 31, 2025 15:58

matouskozak force-pushed the synchronize-runtime-init-android branch from 9501676 to d2f611e Compare January 31, 2025 15:59

move resource cleanup to onDestroy

cb399e4

This was referenced Feb 3, 2025

[wasm][AOT] emcc : error - received SIGKILL (-9) #89402

Open

[wasm] Out of memory exception in System.Xml.XmlWriterApiTests.TCFullEndElement tests #110090

Open

AaronRobinsonMSFT reviewed Feb 4, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Outdated Show resolved Hide resolved

AaronRobinsonMSFT reviewed Feb 4, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Outdated Show resolved Hide resolved

AaronRobinsonMSFT reviewed Feb 4, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Show resolved Hide resolved

AaronRobinsonMSFT reviewed Feb 4, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c Outdated Show resolved Hide resolved

AaronRobinsonMSFT approved these changes Feb 4, 2025

View reviewed changes

ivanpovazan reviewed Feb 4, 2025

View reviewed changes

ivanpovazan approved these changes Feb 4, 2025

View reviewed changes

ivanpovazan mentioned this pull request Jan 29, 2025

[mono] Unify mobile build integration files and sample apps for non-Mono runtimes #111923

Open

3 tasks

address review feedback by Aaron and Ivan

f857e5b

akoeplinger approved these changes Feb 4, 2025

View reviewed changes

matouskozak requested a review from elinor-fung February 5, 2025 10:19

ivanpovazan reviewed Feb 5, 2025

View reviewed changes

src/tasks/AndroidAppBuilder/Templates/monodroid-librarymode.c Outdated Show resolved Hide resolved

Update src/tasks/AndroidAppBuilder/Templates/monodroid-librarymode.c

52f8e40

Co-authored-by: Ivan Povazan <55002338+ivanpovazan@users.noreply.github.com>

matouskozak merged commit c9af66c into dotnet:main Feb 5, 2025
149 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Android] Decouple runtime initialization and entry point execution for Android sample #111742

[Android] Decouple runtime initialization and entry point execution for Android sample #111742

matouskozak commented Jan 23, 2025 •

edited

Loading

akoeplinger commented Jan 23, 2025 •

edited

Loading

matouskozak commented Jan 23, 2025 •

edited

Loading

matouskozak commented Jan 23, 2025

azure-pipelines bot commented Jan 23, 2025

matouskozak commented Jan 23, 2025

azure-pipelines bot commented Jan 23, 2025

matouskozak commented Jan 23, 2025

azure-pipelines bot commented Jan 23, 2025

vitek-karas commented Jan 24, 2025

matouskozak commented Jan 24, 2025 •

edited

Loading

matouskozak commented Jan 24, 2025

ivanpovazan commented Jan 24, 2025 •

edited

Loading

matouskozak commented Feb 3, 2025

azure-pipelines bot commented Feb 3, 2025

AaronRobinsonMSFT Feb 4, 2025

matouskozak Feb 4, 2025

jonathanpeppers Feb 4, 2025

matouskozak Feb 4, 2025

AaronRobinsonMSFT Feb 4, 2025

matouskozak Feb 4, 2025

AaronRobinsonMSFT Feb 4, 2025

AaronRobinsonMSFT left a comment

ivanpovazan left a comment

ivanpovazan Feb 4, 2025

matouskozak Feb 4, 2025

matouskozak commented Feb 5, 2025

azure-pipelines bot commented Feb 5, 2025

matouskozak commented Feb 5, 2025

azure-pipelines bot commented Feb 5, 2025

[Android] Decouple runtime initialization and entry point execution for Android sample #111742

[Android] Decouple runtime initialization and entry point execution for Android sample #111742

Conversation

matouskozak commented Jan 23, 2025 • edited Loading

Problem Description

Proposed Solution

Future Work

akoeplinger commented Jan 23, 2025 • edited Loading

matouskozak commented Jan 23, 2025 • edited Loading

matouskozak commented Jan 23, 2025

azure-pipelines bot commented Jan 23, 2025

matouskozak commented Jan 23, 2025

azure-pipelines bot commented Jan 23, 2025

matouskozak commented Jan 23, 2025

azure-pipelines bot commented Jan 23, 2025

vitek-karas commented Jan 24, 2025

matouskozak commented Jan 24, 2025 • edited Loading

matouskozak commented Jan 24, 2025

ivanpovazan commented Jan 24, 2025 • edited Loading

matouskozak commented Feb 3, 2025

azure-pipelines bot commented Feb 3, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AaronRobinsonMSFT left a comment

Choose a reason for hiding this comment

ivanpovazan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matouskozak commented Feb 5, 2025

azure-pipelines bot commented Feb 5, 2025

matouskozak commented Feb 5, 2025

azure-pipelines bot commented Feb 5, 2025

matouskozak commented Jan 23, 2025 •

edited

Loading

akoeplinger commented Jan 23, 2025 •

edited

Loading

matouskozak commented Jan 23, 2025 •

edited

Loading

matouskozak commented Jan 24, 2025 •

edited

Loading

ivanpovazan commented Jan 24, 2025 •

edited

Loading