runOnUiThread vs Looper.getMainLooper().post dans Android

Question

Quelqu'un peut-il me dire s'il y a une différence entre utiliser runOnUiThread() contre Looper.getMainLooper().post() pour exécuter une tâche sur le thread de l'interface utilisateur dans Android ? ?

La seule chose que je peux déterminer est que, puisque runOnUiThread est une méthode Activity non statique, Looper.getMainLooper().post() est plus pratique lorsque vous devez coder quelque chose dans une classe qui ne peut pas voir l'activité (comme une interface).

Je ne cherche pas à discuter de la question de savoir si quelque chose doit être exécuté sur le thread de l'interface utilisateur, je comprends que certaines choses ne peuvent pas être exécutées et que beaucoup de choses ne devraient pas l'être, mais certaines choses (comme le démarrage d'une tâche asynchrone) DOIVENT être exécutées à partir du thread de l'interface utilisateur.

Answer 1

Ce qui suit se comporte de la même manière lorsqu'il est appelé à partir de threads d'arrière-plan :

• en utilisant Looper.getMainLooper()

  Runnable task = getTask();
  new Handler(Looper.getMainLooper()).post(task);

• en utilisant Activity#runOnUiThread()

  Runnable task = getTask();
  runOnUiThread(task);

La seule différence est que lorsque vous le faites à partir du fil d'interface utilisateur puisque

public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);
    } else {
        action.run();
    }
}

vérifiera si le thread actuel est déjà le thread de l'interface utilisateur et l'exécutera directement. Le fait de le poster en tant que message retardera l'exécution jusqu'à ce que vous reveniez de la méthode du fil d'interface utilisateur actuel.

Il existe également une troisième manière d'exécuter un Runnable sur le thread de l'interface utilisateur qui serait View#post(Runnable) - celui-ci affichera toujours le message, même s'il est appelé depuis le thread de l'interface utilisateur. C'est utile car cela permet de s'assurer que le View a été correctement construit et a une disposition avant que le code ne soit exécuté.