On m’a interrogé récemment sur la libération de la mémoire des objets en silverlight. Je vais essayer de synthétiser ici ce que j’ai répondu.
Silverlight réagi exactement de la même manière que le framework .Net. La mémoire est gérée par un garbage collector (ramasse-miettes) qui libère les allocations mémoires des objets une fois qu’ils ne sont plus référencés.
L’application de test
Voila le principe de mon application de test. Au clic sur un bouton, mon application ajoute un usercontrol dans l’arbre visuel et au clic sur un autre bouton, je l’enlève. La seule référence vers mon contrôle est faite par l’arbre graphique. Dans le constructeur de mon usercontrol, j’incrémente un compteur qui m’indique le nombre d’instances en cours et dans le destructeur je le décrémente. Ce compteur est affiché par binding dans l’interface graphique.
Petite parenthèse pour le fonctionnement de l’application, la destruction des objets ne se passe pas dans le thread graphique, pour que la mise a jour du binding fonctionne, je lève l’événement PropertyChanged de AppController par le SynchronizationContext récupéré du thread graphique.
Contrôle sans références
A l’ajout de mon usercontrol, on note bien l’incrémentation du compteur.
Je clic sur le bouton Remove et je vois que mon compteur est toujours à 1. Le garbage collector ne passe pas tout de suite. Il y a un algorithme qui détermine quand le garbage collector doit passer sur les objets. Pour le besoin de mon application, je vais forcer l’appel au garbage collector au clic sur le bouton Force GC. Il faut noter que c’est une mauvaise pratique que de vouloir appeler soit même de garbage collector. GC.Collect() ne doit être appelée que si vous en avez réellement l’utilité. Un appel trop fréquent peut dégrader les performances de votre application.
Le clic sur Force GC ramène bien le compte de référence à 0.
Contrôle s’abonnant à un événement
Comme je vous le précisait dans le fonctionnement de mon application, je ne maintient aucune référence vers mes usercontrol, je n’ai théoriquement rien qui va empêcher le garbage collector de passer. Cependant le contrôle lui même peut faire qu’il ne sera pas libéré. Ici ma classe AppController fourni un événement auquel mes contrôles peuvent s’abonner. MyControl2 va s’abonner à cet événement. Au clic sur le bouton Raise Test event, vous verez que la couleur du usercontrol change.
Si vous ajoutez le usercontrol MyControl2, que vous l’enlevez et que vous forcez le garbage collector, vous verrez que l’instance ne se libère pas. Que se passe-t-il ?
Lorsque le contrôle s’est abonné à l’événement de AppController, il a créé un EventHandler (une référence vers une fonction) et l’a ajouté à la liste des fonctions à appeler lorsque l’événement est levé. Un événement n’est rien d’autre qu’une liste de références qui pointe vers les fonctions à appeler. Pour que notre contrôle se libère, il faut donc supprimer cette référence. Un clic sur Clear Test event list demande à AppController de vider sa liste d’événement, un clic sur Force GC remettra les compteurs à 0.
IDisposable
Une bonne pratique pour gérer la libération de ressources internes et le désabonnement d’évenement est d’implémenter l’interface IDisposable. Cette interface vous demande d’implémenter la fonction Dispose dans laquelle vous pouvez remettre à null les références externes, vous désabonnez d’événements, etc…
Le usercontrol MyControl3 implémente cette interface. Lorsque le bouton Remove First Item est cliqué, mon application vérifie si le contrôle à enlever implémente IDisposable et l’appel le cas échéant.
Les clics successifs sur Add MyControl3, Remove First Item et Force GC incrémentent et décrémentent bien notre compteur de références.
WeakReference et proxy d’événement
Si vous ne maitrisez pas la logique d’ajout suppression des contrôles, vous ne pouvez pas toujours appeler la IDisposable.Dispose. (A noter que ce n’est pas parce qu’un contrôle n’est plus dans l’arbre d’affichage qu’il faut nécessairement le disposer. Un tabcontrol ajoute et enlève chaque tab de l’abre graphique.)
La classe WeakReference permet de maintenir une référence “qui ne compte pas” du point de vue du garbage collector. La propriété Target de la WeakReference vaut null quand le garbage collector est passé et renvoi l’instance de l’objet sinon.
Ici pour gérer notre abonnement à l’événement, nous allons utiliser ces WeakReference pour pouvoir quand même être libéré. La fonction à appeler en retour de l’événement est : MyControl4.Instance_TestEvent. Cette fonction est privée. WeakListener est une classe interne à MyControl4 et va donc pouvoir appeler cette fonction privée. C’est WeakListener.Instance_TestEvent que nous allons abonner à l’événement de AppController. Lors de l’appel de l’événement, elle va vérifier que sa WeakReference vers MyControl4 est toujours valide, si tel est le cas, cette fonction va transmettre l’appel vers la fonction MyControl4.Instance_TestEvent, sinon elle se désabonne de l’appelant et pourra donc aussi être collecté par le garbage collector.
public partial class MyControl4 : UserControl
{
private class WeakListener
{
public WeakListener(MyControl4 target)
{
weakReference = new WeakReference(target);
}
private readonly WeakReference weakReference;
public void Instance_TestEvent(object sender, EventArgs e)
{
MyControl4 ctrl = (MyControl4)weakReference.Target;
if (ctrl != null)
{
ctrl.Instance_TestEvent(sender, e);
}
else
{
((AppController)sender).TestEvent -= this.Instance_TestEvent;
}
}
}
void Instance_TestEvent(object sender, EventArgs e)
{
this.LayoutRoot.Background = new SolidColorBrush(GetRandomColor());
}
…
}
Un clic sur Add MyControl4, Remove et Force GC vous donnera un compte de référence de MyControl4 à 0. Il faut noter qu’à ce stade, MyControl4 a été libéré mais le WeakListener est toujours présent en mémoire. Sa libération ne sera effectué que lorsque l’événement sera appelé, la classe s’autodésabonnera toute seule de l’événement et pourra est collectée.
WeakEventList
J’ai ajouté dans slextensions une WeakEventList permettant de gérer une liste d’événements basés sur des WeakReference. A la place de stocker les événements par le processus standard de .Net, nous créons une liste de WeakReference directement sur les delegates abonnés.
Voila la déclaration de l’événement de ma class AppController.
private WeakEventList<EventArgs> weakTestEvent;
private event EventHandler<EventArgs> testEvent;
public event EventHandler<EventArgs> TestEvent
{
add
{
if(UseWeakEvent)
{
weakTestEvent.Event += value;
}
else
{
testEvent += value;
}
}
remove
{
if (UseWeakEvent)
{
weakTestEvent.Event -= value;
}
else
{
testEvent -= value;
}
}
}
En cochant la case UseWeakEvent et en reproduisant le cas qui posait problème au début de ce post ( Add MyControl2, Remove, Force GC), on voit que la référence est bien libérée.
Vous trouvez plusieurs autres manières de créer des “weakevent” sur internet. Celle-ci est la seule qui marche en silverlight pour des appels à des fonctions privées. De nombreuses utilisent la réflexion pour pouvoir accéder à la fonction finale à appeler par l’événement, ceci n’est pas permit en silverlight si la déclaration est privée. Le mode MediumTrust de silverlight nous en empêche.