Question

I asked a lead in to this question here. I want to know if it is recommended to read the android resources (in the res) folder on the ui-thread or on the game thread for a simple game (based off the lunar lander sample). I see in lunar lander that they allocate resources before starting the game loop. However that doesn’t scale up very well if there are lots of resources. The answer to my previous question says that it is ok to read resources like bitmaps on the background thread. Now I want to know if this is the correct way to do things.

An alternate architecture would be to post a Runnable to the ui-thread from time to time and allocate resources then.

Does garbage collection come into play? I wasn’t sure which thread GC runs on. But my guess is that it runs on the thread on which the object was allocated.

Answer 1

The answer to my previous question says that it is ok to read
resources like bitmaps on the background thread. Now I want to know if
this is the correct way to do things.

As per the doc here,

The BitmapFactory.decode* methods, discussed in the Load Large Bitmaps
Efficiently lesson, should not be executed on the main UI thread if
the source data is read from disk or a network location (or really any
source other than memory). The time this data takes to load is
unpredictable and depends on a variety of factors (speed of reading
from disk or network, size of image, power of CPU, etc.). If one of
these tasks blocks the UI thread, the system flags your application as
non-responsive and the user has the option of closing it (see
Designing for Responsiveness for more information).

So you can use a seperate thread to load resources on above mentioned conditions.

I think it depends on your needs and the size and number of resource and even if there are some other things to consider. For an instance, if you don’t want your app user to navigate to the next screen until all your resources are loaded then using a thread may be helpful.

Garbage collection works in daemon thread. The daemon thread runs in the background.
Garbage collection comes into action when object becomes eligible for garbage collection i.e, when there are no live reference available or when memory becomes too low. Use this link to get to know about using tracking memory allocations and how to avoid frequent garbage collection to happen.