Android：Touch严重降低了我的应用程序速度

Question

I've been raking my brains on this one for a while.

when I'm running my application (opengl game) eveyrthing goes fine but when I touch the screen my application slows down quite seriously (not noticeable on powerful phones like the nexus one, but on the htc magic it gets quite annoying).

I did a trace and found out that the touch events seem to be handled in a different thread and even if it doesn't take so much processing time I think androids ability to switch between threads is not so good...

What is the best way to handle touch when speed is an issue ?

Currently I'm using : in the GLSurfaceView

@Override
 public boolean onTouchEvent(MotionEvent event) {
     GameHandler.onTouchEvent(event);
     return true;
 }

Any ideas are welcome

Answer 1

I have a feeling the bug report below may be relevant. Sadly in seems its only going to be fixed in gingerbread.

Bug report

Have just seen that SO prefers details in the answers in case links vanish etc. the above refers to a google accepted bug in Adnroid 2.1 targetted for a fix in the gingerbread release.

Issue 7836: system_server consumes excessive CPU processing touch events

Answer 2

I can't vouch for this myself, but my research has shown that touching the screen fires so many events that it floods the events queue and therefore lags the CPU taking your resources.

Try putting: -

   try {
        Thread.sleep(16);
    } catch (InterruptedException e) {} //ignore

before any returns that you have in the onTouch method (usually there's only the one at the end - but just making sure). I know sleep is usually a very bad thing to do, but its not in the UI thread so it should be ok. Sleep 16 should cap the FPS to 60.

Answer 3

Don't put heavy computation to your onTouchEvent(). The OnTouchEvent can be fired tens or hundred of times per second per finger, you should defer the heavy computation to the other part of your game (eg the physics engine or the graphic engine). In particular avoid drawing in your onTouchEvent.

You should preferrably use onClickEvent or other less intensive mouse event and only use onTouchEvent when you really need to track the motion of the touch.

Answer 4

@Jason:

This was going to be a comment, but it grew too big and it is a different [better] answer to the one I just gave.

I have changed my implementation using this method as described here http://obviam.net/index.php/the-android-game-loop/

By employing the method described above means you should not need to sleep the OnTouch events.

Also don't forget to protect your game loop thread as mentioned here http://wonton-games.blogspot.com/2010/06/lunar-lander-resume-game-workaround.html

Also also keep in mind that Chris Pruett when writing Replica Island said he used 2 threads, one for the update() and the other for render() - both will have to be protected.

Chris does sleep his OnTouch with 16 milliseconds (60 fps) to cut back the events - so I would say its best to experiment if you still need to cut the events down - you need only touch the screen whilst stuff is happening to see if it lags and thus subsequently speeds up when let go.

For my needs currently I am using the same thread as I haven't progressed into OpenGL, I still use the canvas. But when I go OpenGL, it will be 2 threads, and each will be a complete class of its own.

Finally, I don't time my sprites by counting frames, I've wrapped them with a timer. I'll share my Class and show you how I call it. Bear in mind I am still new to Java so apologies for poor code.

package com.yourname.yourapplication;

//Used for doing something after a set time
public class TimeDo {
    private int mRepeat = 0; //Stores the last wait period for the reset() later
    private long mTime = 0; //The goal time of when its due
    private boolean mFlagged = false; //Stop them getting a second true on a subsequent check

    public TimeDo(int milliseconds) {
        reset(milliseconds);
    }

    public TimeDo() {
        this(0);
    }

    public void reset(int milliseconds) {
        mRepeat = milliseconds;
        mTime = System.currentTimeMillis() + milliseconds;
        mFlagged = mRepeat==0; //ignore if zero
    }

    public void reset() { //Set it back to the delay used last time 
        reset(mRepeat);
    }

    public boolean check() {
        if (mFlagged) //Assert: shouldn't really happen
            return false;
        mFlagged = System.currentTimeMillis() > mTime; 
        return mFlagged;
    }

    public boolean checkAndReset() {
        if (check()) {
            reset();
            return true;
        }
        return false; //note mFlagged could be true here, so don't use it
    }

}

And it is implemented thusly: -

public class Gem {
    private TimeDo mMoveGem = new TimeDo(100); //move 10 times a second, 100ms 
    private int mX = 0;
    private int mY = 0;
    private int mMoveX = 3;
    private int mMoveY = 4;
    .
    .
    .   
    public void update() {
        if (mMoveGem.checkAndReset()) {
            mX += mMoveX;
            mY += mMoveY;
            .
            .
        }
    }

    public void render(Canvas canvas) {
    //etc etc
        .
        .
    }

}

Hope any of that helps! Sorry if you have to rewrite lots of your application - I did.

Edit: That TimeDo class is not a postDelayed runnable, like an automatic alarm. If you don't check it no "event" will fire. You could get excited and have it create a runnable and pass it a callback method that resides within your class (think of an OnClick method) - but defeats the purpose of running an exclusive time-able update() thread that updates all your components.