4 ms·

All those apps uses the native GUI of the platform, which means they have to use the SDK. Why FB would even consider using the NDK is beyond me, as the FB app i

• dschiptsov 13y ago
  OK, I will try to explain. The problem with Java is that it doesn't actually fits for mobile development (or any sane development at all) being just a buzzword, a bubble inflated by corporate money. Consider the very basics of system architecture. There is something called ABI, which defines how syscalls are used and implemented. Android uses its own ABI which is a flavor of Linux ABI for ARM architecture (actually it supports different ARM chips and even x86, but it doesn't matter). According to these ABIs we perform syscall as it is in a Linux system. So, when we do Math we actually call procedures from libm.so, when we do crypto we call libssl.so (from OpenSSL) etc. It also has its own variant of libc.so and implementation of OpenGL ES, as one could guess, libGL.so. How does Java fits here? Well, according to original concept, it ought to be an isolated VM on top of any OS, which supposed to be run everywhere, and everything must be written (once) in pure Java. Because of that brilliant idea to simply ignore what an OS provides, they have re-implemented everything its own, proper way - famous Strings, Calendar, UTF-32, you name it. So-called reality, however, imposed some necessary corrections, and the kluge called JNI was added. It allows to break the purity and, using ugly and very inefficient mechanisms, dlload and call OS and third-party libraries. What we have in Android is, basically, a bunch of JNI calls to Android Runtime (libart.so, if I got it correctly) which is, not surprisingly, have nothing to do with Java. I am not an expert to tell how the bytecode translator (dx) works, but it doesn't really matter. Why do Android has Java at all? The answer is quite simple - because it is such a huge buzzword, such a great scam. It was the way to gain attention of ignorant masses^W^Wmillions of coders. "Wait, Java? Sounds familiar!" (The very same idea to play the Javascript card with WebOS have died, thank god.) So, the developers of complex (read: real-world) apps such as FB have realized that this unnecessary Java layer can't be used for anything but hello-words or http-get-post apps, and that it is much easier to avoid Java at all (what's the point to have the overhead of all that JNI calls), because, one could see, it is just an unnecessary, artificial layer which doesn't fit anywhere (except manager's presentations). I probably missed some details, but I am not an Android expert.
  • Skinney 13y ago
    This again, is wrong. Android was made to run managed code from the beginning, it's designed around that very fact. Let me try to enlighten you. In Android, every process spins up its own Dalvik VM. Yes, Dalvik VM, not Java VM, as Android doesn't run Java. The android development tools does contain a Java Bytecode to Dalvic Bytecode converter (dex), which is why JVM based languages run on Android, as long as you don't generate Java bytecode on the fly (which several dynamic languages do). Anyway, each process spins up it's own Dalvik VM, which get's to run your Application. There really isn't any exception to this, which means that even if you create a program using the NDK, you will still need to do some Java to set up an activity that in turn runs the native code. Because calling native code through a foreign function interface (FFI, known as JNI on the JVM) creates some overhead, Android does as little of this as possible. This is why most the UI API is implemended directly in Java/Dalvik-Bytecode, and only the low-level drawing API is in native code (or implemented directly in the VM, not certain). If you program an app using only the NDK, you therefore won't have access to the native UI API, meaning you will have to write glue-code to call the Java API, or use your own GUI API (like Qt). > Because of that brilliant idea to simply ignore what an OS provides, they have re-implemented everything its own, proper way - famous Strings, Calendar, UTF-32, you name it. Right... So normally, out of the box, you will have access to wchar, socket, time.h and math.h. You don't really re-implement this in the JVM, you write bindings to the low-level functions, and then write abstractions (UTF-16, Strings, DateTime ...) on top of that. The actual bindings are usually generated using Swing or something like that. > So, the developers of complex (read: real-world) apps such as FB have realized that this unnecessary Java layer can't be used for anything ... Hopefully, I've been able to explain why cutting out the Dalvik/Java layer brings more pain than it's worth. Most applications on Android are running on the Dalvik/Java VM. The exceptions are VMs (Like Xamarin.Android) and OpenGL applications, like games, which require more fine grained controll of memory allocations to avoid garbage collections in the middle of a render-loop. Just in case you are not convinced, here is Google's own warning on the use of the NDK for app development. "Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++." P.S: Facebook did use HTML/JS for their app for a while, but switched to the native SDK because the HTML-based app was to slow. The native SDK (Java) seems to suit them just fine. P.P.S: Check out this link to see why using the NDK is a pain in the . https://mflerackers.wordpress.com/2013/08/25/using-the-ndk-and-jni-to-build-android-applications/ https://mflerackers.wordpress.com/2013/08/25/using-the-ndk-a...