Considérez l'affaire suivante:
Main Thread -----UIView info \ --------------------------------------- / Button Updated ------
\ (Some Event) / (Some Event)
\ /
BG Thread ---------------------Validate UIView info-----Update Button------------------------
4 Réponses :
Vous ne pouvez pas et ne doit jamais bloquer le fil principal. Si vous le faites, l'interface gelera et, si le blocage dure trop longtemps, le processus de surveillance va tuer votre application morte avant les yeux de l'utilisateur.
Vous pouvez donner à l'utilisateur un sens que quelque chose se passe et décourage l'utilisateur de faire quoi que ce soit, par, éteindre, éteindre l'interaction de l'utilisateur et mettre en place une fileuse. Mais en général, oui, la multithreading est difficile; Vous devez être préparé pour la possibilité que vous revenez sur le fil principal lorsque l'application a changé d'état.
Merci @matt - apprécie vraiment vous regarder cette question. Le retard ne sera jamais sur une seconde. C'est plus pour la validation interne.
Dans ce cas, l'interface temporaire affichant un spinner ressemble à une bonne solution. Le but de ma réponse est simplement de vous décourager de vous supposer que vous pouvez en quelque sorte garantir l'état de l'application lorsque vous laissez le fil principal et y retourner plus tard. Vous ne pouvez jamais faire ça; Votre application est Evénement entraînée , ce qui signifie que des trucs sont libres de se produire chaque fois que votre code de thread principal ne fonctionne pas. Il faut apprendre à penser à ces termes.
Votre bouton ne doit pas être mis à jour en arrière-plan. Vous devez toujours modifier les composants uikit sur le fil principal.
Vous ne devez également jamais bloquer le fil principal, ce que vous recherchez est le spectacle à l'utilisateur une indication qu'un processus d'arrière-plan est actif. "UiactivitéIndicatorview" pourrait être une bonne chose à montrer à l'utilisateur, vous pouvez également désactiver l'interaction utilisateur sur la vue pour empêcher que l'utilisateur de toucher quoi que ce soit s'il est essentiel d'attendre que l'opération soit complète mais non recommandée.
Le délai n'est jamais pendant plus d'une seconde - c'est principalement pour le traitement interne.
Plutôt que de bloquer un thread principal, désactivez les commandes d'entrée utilisateur à votre vue jusqu'à ce que la validation soit terminée, puis réactivez-les.
Il serait également logique d'ajouter un indicateur d'activité avec des peaux de protection élevées. Il montrera à l'utilisateur qu'il existe des travaux d'arrière-plan en cours si vous le démarrez lorsque le travail de fond commence et l'arrêtez lorsque la validation est terminée.
S'il y a une chance, le processus d'arrière-plan pourrait suspendre ou prendre plus de temps, par ex. Si cela fait une demande de réseau, vous pouvez afficher / activer un bouton Annuler et un moyen de le terminer.
Affichage des indicateurs d'activité et éventuellement fournissant un bouton Annuler tant besoin que le thread principal continue à fonctionner, donc ne le bloque pas!
Oui, vous ne devez jamais bloquer le fil principal et mettre à jour UI uniquement sur le fil principal.
Cela dit - montrez un indicateur de fileur / d'activité en fonction de l'arrière-plan.
Pensez attentivement à propos de l'interface utilisateur et par exemple. présentez quelque chose afin que l'utilisateur ne puisse pas changer quelque chose pendant que vous êtes occupé avec E.G. dialogue ou collant ou quelque chose comme ça.
En pratique, cela devient souvent plus une question d'UX que de bloquer.
Comme d'autres l'ont dit, vous ne «bloquer» le fil principal. Si nécessaire, tandis que le processus ASYNC est en cours, vous pouvez temporairement (a) désactiver l'interaction utilisateur; et / ou (b) montrent une indication visuelle que le processus ASYNC est en cours et réactive quand cela est fait.