Modification d'une vue dans l'UI ralenti mon application

**houssine91** · 26/09/2013, 22h25

Bonsoir, j'ai un long traitement pour des edittexts dans un thread externe et l'UI avec la méthode View::post , mais le problème, c'est que l'application reste bloqué jusqu'à ce que le traitement soit terminé malgré qu'il est dans un autre thread.
et si je fait tout le traitement dans le thread principal, sa vitesse est meilleur que celle de l'autre cas.
voici le morceau de code correspondant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
	public void run() {
		Point limit;
		if(isH)
			limit=	edit2.getLimitH(); //edit2 est une instantiation d'une classe héritant EditText
		else
			limit=	edit2.getLimitV();
		for(int i=limit.x;i<=limit.y;i++){
			final MyEditText edit;
				edit = myList.get(new Point(edit2.getPosition().x, i));
 
				// la partie sensible !
				edit.post(new Runnable() {		
					@Override
					public void run() {
						if(hasFocus)
							edit.setBackgroundDrawable(bg1);
						else
							edit.setBackgroundDrawable(bg0);
					}
				}) ;
		}	
	}

**nicroman** · 27/09/2013, 03h07

A chaque étape de la boucle tu fais un "postRunnable"...
Donc le runnable est executé (en parallèle du thread principal ou presque) .

Le pire c'est qu'il est fort probable que les dernières instances du runnable tourne *après* que le thread soit terminé.

D'autre part... si il y a, disons, 300 runnables empilés à un moment donné.. le click sur un bouton sera traité *après* ces runnables. Autant dire que l'application est bloquée.

En général, on ne fait la mise à jour que X fois par seconde au maximum...

Pourquoi ne pas utiliser un AsyncTask et la notion de "progress" ?

**houssine91** · 27/09/2013, 13h20

merci pour votre réponse, mais est ce que la modification de ces vue dans un AsyncTask ne bloque pas le thread principale?

**nicroman** · 27/09/2013, 14h53

je ne saisis pas la question....

Une modification de View bloque toujours le thread principal (puisque c'est lui qui est chargé de cela).

Prenons le cas de base:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
// Thread Principal
for (int i = 0; (i < 10000); ++i)
   view.setText("Iteration #"+Integer.toString(i));

L'application est bloquée, et n'affichera rien puisque le message "refresh" sera posté par le setText, mais executé qu'à la sortie de la boucle.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
// Thread 1
for (int i = 0; (i < 10000); ++i)
   handler.postRunnable(new Runnable() { view.setText("Iteration #"+Integer.toString(i)); });

L'application est bloquée de la même manière puisque le thread principal va "empiler" 10000 messages dans le thread principal indiquant de faire exactement la même chose... Résultat identique donc, avec en prime gestion du handler / thread / runnable (potentiellement problème de mémoire donc).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// AsyncTask
class Task extends AsyncTask<Void,Integer,Void) {
    public void doInBackground(Void ... params)
    {
          for (int i = 0; (i < 10000) && !isCancelled(); ++i) 
               publishProgress(Integer.valueOf(i));
    }
 
    public void onProgressUpdate(Integer ... i)
    {
          view.setText("Iteration #"+Integer.toString(i[0]));
    }
}

La c'est différent, l'AsyncTask va demander au thread UI de raffraichir la progression sur le premier publishProgress()... Tant que ce n'est pas fait, les publishProgress suivant ne feront rien.
Quand l'UI a le temps (les autres évenements sont gérés), le thread principal va donc appeler onProgressUpdate()....

En prime l'AsyncTask gère le cancel (pas facile à faire dans un "Thread" à la main), le handler, et le pool de threads....