Threading dans Xamarin.iOS
Le runtime Xamarin.iOS permet aux développeurs d’accéder aux API de threading .NET, à la fois explicitement lors de l’utilisation de threads (System.Threading.Thread, System.Threading.ThreadPool) et implicitement lors de l’utilisation des modèles de délégué asynchrones ou des méthodes BeginXXX, ainsi qu’à la gamme complète d’API qui prennent en charge la bibliothèque parallèle de tâches.
Xamarin vous recommande vivement d’utiliser la bibliothèque parallèle de tâches (TPL) pour créer des applications pour plusieurs raisons :
- Le planificateur TPL par défaut délègue l’exécution des tâches au pool de threads, qui à son tour augmente dynamiquement le nombre de threads nécessaires à mesure que le processus a lieu, tout en évitant un scénario où un trop grand nombre de threads se retrouvent en concurrence pour le temps processeur.
- Il est plus facile de penser aux opérations en termes de tâches TPL. Vous pouvez facilement les manipuler, les planifier, sérialiser leur exécution ou en lancer plusieurs en parallèle avec un ensemble complet d’API.
- Il constitue la base de la programmation avec les nouvelles extensions de langage asynchrone C#.
Le pool de threads augmente lentement le nombre de threads en fonction du nombre de cœurs de processeur disponibles sur le système, de la charge système et des demandes de votre application. Vous pouvez utiliser ce pool de threads en appelant des méthodes dans ou en System.Threading.ThreadPool utilisant la valeur par défaut System.Threading.Tasks.TaskScheduler (partie des frameworks parallèles).
En règle générale, les développeurs utilisent des threads lorsqu’ils ont besoin de créer des applications réactives et qu’ils ne veulent pas bloquer la boucle d’exécution de l’interface utilisateur main.
Développement d’applications réactives
L’accès aux éléments d’interface utilisateur doit être limité au thread qui exécute la boucle main pour votre application. Si vous souhaitez apporter des modifications à l’interface utilisateur main à partir d’un thread, vous devez mettre le code en file d’attente à l’aide de NSObject.InvokeOnMainThread, comme suit :
MyThreadedRoutine ()
{
var result = DoComputation ();
// we want to update an object that is managed by the main
// thread; To do so, we need to ensure that we only access
// this from the main thread:
InvokeOnMainThread (delegate {
label.Text = "The result is: " + result;
});
}
Le code ci-dessus appelle le code à l’intérieur du délégué dans le contexte du thread main, sans provoquer de conditions de concurrence susceptibles de bloquer votre application.
Threading et garbage collection
Au cours de l’exécution, le Objective-C runtime crée et libère des objets. Si les objets sont marqués pour « mise en production automatique », le Objective-C runtime libère ces objets dans le thread actuel NSAutoReleasePool. Xamarin.iOS crée un NSAutoRelease pool pour chaque thread à partir du System.Threading.ThreadPool thread et pour le thread main. Cette extension couvre tous les threads créés à l’aide du TaskScheduler par défaut dans System.Threading.Tasks.
Si vous créez vos propres threads à l’aide System.Threading de, vous devez fournir votre propre NSAutoRelease pool pour empêcher la fuite des données. Pour ce faire, encapsulez simplement votre thread dans le morceau de code suivant :
void MyThreadStart (object arg)
{
using (var ns = new NSAutoReleasePool ()){
// Your code goes here.
}
}
Remarque : Depuis Xamarin.iOS 5.2, vous n’avez plus besoin de fournir les vôtres NSAutoReleasePool , car un sera fourni automatiquement pour vous.