More concretely, I’m asking this: why aren’t applications compiled fully to native code before distribution rather than bytecode that runs on some virtual machine or runtime environment?
Implementation details aside, fundamentally, an Android application consists of bytecode, static resources, etc. In the Java world, I understand that the main appeal of having the JVM is to allow for enhanced portability and maybe also improved security. I know Android uses ART, but it remains that the applications are composed of processor-independent bytecode that leads to all this complex design to convert it into runnable code in some efficient manner. See: ART optimizing profiles, JIT compilation, JIT/AOT Hybrid Compilation… that’s a lot of work to support this complex design.
Android only officially supports arm64 currently, so why the extra complexity? Is this a vestigial remnant of the past? If so, with the move up in minimum supported versions, I should think Android should be transitioning to a binary distribution model at a natural point where compatibility is breaking. What benefit is being realized from all this runtime complexity?
First of all, since the very early days Android has always allowed apps to make use of native code using the “NDK”, and in fact most games and most apps that do any sort of AI, image processing, or anything else complex like that make heavy use of native code already, for performance reasons.
Keep in mind that the decision to base Android apps around Java was made back in 2003 when Android was founded. Some of the reasons they picked Java were:
Now 20 years later I think it’s worked out pretty well. It’s hard to imagine picking a different language would have worked out better. Java is still just as popular as ever, and Android developers can take advantage of all of the Java tools from any other platform or application.
Apple’s original option for iOS apps was just Objective-C, which is higher-performance, but overall it’s a more obscure, difficult to use language. Developers adopted it despite Obj-C, not because of it. Apple had to invent Swift to provide a more modern alternative, because Obj-C is basically not used anywhere else and it felt very ancient. While Swift is a pretty great language, it’s still somewhat obscure, only used for iOS and Mac apps - while Java and JVM languages are used everywhere.
Anyway, let’s say that Android really did want to switch, for some reason. I’m not sure why you think switching to compiled code would be less complex. How would all of the millions of existing Android apps migrate? What native languages would be supported? It’d be a huge transition for dubious benefits.
As it is, Android is extremely flexible. While the official APIs require a JVM language, because of the NDK you can basically write Android apps in whatever language you want. People have built frameworks enabling you to build Android apps in nearly every language under the sun.
Thank you for this great and detailed answer!
I would also add that today JVM environments support more languages such as Scala, Kotlin, and Clojure (to name a few). So more variety and more modern paradigms are available.
As for native languages, we are more or less left with C, C++, Go and Rust. Also some of them are really awesome, none seem like a good choice for general-purpose app development.
And a counter-intuitive thing is that modern run times are so well optimized that sometimes they can outperform native applications (I’m not talking about very tight calculations such image processing and AI), because JIT has much more information about both the specific hardware and run time introspection that is unavailable at compile time.
Yeah but at the same time if you support c++ for example its still extremely relevant language(i like c better tho…) and you could build support onto that stable base instead of using the $hitstorm called java. Well thats my opinion anyways. Maybe ease of use is more important and making phones that are powerfull enough to be used as a laptop is the right path forward. But making android more efficient would take a lot of other things and im not nearly qualified enough for this discussion.