Thoughts on Android NDK
4,332
6
Advertisement
In my spare spare time (that is, my time not dedicated to my day job or an active side project), I've been hacking with porting Word Duelist from iPhone to the Android NDK. I wrote my core iPhone code in C++ without STL specifically to facilitate this. Of course, then Google announced the newer versions of the NDK would have full STL support, but that is neither here nor there.
Here are some of my experiences in no particular order:
Here are some of my experiences in no particular order:
- Eclipse integration is a little wonky. I've found that after I build my C++ library, if I don't then manually refresh the Eclipse project it doesn't pick up my changes. This caused a lot of hair pulling in the beginning until I figured this out.
- All the same, most everything just worked. Aside from some blatantly platform dependent code (file loading mostly) and a few minor nitpicks, I was able to move my C++ codebase over with ease. I was relieved that the OpenGL rendering code required no changes to get the game up and rendering.
- Calling C++ code from within Java is trivially easy. The other way around, though, has a fair number of quirks. I still haven't figured out how to call a void Java method from w/in C++ - all my methods return integers or else things go wrong.
- Loading files is hairy. I haven't found a good way to read an entire file in as a single string. There's a good reason to want to do this - reading in a file line-by-line generates garbage, which in turn invokes the garbage collector, which drastically slows down load times. When you're talking about loading a 40,000 line word list or a large XML file, it's prohibitively expensive. For a lot of files, a solution is to flatten the file into a single line (if possible), but that hasn't worked for the word list since it takes up too much memory when loaded in bulk. I may get away with moving my assets to a different directory and loading them w/in C++ code? I'm not sure yet.
- This isn't NDK specific, but developing on the actual device is usually faster than using the emulator. Android emulators are *slow.*
- The OpenGL rendering does have a few glitches. Alpha blending seems to behave a little strangely in some cases. Still trying to isolate this.
- Debugging is fussy. The Eclipse debugger is not wildly great as is, but I haven't yet worked out a way to debug my C++ code. Luckily most of my code was already debugged during iPhone dev, so I only have to worry about the communication layer between Java & C++.
- It's pretty important to decouple updating & rendering when using GLSurfaceView. With the iPhone I just wrapped them up together and it worked fine, but when using GLSurfaceView there's a noticeable slowdown (I'm guessing the redraw isn't invoked as often). Unfortunately the multithreading is a little tricky since any texture operations need to be invoked within the rendering thread, and I didn't plan for that initially. Oops.
- I haven't found a good way to handle memory issues. I'm finding I exhaust memory quickly. On iPhone, I got a memory warning that I could respond to before my app shut down and unload unneeded gunk, but I haven't found an equivalent for Android - probably because it expects to manage all the memory. This probably just means I need to be more careful about when I unload textures.
Working with the NDK hasn't been completely painless, but it's not the worst platform I've worked with. I don't have a timeline for Word Duelist's release there, there's still a fair bit of debugging ahead, but if progress moves the way it has I expect a month or two.
Advertisement
Advertisement
Advertisement
Discussion