Question

I am building an application for the android Phone and am experiencing some strange ‘throttling’. I believe it is because a semaphore is being called to halt whatever the application is doing to process something else within the phone. Though I’m not positive.

I am curious of if there would be a way to spread these breaks out or something else to make it less visible to the users that the application is having little lag spikes so-to-speak.

Edit: some further information, what I am currently running with is a 2d array of images – only about 80 are drawn at a time of the instanced ~8000. They only draw if their colour tint is not RGB0(pitch black). A runtime loop in the update checks what images are closest to the player and gives them a basic minimal lighting of RGB 0.2f. Other than that basic event handlers and movement/view-port loops are in the update. Note that I’m using Libgdx framework, not android native. So OpenGL etc etc

Edit: I’d like to note that the problem isn’t what you’d think it would be. I was sending a vector2 about 3800 times a render – but not just ‘sending’ one, but declaring new Vector2 and sending parameters that way. THE GARBAGE COLLECTOR WOULD NOT TOLERATE THIS ATROCITY. Runs smoothly now that I’m sending just 2 floats. My bad ._.

Answer 1

Unless there are several active processes running at the same time, this should not happen.

My guess (without seeing the code) is that the garbage collector is kicking in too much. Are you initializing objects in a loop? If so, can you reuse the objects instead?

Objects may be anything, specially Views. Make sure you reuse your Views and not create new ones.

Another point to consider is full layout redrawing: can you redraw just a portion of the screen instead of all of it? (i.e., use view.invalidate(rect); as opposed to view.invalidate();)

Lastly, are your layouts too deep? Try to make them as flat as you can. For example, use RelativeLayout instead of nested LinearLayouts.

Take some time an watch this video: Romain Guy’s Google I/O 2009 talk. Lots of information to get from there.

After the update, I see that you have 8K images to draw. If you instantiate all of them most probably there is not much room in the memory for anything else, so the GC will need to continuously collect anything it can. That means, slowing down the whole system. Check out, on the same video, the Q&A at about 53-55 min. He proposes, in situations like yours, to have all the references to bitmaps in a HashMap of soft references, so the GC can collect the unused images when needed. That would prevent collecting anything else.
I would also instantiate them in batches as needed instead of doing it all at the beginning.