this post was submitted on 02 Jul 2023
83 points (96.6% liked)

Android

27883 readers
26 users here now

DROID DOES

Welcome to the droidymcdroidface-iest, Lemmyest (Lemmiest), test, bestest, phoniest, pluckiest, snarkiest, and spiciest Android community on Lemmy (Do not respond)! Here you can participate in amazing discussions and events relating to all things Android.

The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:

Rules


1. All posts must be relevant to Android devices/operating system.


2. Posts cannot be illegal or NSFW material.


3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.


4. Non-whitelisted bots will be banned.


5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.


6. Memes are not allowed to be posts, but are allowed in the comments.


7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.


8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.


Community Resources:


We are Android girls*,

In our Lemmy.world.

The back is plastic,

It's fantastic.

*Well, not just girls: people of all gender identities are welcomed here.


Our Partner Communities:

[email protected]


founded 1 year ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 10 points 1 year ago (1 children)

I think there are a couple of things to consider. Number one is that Android at the very beginning never was designed for large touchscreen phones, rather it was supposed to be a small portable Software Stack that would run on digital cameras where Java would be good enough.

Another historic thing that must have played into this is that Android was fighting an uphill battle. At the time iOS, PalmOS, BlackberryOS, Symbian and Windows Mobile all were shipping units. So I think they knew they had to keep the barrier of entry for creating Apps as low as possible and Java was (and still is) an incredible easy to understand language with a very gentle learning curve. Plus it was one of the most widley used language with robust tooling.

Also for implementation - Android actually was AOT compiling Apps during installation during the Android 5 and 6 days however starting with 7 they went away from that by using a hybrid approach. Basically if you download an App and launch it the first time, it would run in JIT mode and collect data and than compile and optimize cirtical parts while the phone is idle and charging. There even is an adb command (adb shell cmd package compile -m speed -f my-package) to manually compile apps. But I have played around with this a lot, trust me, and I can't notice a difference.

Also more generally I think that Android Apps being mostly made up of intermediate bytecode instead of raw CPU instructions is overall a massive benefit for security and incredible futureproofing. It allows for things like x64 Chromebooks and Asus Zenfones with Intel Atom SoCs (yes that was a thing) and would make a transition to a new ISA like RiscV somewhat managable I think. Also I don't think Java and its performance overhead matters - usually its badly coded Apps or these god awful wrapped webview "apps" that cause issues. Simple as that. If you today compare a Nexus 5 and an iPhone 5S, the Nexus 5 is faster 8/10 times, and that despite having a slower CPU and the whole java stack.

[โ€“] [email protected] 2 points 1 year ago

The hybrid compilation approach is spectacular. Really smart design. It's as close as having the cake and eating it as possible.