Toutes les applications Android utilisent un thread principal pour gérer les opérations de l'interface utilisateur. Appels de longue durée opérations de ce thread principal peut entraîner des blocages et un manque de réponse. Pour Par exemple, si votre application envoie une requête réseau à partir du thread principal, l'UI de votre application est figée jusqu'à ce qu'elle reçoive la réponse du réseau. Si vous utilisez Java, vous pouvez créer des threads d'arrière-plan supplémentaires pour gérer les opérations de longue durée ; le thread principal continue de gérer les mises à jour de l'UI.
Ce guide explique comment les développeurs utilisant le langage de programmation Java peuvent utiliser un pool de threads pour configurer et utiliser plusieurs threads dans une application Android. Ce guide vous montre également comment définir le code à exécuter sur un thread et comment communiquer entre l'un de ces threads et le thread principal.
Bibliothèques de simultanéité
Il est important de comprendre les bases des threads et leurs ces mécanismes. Il existe cependant de nombreuses bibliothèques populaires proposant des abstractions sur ces concepts et des utilitaires prêts à l'emploi pour transmettre des données entre les threads. Ces bibliothèques incluent Guava et RxJava pour les utilisateurs du langage de programmation Java et les coroutines que nous recommandons aux utilisateurs de Kotlin.
En pratique, vous devez choisir celle qui convient le mieux à votre application de développement, même si les règles des threads restent les mêmes.
Présentation des exemples
Les exemples présentés dans cette rubrique sont basés sur le Guide de l'architecture des applications. requête réseau et renvoie le résultat au thread principal, où l'application peut afficher ce résultat à l'écran.
Plus précisément, ViewModel appelle la couche de données sur le thread principal pour
la requête réseau. La couche de données est chargée de déplacer
l'exécution de la requête réseau en dehors du thread principal et la publication du résultat
au thread principal à l'aide d'un rappel.
Pour déplacer l'exécution de la requête réseau en dehors du thread principal, nous devons créer d'autres threads dans notre application.
Créer plusieurs threads
Un pool de threads est une collection gérée de threads qui exécute des tâches dans
parallèlement à une file d'attente. Les nouvelles tâches sont exécutées sur des threads existants
les threads deviennent inactifs. Pour envoyer une tâche à un pool de threads, utilisez la
ExecutorService. Notez que ExecutorService n'a rien à voir
avec Services, le composant d'application Android.
La création de threads est coûteuse. Vous ne devez donc créer un pool de threads qu'une seule fois
que votre application initialise. Veillez à enregistrer l'instance de ExecutorService.
soit dans la classe Application, soit dans un conteneur d'injection de dépendances.
L'exemple suivant crée un pool de quatre threads que nous pouvons utiliser pour
exécuter des tâches en arrière-plan.
public class MyApplication extends Application {
ExecutorService executorService = Executors.newFixedThreadPool(4);
}
Il existe d'autres façons de configurer un pool de threads en fonction des charge de travail spécifique. Pour en savoir plus, consultez la section Configurer un pool de threads.
Exécuter dans un thread d'arrière-plan
Effectuer une requête réseau sur le thread principal entraîne l'attente du thread.
block, jusqu'à ce qu'il reçoive une réponse. Comme le thread est bloqué, le système d'exploitation ne peut pas
appelez onDraw(), et votre application se fige, ce qui peut entraîner une erreur
Boîte de dialogue "Répondre" (ANR). Exécutons plutôt cette opération sur un arrière-plan
thread.
Envoyer la demande
Tout d'abord, examinons la classe LoginRepository et voyons comment elle contribue
la requête réseau:
// Result.java
public abstract class Result<T> {
private Result() {}
public static final class Success<T> extends Result<T> {
public T data;
public Success(T data) {
this.data = data;
}
}
public static final class Error<T> extends Result<T> {
public Exception exception;
public Error(Exception exception) {
this.exception = exception;
}
}
}
// LoginRepository.java
public class LoginRepository {
private final String loginUrl = "https://example.com/login";
private final LoginResponseParser responseParser;
public LoginRepository(LoginResponseParser responseParser) {
this.responseParser = responseParser;
}
public Result<LoginResponse> makeLoginRequest(String jsonBody) {
try {
URL url = new URL(loginUrl);
HttpURLConnection httpConnection = (HttpURLConnection) url.openConnection();
httpConnection.setRequestMethod("POST");
httpConnection.setRequestProperty("Content-Type", "application/json; charset=utf-8");
httpConnection.setRequestProperty("Accept", "application/json");
httpConnection.setDoOutput(true);
httpConnection.getOutputStream().write(jsonBody.getBytes("utf-8"));
LoginResponse loginResponse = responseParser.parse(httpConnection.getInputStream());
return new Result.Success<LoginResponse>(loginResponse);
} catch (Exception e) {
return new Result.Error<LoginResponse>(e);
}
}
}
makeLoginRequest() est synchrone et bloque le thread d'appel. Pour modéliser les
à la requête réseau, nous avons notre propre classe Result.
Déclencher la requête
ViewModel déclenche la requête réseau lorsque l'utilisateur appuie, par exemple sur
un bouton:
public class LoginViewModel {
private final LoginRepository loginRepository;
public LoginViewModel(LoginRepository loginRepository) {
this.loginRepository = loginRepository;
}
public void makeLoginRequest(String username, String token) {
String jsonBody = "{ username: \"" + username + "\", token: \"" + token + "\" }";
loginRepository.makeLoginRequest(jsonBody);
}
}
Avec le code précédent, LoginViewModel bloque le thread principal lors de la création
la requête réseau. Nous pouvons utiliser le pool de threads que nous avons instancié pour déplacer
l'exécution sur un thread d'arrière-plan.
Gérer l'injection de dépendances
Tout d'abord, en suivant les principes de l'injection de dépendances, LoginRepository
utilise une instance d'Executor et non de ExecutorService, car
exécuter du code et ne pas gérer les threads:
public class LoginRepository {
...
private final Executor executor;
public LoginRepository(LoginResponseParser responseParser, Executor executor) {
this.responseParser = responseParser;
this.executor = executor;
}
...
}
La méthode execute() de l'exécuteur utilise un Runnable. Un Runnable est un
Interface SAM (Single Abstract Method) avec une méthode run() exécutée dans
un thread lorsqu'il est appelé.
Exécuter en arrière-plan
Créons une autre fonction appelée makeLoginRequest(), qui déplace
sur le thread d'arrière-plan et ignore la réponse pour le moment:
public class LoginRepository {
...
public void makeLoginRequest(final String jsonBody) {
executor.execute(new Runnable() {
@Override
public void run() {
Result<LoginResponse> ignoredResponse = makeSynchronousLoginRequest(jsonBody);
}
});
}
public Result<LoginResponse> makeSynchronousLoginRequest(String jsonBody) {
... // HttpURLConnection logic
}
...
}
Dans la méthode execute(), nous créons un Runnable avec le bloc de code.
que nous voulons exécuter dans le thread d'arrière-plan. Dans notre cas, le réseau synchrone
. En interne, ExecutorService gère les Runnable et
l'exécute dans un thread disponible.
Points à prendre en compte
Tout thread de votre application peut s'exécuter en parallèle d'autres threads, y compris le thread principal Vous devez donc vous assurer que votre code est thread-safe. Notez que dans notre exemple qu'on évite d'écrire dans des variables partagées entre les threads, de transmettre des données immuables à la place. C'est une bonne pratique, car chaque fil de discussion fonctionne avec ses propres instances de données, et la synchronisation est simplifiée.
Si vous devez partager l'état entre les threads, vous devez veiller à gérer l'accès à partir de threads à l'aide de mécanismes de synchronisation tels que les verrous. Ceci est en dehors de le champ d'application de ce guide. En général, vous devez éviter de partager un état modifiable entre les threads autant que possible.
Communiquer avec le thread principal
À l'étape précédente, nous avons ignoré la réponse à la requête réseau. Pour afficher la
résultat à l'écran, LoginViewModel doit en être informé. Nous pouvons le faire en
à l'aide de rappels.
La fonction makeLoginRequest() doit utiliser un rappel en tant que paramètre afin que :
il peut renvoyer une valeur de manière asynchrone. Le rappel avec le résultat est appelé
chaque fois que la requête réseau
se termine ou qu'un échec se produit. En Kotlin, nous pouvons
utiliser une fonction
d'ordre supérieur. Cependant, en Java, nous devons créer un nouveau rappel
aient les mêmes fonctionnalités:
interface RepositoryCallback<T> {
void onComplete(Result<T> result);
}
public class LoginRepository {
...
public void makeLoginRequest(
final String jsonBody,
final RepositoryCallback<LoginResponse> callback
) {
executor.execute(new Runnable() {
@Override
public void run() {
try {
Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
callback.onComplete(result);
} catch (Exception e) {
Result<LoginResponse> errorResult = new Result.Error<>(e);
callback.onComplete(errorResult);
}
}
});
}
...
}
ViewModel doit implémenter le rappel maintenant. Il peut effectuer différentes opérations
en fonction du résultat:
public class LoginViewModel {
...
public void makeLoginRequest(String username, String token) {
String jsonBody = "{ username: \"" + username + "\", token: \"" + token + "\" }";
loginRepository.makeLoginRequest(jsonBody, new RepositoryCallback<LoginResponse>() {
@Override
public void onComplete(Result<LoginResponse> result) {
if (result instanceof Result.Success) {
// Happy path
} else {
// Show error in UI
}
}
});
}
}
Dans cet exemple, le rappel est exécuté dans le thread appelant, qui est un thread d'arrière-plan. Cela signifie que vous ne pouvez pas modifier ni communiquer directement avec la couche d'UI jusqu'à ce que vous reveniez au thread principal.
Utiliser des gestionnaires
Vous pouvez utiliser un Handler pour mettre en file d'attente une action à effectuer sur un autre
thread. Pour spécifier le thread sur lequel exécuter l'action, créez le
Handler à l'aide d'un looper pour le thread. Un Looper est un objet qui s'exécute
dans la boucle de messages d'un fil de discussion associé. Une fois que vous avez créé un Handler, vous
vous pouvez ensuite utiliser la méthode post(Runnable) pour exécuter un bloc de code dans
thread correspondant.
Looper inclut une fonction d'assistance, getMainLooper(), qui récupère les
Looper du thread principal. Vous pouvez exécuter du code dans le thread principal à l'aide de cette
Looper pour créer un Handler Comme c'est quelque chose que
vous pourriez faire assez souvent,
vous pouvez également enregistrer une instance de Handler à l'endroit où vous avez enregistré le
ExecutorService:
public class MyApplication extends Application {
ExecutorService executorService = Executors.newFixedThreadPool(4);
Handler mainThreadHandler = HandlerCompat.createAsync(Looper.getMainLooper());
}
Il est recommandé d'injecter le gestionnaire dans le dépôt, car il donne
plus de flexibilité. Par exemple, à l'avenir, vous voudrez peut-être transmettre un
un Handler différent pour planifier des tâches dans un thread distinct. Si vous avez toujours
communiquant avec le même thread, vous pouvez transmettre le Handler au
de dépôt, comme illustré dans l'exemple suivant.
public class LoginRepository {
...
private final Handler resultHandler;
public LoginRepository(LoginResponseParser responseParser, Executor executor,
Handler resultHandler) {
this.responseParser = responseParser;
this.executor = executor;
this.resultHandler = resultHandler;
}
public void makeLoginRequest(
final String jsonBody,
final RepositoryCallback<LoginResponse> callback
) {
executor.execute(new Runnable() {
@Override
public void run() {
try {
Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
notifyResult(result, callback);
} catch (Exception e) {
Result<LoginResponse> errorResult = new Result.Error<>(e);
notifyResult(errorResult, callback);
}
}
});
}
private void notifyResult(
final Result<LoginResponse> result,
final RepositoryCallback<LoginResponse> callback,
) {
resultHandler.post(new Runnable() {
@Override
public void run() {
callback.onComplete(result);
}
});
}
...
}
Pour plus de flexibilité, vous pouvez également transmettre un Handler à chaque
:
public class LoginRepository {
...
public void makeLoginRequest(
final String jsonBody,
final RepositoryCallback<LoginResponse> callback,
final Handler resultHandler,
) {
executor.execute(new Runnable() {
@Override
public void run() {
try {
Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
notifyResult(result, callback, resultHandler);
} catch (Exception e) {
Result<LoginResponse> errorResult = new Result.Error<>(e);
notifyResult(errorResult, callback, resultHandler);
}
}
});
}
private void notifyResult(
final Result<LoginResponse> result,
final RepositoryCallback<LoginResponse> callback,
final Handler resultHandler
) {
resultHandler.post(new Runnable() {
@Override
public void run() {
callback.onComplete(result);
}
});
}
}
Dans cet exemple, le rappel transmis dans l'objet makeLoginRequest du Repository
est exécuté sur le thread principal. Vous pouvez donc modifier directement l'UI
à partir du rappel ou utiliser LiveData.setValue() pour communiquer avec l'UI.
Configurer un pool de threads
Vous pouvez créer un pool de threads à l'aide de l'une des fonctions d'assistance Executor avec des paramètres prédéfinis, comme indiqué dans l'exemple de code précédent. Par ailleurs, Si vous souhaitez personnaliser les détails du pool de threads, vous pouvez créer un à l'aide de ThreadPoolExecutor. Vous pouvez configurer les paramètres suivants : détails:
- Taille initiale et maximale du pool.
- Maintenir la durée de vie et l'unité de temps. La durée de conservation correspond à la durée maximale qu'un thread peut rester inactif avant son arrêt.
- File d'attente d'entrée contenant
Runnabletâches. Cette file d'attente doit implémenter BlockingQueue. Pour répondre aux exigences de votre application, vous pouvez choisir parmi les implémentations de file d'attente disponibles. Pour en savoir plus, consultez le cours présentation de ThreadPoolExecutor.
Voici un exemple qui spécifie la taille du pool de threads en fonction du nombre total de cœurs de processeur, un temps de conservation d'une seconde et une file d'attente d'entrée.
public class MyApplication extends Application {
/*
* Gets the number of available cores
* (not always the same as the maximum number of cores)
*/
private static int NUMBER_OF_CORES = Runtime.getRuntime().availableProcessors();
// Instantiates the queue of Runnables as a LinkedBlockingQueue
private final BlockingQueue<Runnable> workQueue = new LinkedBlockingQueue<Runnable>();
// Sets the amount of time an idle thread waits before terminating
private static final int KEEP_ALIVE_TIME = 1;
// Sets the Time Unit to seconds
private static final TimeUnit KEEP_ALIVE_TIME_UNIT = TimeUnit.SECONDS;
// Creates a thread pool manager
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
NUMBER_OF_CORES, // Initial pool size
NUMBER_OF_CORES, // Max pool size
KEEP_ALIVE_TIME,
KEEP_ALIVE_TIME_UNIT,
workQueue
);
...
}