J’ai lu de nombreux articles d’introduction sur la mise à jour de l’interface principale dans le fil de discussion en arrière-plan, et la plupart utilisent Control.Invoke et Control.BeginInvoke. Ce sont de bonnes solutions, mais il y a deux problèmes :
1. Vous devez référencer System.Windows.Forms, puis utiliser System.Windows.Forms
2. La structure du code est relativement désordonnée. (En fait, c’est aussi causé par #1)
Microsoft propose une autre solution plus élégante, à savoir System.Threading. SynchronizationContext。 Comme vous pouvez le voir, il n’est pas dans namesapce System.Windows.Forms, donc nous pouvons l’utiliser légitimement dans BusinessLaryer, Controler, et même dans les modules.
Et il est très pratique à utiliser, vous n’avez besoin de vous concentrer que sur les deux méthodes suivantes :
1. Envoyer : envoie une requête de mise à jour d’interface au thread principal, bloquant le thread courant jusqu’à son retour.
2. Post : Envoie une demande de mise à jour d’interface au thread principal sans bloquer le thread actuel.
En fait, ils sont tous la même méthode, sauf que l’envoi est synchrone et le post est asynchrone
Avant Form1 form = new Form1(), l’objet SynchronizationContext était vide, et lorsque le formulaire Form1 était instancié, l’objet SynchronizationContext était ajouté à ce thread. La réponse est donc que lorsque l’objet Control est créé, l’objet SynchronizationContext est également créé et attaché au thread. Tous lorsqu’ils utilisent la forme InitializeComponent() ; Une fois cela fait, il peut obtenir un objet qui n’est pas NULL
Enfin, la différence entre les méthodes Sendt() et Post() de SynchronizationContext :
Send() est implémenté simplement en appelant le délégué sur le thread courant (appel synchrone). C’est-à-dire que le thread UI est appelé directement sur le sous-thread pour être exécuté, et le sous-thread continue de s’exécuter après la fin de l’exécution du thread UI.
Post() est implémenté en appelant un délégué sur le pool de threads (appel asynchrone). C’est parce que le sous-thread trouvera un thread du pool de threads pour régler le thread UI, et le sous-thread exécutera directement son propre code sans attendre que le thread UI se termine.
Code de test :
Résultat:
Fil principal de l’interface utilisateur : 1
Fil : 5
SynchContext :1
Résumé:L’objet SynchronizationContext sur le thread UI, qu’il soit appelé sur le thread principal ou dans le thread, sera exécuté sur le thread principal, donc lorsqu’il y a beaucoup de code chronophage, cela provoquera un gel ou une disparition simulée de l’interface UI！
En faitLe thread UI n’utilise pas la classe SynchronizationContext, mais WindowsFormsSynchronizationContextCe Dongdong.
Code-source System.Threading.SynchronizationContext :
Code-source WindowsFormsSynchronizationContext :
|
Publié sur 15/03/2018 11:51:07
|
|
|
|
