My current project involves an Android app with some existing native code. As far as I know, I can either use the code as a separate binary which will be run in a separate process or through JNI which allows simpler communication.
Is it true that JNI should usually be preferred over the over approach? The native code (which was written to be compiled into a UNIX binary) really relies on continous performance. It should not be affected by other code (e.g. Android views, activities, processes, threads...) at all, at least in theory. Practically, our goal is to keep it as performant as possible. Will JNI cause performance problems, especially in the terms of communication overhead and VM threading?
A separated binary would have the benefits
- that it is simple to maintain
- that the existing native code base does not have to be changed (except from compatibility changes, of course)
- that the process running the separated binary might be less vulnerable to performance impacts than the single-process JNI solution.
Related
For example, I want to create a simple application based on GPS, with making waypoints, showing them on map, etc.. So, is it possible to make such an app using C++ only, without any Java sources? Would it be more difficult than making the same on Java?
So, is it possible to make such an app using C++ only, without any
Java sources?
No. If you want to receive GPS coordinates, there is no way to do this without any Java code.
You could write an app in which Java is used as a thin wrapper around native code, using JNI to exchange data between Java and C++. However...
Would it be more difficult than making the same on Java?
Yes! In addition, the app would likely end up being:
Slower.
Buggier.
Harder to understand and maintain.
For Android development, Java is just the natural, normal, default language, and C++ is for exotic special tasks, typically those which involve really intensive calculations. You use it when you need it, not because you don't "want to" write in Java or because "Java is slow".
Writing correct JNI code is also not exactly trivial. For example, it's very easy to get local references and global references wrong if you don't read the documentation, as the compiler cannot detect their incorrect usage.
As the official documentation of the Android Native Development Kit says:
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++.
It also says:
You cannot access features such as Services and Content Providers
natively, so if you want to use them or any other framework API, you
can still write JNI code to do so.
Yes, search for Android NDK. Apparently it's a bit of a hassle, you'll be using SO a lot!
I've been looking into writing a small cross-platform OpenGL/helper code that can compile on Android and the iPhone. I was looking up the best way to handle multiple threads within the NDK on Android and couldn't find a definitive answer. I read that fork() should not be used because Android doesn't keep tabs on those processes.
I'm not worried about making the forking cross-platform as it can be easily defined separately. So, I was wondering if anyone knew the best way to handle creation and management of multiple threads within the NDK.
According to NDK/JNI: identifying current thread , Java threads on Android correspond to pthreads. So consider using those. The relevant C headers do come with NDK.
Not sure how will calling Java back from those threads work. I won't automatically assume that the JNI pointer is thread-safe.
Not really an immediate source code question per se....but Im looking into doing some casual Android Programming, nothing heavy.
But it seems to use alot of XML and Java......what I wonder though is why is it that android is written mostly in C and XML (along with C++ and Java) with it being closely related to the Linux OS......but why is the "main" language for programming in android Java?
Just out of curiosity of course.
The "main" language, as you called it, is Java. You can use C/C++ via the NDK, but you won't need it unless you are doing some special stuff. If you wonder when you would need to use C/C++, take a look at the official documentation:
When to Develop in Native Code
The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but always increases application complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
The Android framework provides two ways to use native code:
Write your application using the Android framework and use JNI to access the APIs provided by the Android NDK. This technique allows you to take advantage of the convenience of the Android framework, but still allows you to write native code when necessary. You can install applications that use native code through the JNI on devices that run Android 1.5 or later.
Write a native activity, which allows you to implement the lifecycle callbacks in native code. The Android SDK provides the NativeActivity class, which is a convenience class that notifies your native code of any activity lifecycle callbacks (onCreate(), onPause(), onResume(), etc). You can implement the callbacks in your native code to handle these events when they occur. Applications that use native activities must be run on Android 2.3 (API Level 9) or
You cannot access features such as Services and Content Providers natively, so if you want to use them or any other framework API, you can still write JNI code to do so.
I am just guessing but Java is a bit easier to program than C/C++ so its more attractive to new programmer which is also good for the platform success itself.
Another reason might be that an application written in java runs in a separate VM so it can be much easier controlled by android. If a vm is not responding the main OS can just kill it and the phone is still responding.
Suaron... From a stability point of view Java apps should be less likely to take down the device. So Java || C# || C++/CLI safer than C++ vs C vs Assembly. To this end the API is in Java and so most Apps are in Java.
On the other hand C/C++ gets closer to the hardware and is more appropriate for writing libraries that interact with hardware. It is much easier to shoot yourself in the foot with C++.
JAL
The Android NDK has just been significantly expanded to include support for writing android applications entirely in native C/C++ code. One can now capture input events on the keyboard and touch screen using native code, and also implement the application lifecycle in C/C++ using the new NativeActivity class.
Given all the expanded native capabilities, would it be worthwhile to completely bypass Java and write Android application in native code?
The NDK is not native per-se. It is to a large extent a JNI wrapper around the Android SDK. Using NativeActivity gives you a convenient way of dealing with certain app-life cycle events, and add your own native code on top. ALooper, AInputQueue etc. are all JNI wrappers of the Java SDK counterparts, some with additional code that is private and unaccessible for real apps.
When it comes to Android development, there's no such thing as writing an application entirely in native C++ - you will (in every real App case that I can think of) always need to use the Android API:s, which are to a huge extent pure Java. Wether you use these through wrappers provided by the NDK or wrappers that you create yourself doesn't really change this.
So, to answer your question: No, it wouldn't be worthwhile, because you would end up writing JNI wrappers for SDK calls instead of writing JNI wrappers to your own Java methods that do the same thing, with less code, simpler code and faster code. For example, showing a dialog using "pure c++", involves quite many JNI calls. Just calling a Java method through JNI that does the same thing will give you faster code (one JNI call), and, arguably, code that is easier to maintain.
To fully understand what you can do, you really must examine the Android source code. Start with native_app_glue.c, which is available in the NDK, then continue with the OS implementation of AActivity, ALooper, AInputQueue etc. Google Code Search is a great help in this. :-)
If it is easy to do in Java, and includes many calls, call a method through JNI that does it all, rather than writing all the extra code to do it with multiple JNI calls. Preserve as much of your existing C++ code as is reasonable.
Not if you are just making a standard application. The Java SDK is more complete than its Native counterpart right now so you would still be making things more difficult for yourself.
If you are not doing something that requires the NDK (read: real time performance sensitive) then stick with Java.
Just some food for thought but if you have an app on iOS and Android, some C/C++ code might be shareable. Obviously the iOS Obj-C and platform specific code wouldn't work elsewhere. (Ditto for the Android specific stuff). But you might be able have some shared code that's platform neutral.
If you can, stick with the java style apps until versions of Android supporting native activities constitute a significant fraction of the installed base.
For things that were hard to do before - particularly ports of existing code - this will probably be a big help.
It's not entirely clear yet what has changed vs. just writing your own thin java wrapper. For example, is there still a copy of the dalvik VM hanging around?
I have the following questions, please if you know the answers share it with me.
How can I transform my working Java code to NDK? (it's an algoritm not activity)
I am able to access the database from NDK?
Will a backtracking algorithm with 10 millions of iterations run faster if was written with NDK?
Android NDK allows you to use native (c/c++) code in your Android application. So, you would need to convert your code to c or c++.
The Android database is typically SQLite, so you would need a c/c++ interface for interacting with it. The docs don't talk about giving you that..
From the docs:
Typical good candidates for the NDK
are self-contained, CPU-intensive
operations that don't allocate much
memory, such as signal processing,
physics simulation, and so on. Simply
re-coding a method to run in C usually
does not result in a large performance
increase. The NDK can, however, can be
an effective way to reuse a large
corpus of existing C/C++ code.
If your algorithm is cpu intensive, doesn't allocate much memory, and could be optimized in c/c++ it might be worth a shot..