Fast processing of data

Question 1

While I am not certain that this is the primary problem, I do find quite a bit of inefficiency in your code:

you are creating a lot of transient objects with this

    for (byte i = 0; i < demoRxMsg.dataLength; i++) {
        data = data + Integer.toHexString(demoRxMsg.data[i]) + " ";
    }

For each byte you are creating at least two objects: one StringBuilder and one String object (ref here). If you want to get a String, at least make it like below:

    StringBuilder sb=new StringBuilder();
    for (byte i = 0; i < demoRxMsg.dataLength; i++) {
        sb.append(demoRxMsg.data[i]);
    }
    data=sb.toString();

Instead of comparing strings, it'll be much faster to compare raw bytes, this way you can skip any object creation altogether.

I assuming between the first and last few blocks of data, there are quite a bit of data in between, but in your current implementation those data that do not affect UI will still be checked on the UI thread, instead only run mProgressBar.setProgress(progress); when you have determined that UI needs to be updated. Untested code:

class RxThread extends Thread {
private static final String TEST = "0 0 0 0 0 40 0 0 ";
private static final String TEST2 = "0 1 0 0 0 41 0 0 ";
private static final String TEST3 = "2 bb 0 0 2 fb 0 0 ";
private static final String TEST4 = "2 bd 0 0 2 fd 0 0 ";
private static final String TEST5 = "2 be 0 0 2 fe 0 0 ";

Handler myHandler = new Handler();

public void run() {
while (true) {
    try {
        Thread.sleep(60);

        demoRxMsg = new MessageStructure();

        int progress = -1;
        while (rxChannel.receiveMessage(demoRxMsg) == ReturnCode.SUCCESS) {

            String data = "";
            String format = "";

            rxChannel.receiveMessage(demoRxMsg);

            if (demoRxMsg.frameFormat == API_ADK.STANDARD_FRAME) {
                format = "SFF";
            } else {
                format = "EFF";
            }
            for (byte i = 0; i < demoRxMsg.dataLength; i++) {
                data = data + Integer.toHexString(demoRxMsg.data[i])
                        + " ";
            }

            if (data.equalsIgnoreCase(TEST)) {
                progress = 0;
            } else if (data.equalsIgnoreCase(TEST2)) {
                progress = 1;
            } else if (data.equalsIgnoreCase(TEST3)) {
                progress = 94;
            } else if (data.equalsIgnoreCase(TEST4)) {
                progress = 95;
            } else if (data.equalsIgnoreCase(TEST5)) {
                progress = 96;
            }
        }
        if (progress != -1) {
            final int newProgress = progress;

            myHandler.post(new Runnable() {
                public void run() {
                    mProgressBar.setProgress(newProgress);
                }
            });
        }
    } catch (InterruptedException e) {
        break;
    }
}

} }

Question 2

Well in your special case there is indeed a possibility to optimize. findViewById() is a very expensive operation and you should try caching to speed up the code you have shown above. Read up on the holder pattern and then implement it somewhat like this:

private TextView tv;

[...]

if (data.equalsIgnoreCase(test)) {
    if (tv == null) {
        tv = (TextView) findViewById(R.id.textview);
    }
    tv.setText(" 30 % ");
}

BUT! having said that this will probably not be enough to have the effect you desire in your application. 80ms is very very very fast and Android tends to block the UI-thread for good if there is heavy work going on

So you will have to think about threading and you will have to redesign a bit probably.

My first idea would be to have the input queue running on a separate thread and only invoking a TextViewchange when you determine that there is somewhat of a pause in between. You could then update the view, knowing that this is probably blazingly fast anyway and would not have been distinguishable for the user even if all the messages would have been there

Question 3

You could have a variable hold the update information (make its update/read thread safe) and have the UI thread be in charge of the updates. The UI thread should read the data from this and update its Views. The "update" thread should modify this variable when it receives a message.

You can post a Runnable to the UI thread that updates the TextView and then re-schedules itself to be run after that. This way you'll get the most performance, as re-scheduling the Runnable would allow the UI thread to finish rendering the updated info and then get back to updating the info right away and then re-render and so on. A nice side-effect of this is that you allow the UI thread to process the user input events too.