La gestion des opérations concurrentse et asynchrones est un aspect fondamental du développement Android. L'architecture des applications Android exige que les opérations bloquantes ne soient pas exécutées sur le thread UI principal pour maintenir la fluidité de l'interfaec. Traditionnellement, les développeurs ont utilisé les combinaisons Handler et Looper avec des threads personnalisés pour gérer les communications entre threads. Cependant, cette approche, bien que puissante, peut introduire des vulnérabilités, notamment des exceptions de pointeur nul (NullPointerException) si le Looper n'est pas correctement initialisé au moment de l'accès.
Considérons un scénario où une activité principale tente d'interagir avec un Handler appartenant à un thread de travail nouvellement créé. Le code suivant illustre un piège courant :
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.os.Looper;
import android.os.Message;
import android.util.Log;
public class MainAppActivity extends Activity {
// Thread personnalisé pour les opérations en arrière-plan
class BackgroundWorkerThread extends Thread {
public Handler workerHandler; // Le Handler que d'autres threads peuvent utiliser
public Looper workerLooper; // Le Looper associé à ce thread
@Override
public void run() {
Looper.prepare(); // 1. Prépare le Looper pour ce thread
workerLooper = Looper.myLooper();
workerHandler = new Handler(workerLooper) { // 2. Crée un Handler sur ce Looper
@Override
public void handleMessage(Message msg) {
Log.d("BackgroundWorker", "Message reçu sur le thread : " + Thread.currentThread().getName() + ", Msg code: " + msg.what);
}
};
Looper.loop(); // 3. Lance la boucle de messages
Log.d("BackgroundWorker", "Le Looper du thread de travail est arrêté.");
}
}
private BackgroundWorkerThread worker;
private Handler externalHandlerToWorker; // Un Handler depuis le thread UI pour envoyer des messages au worker
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Suppression du setContentView pour un exemple plus concis, on se concentre sur les threads
// setContentView(R.layout.activity_main); // Supposons un layout simple
worker = new BackgroundWorkerThread();
worker.start(); // Démarre le thread de travail
// Tentative d'interaction immédiate avec le thread de travail
// C'est ici que l'exception de pointeur nul peut survenir.
// Le Looper et le Handler du worker pourraient ne pas être encore initialisés
// lorsque le thread principal tente d'y accéder.
try {
// Une attente artificielle (mauvaise pratique) pour tenter d'éviter l'NPE,
// mais ne garantit pas que le Looper et Handler soient prêts.
Thread.sleep(500); // Ne garantit RIEN!
// Accès au Handler du worker via sa référence publique
if (worker.workerHandler != null) {
worker.workerHandler.sendEmptyMessage(10);
} else {
Log.e("MainAppActivity", "worker.workerHandler est null au moment de l'accès!");
}
// Création d'un Handler sur le thread UI pour envoyer des messages au Looper du worker
// Cette ligne est particulièrement sujette à l'NPE si worker.workerLooper est null
externalHandlerToWorker = new Handler(worker.workerLooper) {
@Override
public void handleMessage(Message msg) {
// Cette méthode ne sera jamais appelée sur le thread UI, mais sur le worker thread.
Log.d("MainAppActivity", "Message traité par le worker via externalHandler, sur le thread : " + Thread.currentThread().getName());
}
};
externalHandlerToWorker.sendEmptyMessage(20);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // Réinitialise le statut d'interruption
Log.e("MainAppActivity", "Interruption lors de l'attente : " + e.getMessage());
} catch (NullPointerException e) {
Log.e("MainAppActivity", "Erreur: NullPointerException - le Looper ou le Handler du worker n'était pas prêt. " + e.getMessage());
}
}
@Override
protected void onDestroy() {
super.onDestroy();
// S'assurer d'arrêter proprement le Looper du thread de travail
if (worker != null && worker.workerLooper != null) {
worker.workerLooper.quitSafely();
}
}
}
L'erreur principale dans l'exemple ci-dessus provient de la nature non déterministe de l'exécution des threads. Le thread principal démarre BackgroundWorkerThread et tente ensuite immédiatement d'accéder à worker.workerLooper et worker.workerHandler. Il est très probable que la méthode run() du BackgroundWorkerThread n'ait pas encore eu le temps d'exécuter Looper.prepare(), d'assigner workerLooper, et de créer workerHandler avant que le thread principal ne tente d'utiliser ces objets. Ceci conduit inévitablement à une NullPointerException.
Pour résoudre ce problème de synchronisation de manière fiable, Android fournit la classe HandlerThread. Cette classe spécialisée est conçue pour simplifier la création d'un thread avec un Looper intégré et prêt à l'epmloi. Elle gère la préparation et le démarrage du Looper en interne, éliminant ainsi le risque de race conditions.
Voici comment utiliser HandlerThread pour gérer les tâches en arrière-plan en toute sécurité :
import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.os.HandlerThread;
import android.os.Message;
import android.util.Log;
import android.widget.TextView;
public class SecureBackgroundActivity extends Activity {
private HandlerThread backgroundProcessingThread;
private Handler taskProcessorHandler; // Handler pour envoyer des tâches au backgroundProcessingThread
private TextView statusTextView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
statusTextView = new TextView(this);
statusTextView.setText("Initialisation du traitement en arrière-plan...");
setContentView(statusTextView);
// 1. Création d'un HandlerThread
// Le constructeur prend un nom qui sera utilisé pour le débogage.
backgroundProcessingThread = new HandlerThread("MonThreadDeTraitement");
backgroundProcessingThread.start(); // 2. Démarrage du HandlerThread (cela prépare son Looper)
// 3. Création d'un Handler associé au Looper du HandlerThread
// getLooper() ne retournera JAMAIS null après un start() réussi.
taskProcessorHandler = new Handler(backgroundProcessingThread.getLooper()) {
@Override
public void handleMessage(Message msg) {
// Cette méthode est exécutée sur le "backgroundProcessingThread"
Log.d("SecureBackground", "Message reçu sur le thread : " + Thread.currentThread().getName() + ", Code: " + msg.what);
// Exemple d'opération longue
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
Log.e("SecureBackground", "Traitement interrompu", e);
}
// Pour interagir avec l'UI, il faut un Handler du thread UI
runOnUiThread(() -> statusTextView.setText("Message " + msg.what + " traité."));
}
};
// 4. Envoi de messages au HandlerThread
taskProcessorHandler.sendEmptyMessage(101);
taskProcessorHandler.obtainMessage(102, "Données à traiter").sendToTarget();
taskProcessorHandler.postDelayed(() -> {
Log.d("SecureBackground", "Tâche différée exécutée.");
runOnUiThread(() -> statusTextView.setText("Tâche différée terminée."));
}, 3000); // Exécute après 3 secondes
}
@Override
protected void onDestroy() {
super.onDestroy();
// Il est crucial d'arrêter proprement le HandlerThread
// afin de libérer ses ressources et de terminer sa boucle de messages.
if (backgroundProcessingThread != null) {
backgroundProcessingThread.quitSafely(); // Arrête le Looper et vide sa file d'attente
}
}
}
Dans cette approche, l'instanciation et le démarrage de backgroundProcessingThread garantissent que son Looper est entièrement opérationnel avant d'être récupéré via getLooper(). Ainsi, la création de taskProcessorHandler avec ce Looper est toujours sûre, éliminant le risque de NullPointerException lié à l'initialisation du Looper. HandlerThread est la méthode préférée pour les opérations en arrière-plan qui nécessitent une file d'attente de messages et une interaction via des Handlers.