Menu
I've been reading around and looking into touchEvents, mainly because my GC is exploding when there is a lengthy touch/slide event OR many touch events. If I do not touch the phone it simply idles as ~5 objects as you can see from the first few GC_EXPLICIT that I performed from DDMS. I then began to touch the screen and sliding around, and the objects shot up around 13513 objects and actually caused a GC_FOR_MALLOC that takes over 100ms. Here was my simple testing code, and below is the log of the dalvicvm tag. If you have documentation of workarounds or causes, or possibly even just another in-depth discussion of this I would greatly appreciate it! Cheers, and good luck on your own endeavors.
[code]
public class testClass extends Activity implements IOnSceneTouchListener{
int numberOfTouches = 0;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
setContentView(R.layout.main);
}
@Override
public boolean onSceneTouchEvent(Scene pScene, TouchEvent pSceneTouchEvent) {
numberOfTouches++;
return false;
}
}
[logcat]
06-28 15:24:55.317: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 53ms
06-28 15:24:55.903: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 136 bytes in 59ms
06-28 15:24:56.708: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 59ms
06-28 15:25:06.614: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 6 objects / 168 bytes in 58ms
06-28 15:25:09.833: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 7 objects / 192 bytes in 65ms
06-28 15:25:14.270: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 8 objects / 232 bytes in 59ms
06-28 15:25:18.294: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 6 objects / 160 bytes in 59ms
06-28 15:25:33.942: DEBUG/dalvikvm(1103): GC_FOR_MALLOC freed 13513 objects / 1403264 bytes in 121ms
06-28 15:26:53.684: DEBUG/dalvikvm(2139): GC_EXPLICIT freed 140 objects / 6960 bytes in 99ms
06-28 15:26:58.731: DEBUG/dalvikvm(1215): GC_EXPLICIT freed 668 objects / 71136 bytes in 117ms
06-28 15:27:31.637: DEBUG/dalvikvm(1103): GC_FOR_MALLOC freed 13962 objects / 1504296 bytes in 122ms
06-28 15:27:44.723: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 63 objects / 2152 bytes in 59ms
06-28 15:27:46.676: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 65ms
06-28 15:27:47.238: DEBUG/dalvikvm(2501): GC_EXPLICIT freed 5 objects / 128 bytes in 58ms
I've yet to actually solve the problem but have stumbled across this great article on this exact problem: Android Touch Problems
[edit] as stracka said, it's most likely due to flooding. My real issue is however with the allocations that are being made on each event? Is there a way to reuse these events/objects to limit allocations due to touch?
I'm currently using andEngine, and the touchEvents are pooled so there should be at most ~5 ever allocated from scratch; otherwise they just reuse don't they?
Thanks for any ideas....
331
Intercept touch events in a ViewGroup. The onInterceptTouchEvent() method is called whenever a touch event is detected on the surface of a ViewGroup , including on the surface of its children.
Touch event works just like the dispatching of the events but in the reverse order from child to parent. Let's say if we dispatch the event from ViewGroup and intercept the event there, it depends on the return value (true/false) that shall the touch of the view be handled on the ViewGroup or the children.
boolean onInterceptTouchEvent(MotionEvent ev) - called whenever a touch event is detected with this ViewGroup or a child of it as target. If this function returns true, the MotionEvent will be intercepted, meaning it will be not be passed on to the child, but rather to the onTouchEvent of this View.
After the Math. abs() calls, you're essentially testing if their finger is farther down the screen than it is across the screen. Store the initial down coordinates as member variables and set them during ACTION_DOWN . You declared two floats (touchX and touchY) inside the onTouchEvent method.
Are you using an older version of Android? I was just reading about the "touch event flood" problem on Android 1.5 in Beginning Android Games. The author's workaround was to put the UI thread to sleep briefly in his onTouch() handler, to limit the number of events received. I don't know how viable that solution is, or if would be of any use to you; the pertinent page from the book can be found here:
Beginning Android Games, page 131
110
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
