Game Development Reference
In-Depth Information
so that it does not run in the background, eating the battery while the activity is paused. The
whole world is a happy place again. Of course, we'll need to synchronize the processing of
input events in the UI thread with our rendering thread. But that will turn out to be really easy,
which you'll see in the next chapter, when we implement our game framework based on all the
information you digested in this chapter.
Hardware-Accelerated Rendering with Canvas
Android 3.0 (Honeycomb) added a remarkable feature in the form of the ability to enable GPU
hardware acceleration for standard 2D canvas draw calls. The value of this feature varies by
application and device, as some devices will actually perform better doing 2D draws on the
CPU and others will benefit from the GPU. Under the hood, the hardware acceleration analyzes
the draw calls and converts them into OpenGL. For example, if we specify that a line should be
drawn from 0,0 to 100,100, then the hardware acceleration will put together a special line-draw
call using OpenGL and draw this to a hardware buffer that later gets composited to the screen.
Enabling this hardware acceleration is as simple as adding the following into your
AndroidManifest.xml
under the
<application />
tag:
android:hardwareAccelerated="true"
Make sure to test your game with the acceleration turned on and off on a variety of devices,
to determine if it's right for you. In the future, it may be fine to have it always on, but as with
anything, we recommend that you take the approach of testing and determining this for yourself
. Of course, there are more configuration options that let you set the hardware acceleration for
a specific application, activity, window, or view, but since we're doing games, we only plan on
having one of each, so setting it globally via application would make the most sense.
The developer of this feature of Android, Romain Guy, has a very detailed blog article about
the dos and don'ts of hardware acceleration and some general guidelines to getting decent
performance using it. The blog entry's URL is
http://android-developers.blogspot.
Best Practices
Android (or rather Dalvik) has some strange performance characteristics at times. In this section
we'll present to you some of the most important best practices that you should follow to make
your games as smooth as silk.
ï?®
The garbage collector is your biggest enemy. Once it obtains CPU time
for doing its dirty work, it will stop the world for up to 600 ms. That's half
a second that your game will not update or render. The user will complain.
Avoid object creation as much as possible, especially in your inner loops.
ï?®
Objects can get created in some not-so-obvious places that you'll want to
avoid. Don't use iterators, as they create new objects. Don't use any of the
standard
Set
or
Map
collection classes, as they create new objects on each
insertion; instead, use the
SparseArray
class provided by the Android API.
Use
StringBuffer
s instead of concatenating strings with the
+
operator. This
will create a new
StringBuffer
each time. And for the love of all that's good
in this world, don't use boxed primitives!
