Multiple TextViews update very slowly

Question

I have a Service that sends an Intent to my Activity every 0.1 seconds. I use it to update a custom implementation of a Chronometer. Here everything goes right. The problem comes when I want to update 14 TextView I have in a TableView inside a Fragment in my Activity. Here the app is very slow.

The method in my Activity where it receives the Intent from the Service:

private BroadcastReceiver broadcastReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        long milis = intent.getLongExtra("milis",0);
        if( mFragment != null)
        mFragment.Update(milis);
    }
};

The code inside the Fragment where I update the TextViews:

public void actualizarTiempoJuego(long milis){
    // Se recuperan los tiempos acumulados y se aumenta la cantidad pasada como parámetro
    for(int i=0;i<7;++i) {
        long mCurrentMilis1 = mVectorMilis1.get(i);
        long mCurrentMilis2 = mVectorMilis2.get(i);
        TextView1 t1 = mListaTitularLayoutLocal.get(i);
        TextView1 t2 = mListaTitularLayoutVisitante.get(i);
        t1.setText(String.value(milis + mCurrentMilis1));
        t2.setText(String.value(milis + mCurrentMilis2));
    }
}

Am I doing anything wrong, or is it just that I'm trying to do something very complex in terms of efficiency?

Answer 1

@Sherif brings up a good point about hidden alpha values that bog down your application a lot. Depending on your platform you may also want to check

<application android:hardwareAccelerated="true"... />

Another thing you can look into that may help performance is not firing off all those Intents. Once you start firing intents you are getting the system involved and depending on how they are getting resolved it may take some extra time.

For this issue I like to use Handlers. They are more light weight than intent. You may also want to look at AsyncTask. This is basically like a thread, but also gives hooks that run on the UI Thread so you can perform both perform a background operation and update the UI without have to post runnables.

EDIT: Lastly, you can always run your layouts through the layoutopt tool. I was personally told by Romain Guy himself that if your drawing too slow, than you need to draw less. Just check out a screenshot (from a less than ideal view tree, but well within the max) from the profiling tool. You can see how much of the resources view drawing takes up. It's very important to keep this as lean as possible if you want your app to be responsive.

EDIT: It is no longer called layoutopt, it's called lint. Check your ~/android-sdk/tools/

Answer 2

I have once faced a situation where a fragment was really slow.

I am just predicting that your fragment has some kind of alpha and it is drawn on a 'heavy' activity.

The conclusion is that each time you are setting the text of a textview your whole view hierarchy is being invalidated.

It seems that fragments have this flaw. Anyway, use some layout instead of the fragment and check if it remains 'slow'.

---

ADDITION: A wrap_content textview will cause much more delay after a setText than a fill_parent textview.

Answer 3

You're likely running into slowdowns due to layout management with TableLayout and TextView. Every time you update text in one of those, a large amount of view measuring has to take place in order to put the characters in the right place on the screen. You should really just profile the app yourself using Traceview to find out. More information at: http://developer.android.com/tools/debugging/debugging-tracing.html

I've had the exact same issue you're seeing with the same type of layout (Fragment > TableLayout > Multiple TextViews). One way to test if your TableLayout/TextView setup is to blame is simply replace all that with a single TextView. That will probably run pretty well. Then put your 14 views into a FrameLayout or RelativeLayout. Even if they all overlap, you should still get decent performance, because it's the complexity of the TableLayout view measurements that's really causing slowdown.