Je sais que Apple recommande officiellement Uikit d'être utilisé dans le fil principal uniquement. Cependant, j'ai également entendu dire que UiImage est en sécurité depuis IOS 4.0. Je ne trouve aucune documentation soutenant cette réclamation.
Quelqu'un a-t-il des informations pour soutenir cette réclamation? En tant que classe utilisée pour stocker des données et décoder les données d'image, UIIMAGE doit être du thread-Safe si bien conçu.
6 Réponses :
Il est vrai que Apple recommande d'utiliser des éléments de l'uikit sur le fil principal:
Remarque: Pour la plupart, les classes Uikit ne doivent être utilisées que d'un Le fil principal de l'application. Ceci est particulièrement vrai pour les cours dérivé de l'uiresponder ou qui implique de manipuler votre Interface utilisateur de l'application de quelque manière que ce soit.
Puisque l'uiimage n'est pas dérivé de l'uiresponder, et vous ne l'affichez pas réellement sur l'interface / l'écran. Ensuite, faire des opérations avec des uiimages sur un autre thread doit être sûr.
Ceci est toutefois basé sur mon expérience, je n'ai vu aucune documentation officielle à ce sujet.
Il est beaucoup plus sûr de fonctionner sur un CGIMAGE, FYI.
Ah oui, mais il est assez facile de convertir entre les deux, de sorte que ce n'est pas tout de suite.
Des trucs sont soit à la sécurité du fil, soit ce n'est pas le cas. CCIMAGE n'est ni plus ni moins de fil à la sécurité de l'uImage. L'extrait n'est pas non plus cité ci-dessus une garantie de sécurité de thread-sécurité pour l'uImage. Cela conseille fortement de ne pas violer les cours dérivés de l'uireponder, mais ne dit rien de ce que l'UIMAGE. Ne supposez pas que c'est sûr parce que ce n'est pas un répondeur. Quoi de neuf pour iOS 4 Docs, D'autre part, mentionnez que le dessin des uiimages et le dessin sur des uiimages sont du thread-Safe de 4.0 en hausse. Alors, attira!
Je veux accepter le commentaire de Jorgann. C'est exactement ce que je cherche.
dans le Quoi de neuf dans iOS: iOS 4.0 Notes de publication, les améliorations du cadre Uikit incluent ce bit:
Dessin à un contexte graphique dans Uikit est maintenant de fil-coffre-fort. Spécifiquement: les routines utilisées pour accéder et manipuler les graphiques le contexte peut maintenant gérer correctement les contextes résidant sur différents fils. La chaîne et le dessin d'image sont maintenant thread-coffre-fort. En utilisant la couleur et Les objets de police dans plusieurs threads sont maintenant prudents à faire.
SO UIIMAGE est le fil-en sécurité sur iOS 4.0 et ultérieurement.
Cette déclaration n'implique pas que l'uIimage est en sécurité de quelque manière que ce soit. Il dit simplement que le dessin d'une image dans un contexte est le fil sûr.
Juste pour le faire court: UiImage n'est pas sûr du fil ou mieux ne fonctionne que sur le fil principal, Comme je l'ai expérimenté dans mon courant après quelques débogage.
J'espère que cela aide. Je souhaite avoir plus de clarté à ce sujet d'Apple Ou même mieux une classe d'uiimage, cela pourrait être rendu dans un fil différent. Ne devrait pas être trop difficile ...
EDIT: Après quelques recherches, j'ai constaté que c'est "uigraphiquegetimagefromCurrentImagecontextextextex ();" cela provoque le problème. C'est un peu sur le sujet, mais peut-être que cela aide: https://coderwall.com/p/9J5DCA
Merci à Zachary Waldowski.
N'est plus vrai (voir la réponse d'Eric Goldberg)
UiImage est et a toujours été une classe immuable; L'image que les références informatiques ne peuvent pas être mutées. Cela en fait 100% de fil de sécurité.
directement à partir de La documentation d'Apple pour UiImage
Les objets d'image sont immuables, vous ne pouvez donc pas modifier leurs propriétés après la création. Cela signifie que vous spécifiez généralement les propriétés d'une image au moment de l'initialisation ou comptez sur les métadonnées de l'image pour fournir la valeur de la propriété. signifie également que les objets d'image sont eux-mêmes sûrs à utiliser à partir de n'importe quel thread. La manière dont vous modifiez les propriétés d'un objet d'image existant consiste à utiliser l'une des méthodes de commodité disponibles pour créer une copie de l'image mais avec la valeur personnalisée que vous voulez.
(mettre l'accent sur le mien)
Donc au moins dans la version actuelle du SDK à compter du 13 mai 2014, "Les objets d'image sont eux-mêmes sans danger à partir de n'importe quel fil"
C'est la vraie réponse
"À utiliser", comprend-il les rendre? (initialiseurs)
Je le penserais, mais je vous encourage à vérifier cela.
@Eonil - On dirait qu'il peut y avoir des mises en garde, car le projet Afnetworking a trouvé lors de l'initialisation de nombreux uIimages de différents threads spécifiquement avec imageWithData: . Voir ici: Github.com/afnetworking/afnetworking/Pull/2860
@Ericgoldberg Je n'indiquais que l'appelant UIIMAGE à partir de plusieurs threads et j'ai maintenant un indice de plus. Merci.
Je ressens également des problèmes liés à l'initialisation et j'ai créé un fil séparé pour cela: Stackoverflow.com/Questtions/40636521/...
Le fil-coffre-fort n'est pas le problème, dans lequel aucun thread peut tenter d'accéder à un contexte en même temps (simultanément). Et, bien que cela soit généralement bien, dans des situations à faible mémoire, comme avec une extension d'édition de photos sur des périphériques iOS, deux threads accédant à un contexte peuvent planter une application en raison de la mémoire faible.
Cela se produit lors du mélange de filtres d'image centrale avec des opérations de Vimage. Les deux sont du thread-coffre-fort, mais Arc ne libérera pas les données de tampon de Vimage avant de traiter un objet d'image centrale, vous en avez donc à un moment donné deux copies d'une image en mémoire.
En conséquence, vous ne considérez jamais votre connaissance de la sécurité du thread pour être complète sans compréhension du filetage et de la concurrence - et cela va au double de toute réponse aux questions sur la sécurité des threads. En bref: la question appropriée est que la sécurité de thread-sécurité s'applique à l'utilisation de la mémoire, chaque fois que vous parlez de traitement de l'image?
Si vous ne faites que des coups de pied aux pneus ici, vous devez attendre de poser votre question jusqu'à ce que vous ayez rencontré un vrai problème. Mais si vous planifiez votre prochain déménagement, vous devez savoir comment exécuter des commandes de traitement d'image séquentiellement et avec une distribution manuelle. Vous devez concevoir votre application afin qu'il n'y ait qu'une seule copie de l'image en cours de traitement en mémoire. Ne comptez jamais sur la distribution automatique-thread-coffre-fort ou ne pas faire cet appel à votre appel. Cela ne fonctionnera pas.
Si vous voulez voter une réponse de travail, demandez à la GRUMBA de dire pourquoi. Sniping derrière une cape ne digne que d'un Pah-tak!
On dirait que Apple a mis à jour leur documentation puisque les réponses précédentes ici ont été publiées. Selon la documentation la plus récente, il est prudent de créer et d'utiliser des instances uiimage à partir de tout thread:
Parce que les objets d'image sont immuables, vous ne pouvez pas changer leur Propriétés après la création. La plupart des propriétés d'image sont définies automatiquement Utilisation de métadonnées dans le fichier d'image d'accompagnement ou les données d'image. le nature immuable des objets d'image signifie également qu'ils sont
sûrs à Créez et utilisez à partir de n'importe quel fil .
C'est actuellement la réponse plus simple et correcte, merci à @arda.
BTW, voici un gardien pour toujours vérifier l'accès principal du fil à Uikit: gist.github.com/steipète/5664345