https://dl.dropbox.com/u/60884940/a6a5xa.png
when I run other people programs they seem to have a steady and smooth movement not spike up drop spike up drop, also why would the heap size be so big if the used heap is much lower, it’s a 2D platformer game so could it be too many threads or objects
Because your program has spikes in memory allocation, after which the GC kicks in, cleaning up the garbage.
There’s nothing else to say really. Look at your code to find the cause.
Maybe you periodically create new object(s)? well, as long it doesn’t affect your game in play time don’t mind it too much.
Since it looks like your spikes are followed by an immediate GC, your allocation spike is likely happening in one place. If you enable GC logging (see here for an example of how) and add some debug logging to various bits of your program, that can help in tracking down the culprit by matching up the debug log timestamps with the GC log.
Since it’s very short-lived garbage, another alternative is to just live with it, since collecting it should be plenty fast. That’s a less palatable option on Android though.
Also your max heap size looks rather excessive versus your needs there. I’d set it to maybe 260mb and see how it goes.
Cas 
You’re probably creating a large temporary array.
A typical memory waster is to build Text out of concanated Strings.
like : message = message + " is " + “here”;
As each time a new String Object is created.
Try using a StringBuffer here.
The compiler already does that. One new String is created.
Yes its one new String object.
I ment the whole instruction with “each time”.
When used each frame for example.
Opposite to a StringBuffer where you can append a String without creating a new object.
I’m on the same boat Quadro, one thing i’ve learnt is to run memory analyzers as you develop the software to catch these sort of things, also if you use external libraries i’d check those too, make sure they aren’t the ones causing the garbage collector to go haywire.
If you’re developing a game, you can probably come up with a scheme to reuse most frequently used objects. On modern java, the GC’s are pretty optimal and on a PC platform it wouldn’t matter too much, i’d only start worrying if you were deploying for Android. Then again, reuse has never been anyone’s enemy, plenty of pooling tutorials available.