Architecture: 2 threads vs 1 thread and Java → Rust on each event?

[rnikander]

I wonder if the implementors here looked into this at some point and have an answer. It seems the usual "native" (non JVM) app in android uses a separate thread for a native main/event loop. That's what this crate supports. But it also seems like you could build something where the main Activity class is in Java/Kotlin, and it has a bunch of glue methods that forward to Rust via JNI, without creating a second thread. (Some talk about this in an ndk discussion thread)

It would have more Java glue but they would be conceptually trivial forwarding methods for the most part. Did you all look into this at some point and decide against it for some reason, or did you go straight for the 2-thread style?

[rib]

Hi, TL;DR, as a maintainer here, yeah I'm familiar with both architectures but I probably wouldn't end up saying that one is categorically better than the other other - they both have their place with different trade offs.

As a random example, the official native programming model for Meta Quest is based around NativeActivity, so sometimes the choice is made for you.

In the context of android-activity there wasn't really any consideration of the pros/cons of the different architectures when making this crate in the sense that this crate started out with a pretty-specific, narrow scope which was to have Rust bindings for NativeActivity and GameActivity which already dictate the threading model. For my needs at the time I knew I was happy to work with a threaded model.

Originally this crate was essentially written as a shim over android_native_app_glue.c and it was intentionally adhering to the architecture that NativeActivity was designed for where you have a dedicated native thread that has a small IPC interface for interacting with the Activity running in the Java main thread. Later the android_native_app_glue.c code was ported to 100% Rust but it still adheres to the same architecture.

For anyone that's entirely allergic to touching Java/Kotlin then NativeActivity is essentially the only way in which you can attempt to write a fully native Android application where you don't need to deal with writing any Java/Kotlin code, because it's shipped as part of the Android SDK, but there are real practical limits to what you can build if you try and constrain yourself to a purely native development model.

The other benefit from the native thread architecture is that you can approximate a more traditional native programming model with a main() function where you can e.g run a traditional game loop that might be designed to run across multiple platforms without needing to think too hard about how the main java thread is callback based and can't be used to run long-running blocking code.

For example I was working at Embark Studios for a while on a cross-platform game engine written in Rust and it made sense in that case to be able to run an event loop in a native main thread, with minimal architectural differences compared to other platforms.

But there are also significant limitations with the NativeActivity threaded model because at the end of the day Android's official application programming model is fundamentally based around a JVM and there's no way to escape the fact that all Android applications run on a JVM with most application APIs only exposed to Java/Kotlin, not directly to native code.

Even very basic things like using Intents and requesting permissions can't be done without writing some Java code so I personally don't find it super compelling to try and pretend that it's ever possible to build Android applications without needing to write at least some support code in Java/Kotlin.

A disadvantage (imo) with the threaded architecture is that it adds a layer of indirection between your native code and the Java main thread which receives a lot of important event callbacks that applications care about. The Java APIs also aren't all thread safe and may only be usable from the main java thread.

android-activity has a small IPC abstraction for a small number of interactions with the Java main thread, for tracking Activity lifecycle events and creating new "window" surfaces which can be enough for many applications like fullscreen games but it doesn't cover everything and sometimes you'll need to create your own Activity subclass and find your own solution for bridging extra events between the java main thread and your native thread.

Even though I'm the maintainer for this crate I do think that the non-threaded, native library architecture makes a lot of sense in many cases. Especially for applications that want to build UIs using Android's standard toolkit then if you want to write a lot of business logic in Rust it would make more sense in that case to have a Rust library that you invoke via JNI.

The two models aren't even entirely mutually exclusive. Assuming that you end up writing some kind of Activity subclass for your Android application (which you almost certainly need to do for anything more than a demo) then native methods can be used to jump into Rust from the Activity running in the Java main thread and this can be quite-easily bridged to an android_main thread e.g. via channels.

As it is, android-activity currently only deals with the 2-threaded model, and I don't know whether it would be that practical to also support the single-threaded model considering that the event handling differences are pretty fundamental.

There might be opportunities for android-activity to streamline more hybrid models, but while android-activity doesn't currently impose any specific Java support library or a specific RustActivity then there's a limit to what android-activity can currently do to interact with Java - constrained by the base features of NativeActivity or GameActivity.

I think in the end I'd expect to combine elements of both.

Even if you're running your app in a android_main thread that doesn't mean you need to create an elaborate RPC bridge for all kinds of Android SDK features, and those things probably make more sense to handle via JNI, operating from the appropriate java thread, with some more narrow, application-specific bridge for moving data between threads.

I would also keep in mind that JNI can be quite a pain and so there are also trade offs with how to keep that managable if you lean into creating lots of Rust library code that's trying to drive a lot of Java interaction. Sometimes it's also simpler to accept writing some amount of Java / Kotlin code so you can distil a smaller surface area to access via JNI.

While you're investigating what you want for your app, you might want to investigate this android-view project to see what it might look like to go with more of a single-threaded architecture: https://github.com/rust-mobile/android-view

It's probably fair to say that NativeActivity and GameActivity are generally geared towards applications with a single fullscreen surface, such as games, or UIs rendered with native toolkits. So a key factor in your choice might come from looking at how you want to render your UI. Remember you can't block the Java main/UI thread so you can try to consider how you plan to render and handle input.

If you want to render with opengles or vulkan / wgpu then you almost certainly don't want to try and render from the UI thread, and so then it could be reasonable to go for a threaded model for rendering at least.

[rnikander]

Thank you for the thorough response. To your last point, I'm using wgpu to draw my UI, but I haven't figured out yet exactly when and how that happens on Android, or much time it takes to encode the GPU commands. On iOS I can often render on the main thread, but it sounds like Android may be different. (Maybe I shouldn't be doing that on iOS either; I haven't timed it much yet.) Anyway, time to write code and experiment...

[rib]

Apart from the technical curiosity to see if you could get away with it, I really wouldn't consider trying to render with wgpui from the UI thread and would treat rendering like I/O. Even non-native Android apps have a dedicated rendering thread. If you did attempt to submit to the gpu from the UI thread you also need to consider how to synchronise your buffer swaps/presentation without blocking the thread or e.g. dealing with sync objects / fences. If you want to use wgpu from Rust I believe some apis require an async runtime and you probably wont be able to use those from the UI thread without blocking. Technically there's a slim chance you could make it work but it would almost certainly be an unwise design.