Principes de base d’Android: exécuter du code dans le thread d’interface utilisateur

Dans le sharepoint vue du code en cours d’exécution dans le thread d’interface utilisateur, existe-t-il une différence entre:

MainActivity.this.runOnUiThread(new Runnable() { public void run() { Log.d("UI thread", "I am the UI thread"); } }); 

ou

 MainActivity.this.myView.post(new Runnable() { public void run() { Log.d("UI thread", "I am the UI thread"); } }); 

et

 private class BackgroundTask extends AsyncTask { protected void onPostExecute(Bitmap result) { Log.d("UI thread", "I am the UI thread"); } } 

Aucun d’entre eux n’est exactement le même, bien qu’ils auront tous le même effet net.

La différence entre le premier et le second est que si vous êtes sur le thread principal de l’application lors de l’exécution du code, le premier ( runOnUiThread() ) exécutera le Runnable immédiatement. Le second ( post() ) place toujours le Runnable à la fin de la queue des événements, même si vous êtes déjà sur le thread principal de l’application.

Le troisième, en supposant que vous créez et exécutez une instance de BackgroundTask , perdra beaucoup de temps à extraire un thread du pool de threads, pour exécuter un no-op par défaut doInBackground() avant de finir par un post() . C’est de loin le moins efficace des trois. Utilisez AsyncTask si vous avez réellement du travail à faire dans un thread d’arrière-plan, pas uniquement pour l’utilisation de onPostExecute() .

J’aime celui du commentaire HPP , il peut être utilisé n’importe où sans aucun paramètre:

 new Handler(Looper.getMainLooper()).post(new Runnable() { @Override public void run() { Log.d("UI thread", "I am the UI thread"); } }); 

Il y a une quasortingème manière d’utiliser Handler

 new Handler().post(new Runnable() { @Override public void run() { // Code here will run in UI thread } }); 

La réponse de Pomber est acceptable, mais je ne suis pas très fan de créer de nouveaux objects à plusieurs resockets. Les meilleures solutions sont toujours celles qui tentent d’atténuer la mémoire. Oui, il existe une récupération automatique de mémoire, mais la conservation de la mémoire dans un appareil mobile se situe dans les limites des meilleures pratiques. Le code ci-dessous met à jour un TextView dans un service.

 TextViewUpdater textViewUpdater = new TextViewUpdater(); Handler textViewUpdaterHandler = new Handler(Looper.getMainLooper()); private class TextViewUpdater implements Runnable{ private Ssortingng txt; @Override public void run() { searchResultTextView.setText(txt); } public void setText(Ssortingng txt){ this.txt = txt; } } 

Il peut être utilisé de n’importe où comme ceci:

 textViewUpdater.setText("Hello"); textViewUpdaterHandler.post(textViewUpdater); 

Si vous devez utiliser dans Fragment, vous devez utiliser

 private Context context; @Override public void onAttach(Context context) { super.onAttach(context); this.context = context; } ((MainActivity)context).runOnUiThread(new Runnable() { public void run() { Log.d("UI thread", "I am the UI thread"); } }); 

au lieu de

 getActivity().runOnUiThread(new Runnable() { public void run() { Log.d("UI thread", "I am the UI thread"); } }); 

Parce qu’il y aura une exception de pointeur nul dans certaines situations, comme un fragment de pageur

salut les gars celui-ci est la question de base tout à part je dis

utiliser Handler

 new Handler().post(new Runnable() { @Override public void run() { // Code here will run in UI thread } }); 

Depuis Android P, vous pouvez utiliser getMainExecutor() :

 getMainExecutor().execute(new Runnable() { @Override public void run() { // Code will run on the main thread } }); 

À partir des documents de développement Android :

Renvoie un exécuteur exécutant des tâches en queue sur le thread principal associé à ce contexte. C’est le thread utilisé pour envoyer les appels aux composants de l’application (activités, services, etc.).

Du CommonsBlog :

Vous pouvez appeler getMainExecutor () sur Context pour obtenir un exécuteur exécutant ses travaux sur le thread principal de l’application. Il y a d’autres manières d’accomplir ceci, en utilisant Looper et une implémentation personnalisée d’Executor, mais c’est plus simple.