Je me demande s'il y a une raison d'utiliser l'une par rapport à l'autre dans les observations KVO vs NSNotificationCenter. Performance, utilisation de la mémoire, vitesse, etc?observation KVO vs NSNotificationCenter observation
Les deux ne sont pas toujours interchangeables. Conceptuellement, KVO est seulement pour observer une propriété d'un objet. Par exemple, vous ne pouvez pas utiliser KVO pour remplacer NSApplicationWillTerminateNotification car il informe les observateurs qu'un événement se produit et non un changement de propriété d'un objet. En ce qui concerne les performances et l'utilisation de la mémoire, ils sont à la fois rapides et utilisent une mémoire négligeable. NSNotificationQueue a fusionné pour arrêter les inondations de notifications. KVO n'a pas de coalescence pour autant que je sache, ce qui a causé des problèmes de performance pour moi à un moment donné. J'observais des centaines d'objets, et quand une mise à jour par lots arrivait à ces objets, je recevais des centaines de rappels KVO. Ce n'était pas un problème de performance avec KVO lui-même, mais avec mon propre code exécuté à la suite de la mise à jour par lots.
La performance n'est pas vraiment le problème, c'est plus sur le meilleur ajustement pour le problème. Si c'est un changement de propriété, utilisez KVO. S'il ne s'agit pas d'un changement de propriété, utilisez un délégué ou une notification selon que vous avez besoin d'un seul observateur ou de plusieurs observateurs.
Une question très ancienne, mais pensé à ajouter quelques points. Je suis d'accord avec Tom Dalling's answer, cependant, il existe de nombreux scénarios dans les grandes applications où nous avons tendance à ajouter un observateur pour une propriété d'un objet et nous ne pouvons pas, ou, nous manquons de les retirer de la liste des observateurs. Considérons le scénario suivant de mon application - Un ViewController affiche un objet snake, j'observe un changement de propriété sur cet objet - "venom". Donc, à chaque fois que viewController devait afficher un serpent différent, je supprimais simplement le contrôleur de vue de l'observateur de cet objet serpent.
L'application a évolué pour afficher une liste de serpents au lieu d'un seul serpent, ce qui signifie que j'ai dû observer la propriété de tous les serpents dans cet objet. Maintenant, quand un ancien serpent est retiré du tableau je devrais apprendre à connaître cet événement afin que je puisse enlever le contrôleur de vue en tant qu'observateur de cet objet de serpent. Pour ce faire, je dois d'abord observer les changements sur le tableau lui-même. Pour ce faire, je dois suivre un protocole particulier pour insérer des objets dans le tableau et les retirer du tableau. De cette façon, la complexité augmente. Nous connaissons tous les conséquences de ne pas supprimer un observateur d'un objet et si cet objet est libéré par l'OS!
Au-dessus est un exemple à citer, le principal problème ici est Je ne peux pas obtenir la liste des observateurs KVO pour un objet donné pour les supprimer des observateurs avant cet objet est libéré - Ceci peut être facilement atteint par NSNotification et NSNotificationCenter. À certains moments, j'ai tendance à utiliser NSNotification par rapport à KVO, cependant, KVO a toujours un avantage sur la notification en termes de bonnes pratiques de conception.
Ah. Je ne connaissais pas l'agrégation des notifications. C'est une chose assez importante pour moi. – David
Les notifications sont mieux utilisées lorsqu'aucun objet n'est nécessaire pour connaître un autre objet spécifique. Par exemple, vous souhaiterez peut-être actualiser un ensemble de vues si certaines modifications sont apportées à votre application et que, dans le cas des notifications, ces vues n'ont aucune connaissance de l'objet qui gère les paramètres, ce qui préserve MVC. –