[Zigurd]

> Those of us that care about performance use the NDK anyway.

If you had said "People porting game engines implemented in C use the NDK anyway" you might be right, and they do that because re-coding the game engine is impractical, not for performance. But the implementation of large systems in Android is best done in Java, for reasons of performance, modularity, and power efficiency.

Managed language systems exist for a reason. Dalvik bytecode is much more space efficient than native code, and Google has claimed it is about 2x as space efficient as Java bytecode, and 2x faster to interpret. Those factors reduce the need for a JIT in Android, and, until Android 2.3, Android didn't have one, and there were plenty of ambitious, performance-sensitive Android apps.

The Android component architecture enables a kind of code swapping that enables large apps to fit in a single process with a limited heap size. If you are not making use of component objects, you are not being memory efficient.

Android's Zygote and the use of copy-on-write goes beyond sharing pages of "pure" code. Any page can be shared between processes this way. This keeps global memory use down and makes it efficeint to start many more processes that would otherwise be practical with a VM language.

The Android base classes, Java toolchain, and runtime are the most sophisticated and efficient managed language environment for mobile devices. Ignoring them and going straight to NDK code without a specific performance case based on measurements of Android Java code performance, the effects of the JIT, and code size is a waste of time and a source of bugs that will be harder to find and fix.

[pjmlp]

Sorry, but your comment reads out as Google PR about Dalvik. Even with your published books I am not buying it.

The only thing you are right about is that bytecode is more space efficient than native code.

Everything else is easily done in native code as well, it is just a matter of the OS providing support for it, there is nothing special about having to be a VM.

[Zigurd]

Much of the Android OS's middleware layer is implemented in Java, and runs in a Dalvik VM instance. Many parts of the OS are implemented as Service components and accessed through remote procedure calls - the same way installable apps can provide APIs to other apps.

Contrast this with the history of the CLR in Windows mobile devices. It was not taken seriously as an application platform. None of the built-in apps used it, never mind it being the basis for system programming. Android is a Java OS in a more meaningful way than running a CLR for some subclass of apps, which certainly doesn't make Windows a "C# OS."

Try writing a non-game Android application with every Activity component as a NativeActivity subclass. It will be painful to code, more painful to debug, and it will disappoint in performance.

I'm not just shilling for Google's architectural decisions. Prior to Android being released, I was working on wireless device OS that used Linux and a Java VM for userland software. I am very familiar with the performance increment obtainable using a JIT in a mobile device, and, as an alternative, in using a precompiled Java runtime. As in Android, the heavy-duty pixel-pushing in that OS was done in a graphics stack implemented in native code. Much of Android's widget set is also in native code. Unless you choose to do heavy computation on an Android device, you are not going to get a large advantage from a JIT, especially if your bytecode interpreter actually does perform 2X better than Java.

As for heavy computation on Android devices that's what Renderscript is for.

[pjmlp]

So why do native Objective-C/iOS and native .NET/WP 8.x apps work faster and more fluid than Android ones?

[Zigurd]

Mainly due to differences in multitasking.

Android always enabled completely general multiprocessing and multithreading, initially at the expense of smooth visual effects, and Android was implemented on a variety of CPUs and GPUs. Secondarily, Android didn't used to have concurrent GC. Thirdly the animations were not tuned (q.v. Butter). Fourthly, the graphics stack was tuned to use more GPU-based operations as mobile GPUs improved. If you know you have only OS overhead when you are the foreground task, lots of things get more deterministic. But that does not mean you have more total throughput.

For that matter, Android didn't have low-latency audio until 4.2.

Try taking a look at how many processes, and Dalvik instances, are running concurrently at boot time on an Android device. Then try just starting that many VM instances, of any VM, on any other OS. The reason Microsoft has gone to pre-compiling "in the cloud" is that otherwise the CLR has a miserable startup time and mediocre performance. The CLR architecture is much more like a conventional Java VM. You can't build a whole OS on a managed language implementation of OS features with that level of performance.

I'd wager Microsoft has a much rougher road ahead stuffing a real Windows kernel into handsets and maturing CLR performance, memory efficiency, and battery life for comparable computing tasks that Android handles well in all performance dimensions.

[pjmlp]

> For that matter, Android didn't have low-latency audio until 4.2.

It still doesn't, https://groups.google.com/forum/#!topic/android-ndk/qACobHa8...

[Zigurd]

The person who posted that comment is behind the times re audio on Android.

Android can deliver very low audio latency and do it consistently, but the OEM has to test that their CPU power management and other kernel configurations have not screwed it up, and those tests are not baked into ACS.

The OEM should, at least, correctly use the feature flag for low-latency audio, leaving is off if they don't actually know. But specifying that flag in your manifest means your app loses access to devices where good enough is good enough.

Here is a low-latency polyphonic synth: https://code.google.com/p/music-synthesizer-for-android/

This synth was the test case for development of low-latency audio.