6 ms·

Interesting - but to quote from the Android developer website: Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allo

by bdfh42 13y ago

Interesting - but to quote from the Android developer website: 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. 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.

shadowmint 13y ago
They also say: 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++. Which continues to annoy me even now. I recall the fireside android team chat one time (two years ago?) that went something like: Question: So what about the NDK? You can't beat native for performance... Android team member: *laughs* ... well, you can't beat java for portability Comment from audience: Unless you want to use your code on another platform... <awkward silence, discussion moves on to next question> That's certainly how I feel about it.
- mtdewcmu 13y ago
  Good point. For better or worse, iOS is native code, and you could potentially write C or C++ that targets both.
- pjmlp 13y ago
  Yeah, right. However, - Google has managed to fragment the Java world - Pushes Renderscript instead of OpenCL - Forces everyone to go via JNI to access Android APIs in C and C++ land They are no better than the other players. I am actually curious to find out what are their plans in regard to ART. Only replace Dalvik, or go further in terms of what will be the set of supported languages.
djh_ 13y ago
Don't forget games, the vast majority of popular games are likely running native code. I don't have any stats on that, but you can check out the following games made using the open-source C++ framework Cocos2d-x that the developers asked to be featured: http://www.cocos2d-x.org/games/all?p=8&page=1 http://www.cocos2d-x.org/games/all?p=8&page=1
- Pxtl 13y ago
  Yeah, nobody wants to have a GC pause just as they're about to do something tricky.
  - pjmlp 13y ago
    So maybe AAA studios shouldn't be using Unity. Oh wait...
    - corresation 13y ago
      The overwhelming bulk of a Unity game on Android runs in purely native code (the Unity shared library). Of course the game orchestration and such runs in a managed runtime (mono), but the garbage created by simple orchestration/management running in a GC is minuscule compared to the garbage created by an entire game engine running in a GC.
      - pjmlp 13y ago
        Ah you mean like the Witcher 2 for the XBox 360 where the C++ engine uses a GC?
Zigurd 13y ago
It is possible to make a substantially "NDK-only" app. Mainly for porting games.
melling 13y ago
What is like working with the NDK? C++ is the one language that can work on both iOS and Android (and Windows phone?) Personally, I'd like to get some reuse out of my iOS code. I'd do more C++ if I knew that I could reuse it. Of course, Objective C could actually be portable too.
- djh_ 13y ago
  Having worked with the NDK in Android Developer Tools (Google's Eclipse Fork), it's pretty painful. It takes a long time to get the environment set up and working (somewhat) nicely. You have to get a plugin to debug via ADT, I used the ARM DS-5 debugger. It works, but it's not a good user experience. I used to complain about certain niggles in Xcode, but having used ADT, I shall never complain again. Comparatively, using Xcode is a joy.
  - mox1 13y ago
    I used the Android NDK extensively for an app I wrote recently. The main reasons were for cross compatibility (future iOS port) and because a 3rd party library I needed was written in C. If your new to the world of C/C++..then maybe its painful, but for me it was easy to get up and running. They use the GCC toolchain behind the scenes, with gdb as the debugger. The NDK exists as a download for windows,OSX and Linux. I developed exclusively on OSX (10.8) (Using the android develop toolkit (aka ADT) which is basically a re-skinned Eclipse) and then enabled "ADB over IP" on my Nexus 4. After a bit of setup (like adb connect 'local ip' ) the Android version of gdb (ndk-gdb) on the mac just "sees" your phone, finds the process and automatically connects. If / when a crash would happen (and it happend a lot :) ) you get a stack trace, code line numbers, etc. It might not be as simple as the GUI Xcode world, but it certainly works. I've also got remote core dumps for my app, using Google's Breakpad. When the app crashes natively it uploads a core dump to my server, where I can examine what happened. Here as well you get full stack dumps, line #'s, etc.
    - jevinskie 13y ago
      As far as a cross-toolchain goes, the NDK is quite nice. For the most part, it Just Works for compiling code. The multitude of STLs and complicated (behind the scenes) Makefile system can be annoying. However, the Makefile system is very simple for common needs. Debugging can be a pain, yes. Google is very diligent about releasing updates to fix bugs. It also has Clang now!
corresation 13y ago
That is largely unfortunate dogma. The most likely reason to use the NDK is when you are using existing C(++) code, for instance from your iOS or desktop versions of your app. For me the biggest advantage is building the app for Win64, using rich tools and a high power testing platform and just run a different make and now I have an Android app.

