J'ai développé une application iPhone qui devrait prendre en charge iOS4 et iPad iPad basé sur iOS5.
Mon application fuit la mémoire à peu d'endroits qui deviennent difficiles à déboger en raison de la taille du code. J'ai récemment lu sur l'arc (comptage de référence automatique), ma requête est
Dois-je modifier mon code source (conserver / relâcher / alloc / distributeur) pour compiler avec ARC. De plus, quels changements nous devons effectuer à l'aide d'ARC?
est-il conseillé de passer à l'arc?
Mon application fonctionne sur le téléphone iOS4 si j'utilise arc
merci.
3 Réponses :
Ce n'est probablement pas le meilleur endroit où vous avez posté cette question, mais je vais répondre car cela ne vous dérange pas que la question soit ici.
http://developer.apple.com /Library/mac/#releasEnotes/objectivec/rn-transitioningtOarc/_index.html
Vous utiliserez l'outil de migration 'Edit> Refactor> Convertir en Arc Objective-C' et réparer tout ce que l'outil ne peut pas comprendre.
oui.
Oui, mais la mise à zéro de faibles références ne sera pas.
Une autre considération est que de nombreuses bibliothèques tiers n'ont pas encore de bonnes versions de l'arc. Cela me permet de mettre à niveau certains de mes projets existants.
Vous pouvez exclure sélectivement n'importe quel fichier source d'Arc lorsque vous exécutez la conversion. Il suffit de cocher des fichiers de classe tiers dans la phase de contrôle de la conférence de conversion de l'ARC et il les sautera et les marquez avec -fno-objc-arc afin qu'ils soient exclus de la validation de l'arc. C'est l'une des meilleures caractéristiques de l'arc - que vous pouvez mélanger et assortir des fichiers arc et non arc dans le même projet.
Je pense certainement que c'est bon pour les programmeurs de comprendre la gestion de la mémoire et comment le système fonctionne réellement ... mais je pense que Arc est un très bon système et fonctionne vraiment bien. C'est vraiment une question d'opinion, alors mon opinion est que cela vaut presque toujours la peine de commencer de nouveaux projets qui vont cibler les applications iOS 5 sur ARC, sauf dans des circonstances très spécifiques.
Je pense que si vous utilisez beaucoup de bibliothèques C dans votre code, ARC est un peu plus difficile à utiliser pour le moment (donc si vous utilisez principalement des bibliothèques C tiers et des choses comme la quart de fondation, vous pourriez Considérez si cela a du sens ou non), mais même à ce moment-là, si ces bibliothèques sont principalement isolées à partir de vos contrôleurs de l'objectif-C et que de tels arcs sont toujours bons.
Pour les applications plus anciennes, vous devez consulter votre utilisation de l'application et vos modèles. Si vous utilisez beaucoup de méthodes de délégation, car vous ne pouvez pas utiliser de faibles références sur iOS 4, cela devient un peu plus délicat et vous devrez probablement avoir un code mixte de l'arc et des non-arc. Il pourrait être préférable de prendre une décision de conception d'avancer avec l'arc. Donc, de nouvelles fonctionnalités sont conçues pour iOS 5 et peut-être non disponibles (ou entièrement disponibles) dans la version IOS 4 de l'application, et celles utilisent ARC.
Vraiment, à la fin, cela dépendra de la manière dont votre application est déjà conçue, à quel point il est grand et à quel point vous êtes confortable avec la gestion de la mémoire gérée et l'utilisation / restrictions d'arc. Par exemple, j'ai trois projets que je ne convertitais jamais en arc, celui que je suis mélangé en ce moment, il est entièrement converti (mais cible toujours IOS 4+) et 2 qui sont pleins d'arc et d'iOS 5+ seulement.
OpenGL est techniquement une API C, mais sans aucune sorte de rétention d'objet direct n'est donc pas nécessaire que les «ponts»; Tous les objets sont internes et opaques et accessibles via des fonctions et des ID entier. Néanmoins, y a-t-il quelque chose à conscience de l'utilisation de OpenGL dans le code ARC Obj-C?
Pour être clair, tandis que vous ne pouvez pas utiliser ARC faibles références si vous ciblez iOS 4, vous peut toujours utiliser En utilisant dangereux_unéré , qui est essentiellement l'équivalent de l'utilisation de Attribuer pour les propriétés d'objet. Cela signifie que vous pouvez convertir tout code non-arc bien écrit en arc sans création accidentelle de cycles de retenue sur iOS 4.
dangereux_unéré Vous perdez la fonction Auto-Null de faibles références, mais vous obtenez toujours tous les autres avantages de l'arc, tels que ne pas avoir à craindre d'oublier de libérer des ivars dans votre distributeur déclarations, etc.
Je suggère de faire cette question une entrée de wiki ... C'est certainement une bonne question et définitivement la programmation liée, mais la majeure partie de la question est vraiment d'opinion et liée à des circonstances spécifiques.
Vous demandez trois questions différentes ici. La seconde est couverte par iOS 5 meilleures pratiques (libération / conserver?) , et le troisième par si convertir le projet à Comptage automatique de référence (ARC), est-il toujours en contact sur iOS 3.x, 4.x?