by bdfh42 13y ago

shadowmint 13y ago

They also say: 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++. Which continues to annoy me even now. I recall the fireside android team chat one time (two years ago?) that went something like: Question: So what about the NDK? You can't beat native for performance... Android team member: *laughs* ... well, you can't beat java for portability Comment from audience: Unless you want to use your code on another platform... <awkward silence, discussion moves on to next question> That's certainly how I feel about it.

mtdewcmu 13y ago
Good point. For better or worse, iOS is native code, and you could potentially write C or C++ that targets both.
pjmlp 13y ago
Yeah, right. However, - Google has managed to fragment the Java world - Pushes Renderscript instead of OpenCL - Forces everyone to go via JNI to access Android APIs in C and C++ land They are no better than the other players. I am actually curious to find out what are their plans in regard to ART. Only replace Dalvik, or go further in terms of what will be the set of supported languages.

djh_ 13y ago

Don't forget games, the vast majority of popular games are likely running native code. I don't have any stats on that, but you can check out the following games made using the open-source C++ framework Cocos2d-x that the developers asked to be featured: http://www.cocos2d-x.org/games/all?p=8&page=1 http://www.cocos2d-x.org/games/all?p=8&page=1

Pxtl 13y ago
Yeah, nobody wants to have a GC pause just as they're about to do something tricky.
- pjmlp 13y ago
  So maybe AAA studios shouldn't be using Unity. Oh wait...
  - corresation 13y ago
    The overwhelming bulk of a Unity game on Android runs in purely native code (the Unity shared library). Of course the game orchestration and such runs in a managed runtime (mono), but the garbage created by simple orchestration/management running in a GC is minuscule compared to the garbage created by an entire game engine running in a GC.
    - pjmlp 13y ago
      Ah you mean like the Witcher 2 for the XBox 360 where the C++ engine uses a GC?

Zigurd 13y ago

It is possible to make a substantially "NDK-only" app. Mainly for porting games.

melling 13y ago

What is like working with the NDK? C++ is the one language that can work on both iOS and Android (and Windows phone?) Personally, I'd like to get some reuse out of my iOS code. I'd do more C++ if I knew that I could reuse it. Of course, Objective C could actually be portable too.

djh_ 13y ago
Having worked with the NDK in Android Developer Tools (Google's Eclipse Fork), it's pretty painful. It takes a long time to get the environment set up and working (somewhat) nicely. You have to get a plugin to debug via ADT, I used the ARM DS-5 debugger. It works, but it's not a good user experience. I used to complain about certain niggles in Xcode, but having used ADT, I shall never complain again. Comparatively, using Xcode is a joy.
- mox1 13y ago
  I used the Android NDK extensively for an app I wrote recently. The main reasons were for cross compatibility (future iOS port) and because a 3rd party library I needed was written in C. If your new to the world of C/C++..then maybe its painful, but for me it was easy to get up and running. They use the GCC toolchain behind the scenes, with gdb as the debugger. The NDK exists as a download for windows,OSX and Linux. I developed exclusively on OSX (10.8) (Using the android develop toolkit (aka ADT) which is basically a re-skinned Eclipse) and then enabled "ADB over IP" on my Nexus 4. After a bit of setup (like adb connect 'local ip' ) the Android version of gdb (ndk-gdb) on the mac just "sees" your phone, finds the process and automatically connects. If / when a crash would happen (and it happend a lot :) ) you get a stack trace, code line numbers, etc. It might not be as simple as the GUI Xcode world, but it certainly works. I've also got remote core dumps for my app, using Google's Breakpad. When the app crashes natively it uploads a core dump to my server, where I can examine what happened. Here as well you get full stack dumps, line #'s, etc.
  - jevinskie 13y ago
    As far as a cross-toolchain goes, the NDK is quite nice. For the most part, it Just Works for compiling code. The multitude of STLs and complicated (behind the scenes) Makefile system can be annoying. However, the Makefile system is very simple for common needs. Debugging can be a pain, yes. Google is very diligent about releasing updates to fix bugs. It also has Clang now!

corresation 13y ago

That is largely unfortunate dogma. The most likely reason to use the NDK is when you are using existing C(++) code, for instance from your iOS or desktop versions of your app. For me the biggest advantage is building the app for Win64, using rich tools and a high power testing platform and just run a different make and now I have an Android app.