opportunités et bénéfices de convertir un projet en ARC ?
Nacku
Membre
Bonjour,
on me demande de convertir un projet existant NON ARC en ARC.
Je voudrais savoir si c'est dangereux ? quels sont les bénéfices d'une tel conversion ? utiliser des composants externes arc ?
merci de donner vos avis
Lunack
on me demande de convertir un projet existant NON ARC en ARC.
Je voudrais savoir si c'est dangereux ? quels sont les bénéfices d'une tel conversion ? utiliser des composants externes arc ?
merci de donner vos avis
Lunack
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Xcode propose un outil de Refactoring pour convertir un projet en ARC.
L'outil est très pratique mais peut se tromper, en particulier pour les variables d'instance toutes nues, qu'il met forcément en strong, et si certaines propriétés sont mal déclarées (assign/retain). Il faudra bien tester l'appli après la conversion.
Code plus lisible, réduction drastique des erreurs de gestion mémoire.
Pour moi, le seul inconvénient est quand on travaille avec le Toll-Free Bridge Foundation; les règles deviennent alors subtiles pour préciser à ARC comment gérer la mémoire avec les objets Foundation.
On peut passer un flag au compilo pour désactiver ARC pour un fichier. Fais une recherche.
pour mettre un fichier en non arc il faut ajoute la valleur -fno-objc-arc j'espere t'avoir aider
J'en suis très content. Code beaucoup plus lisible et moins de lignes de code à maintenir.
Je n'ai pas pu faire de tests de performances.
Concrètement, je vous conseille donc de créer un projet par composant externe, projet qui va construire une librairie statique (il y a un template tout fait pour ça). Et de mettre tous ces projets de composants externes avec le projet de votre application (celui qui crée votre .app/.ipa) dans un workspace. Il suffira juste de linker les .a créé par chaque projet dans les Build Phases du projet de l'application et tout sera alors automatique ensuite (au petit hic de Xcode sur les "Relative to Build Products" près, qu'il faut penser à corriger quand on rajoute la lib, mais bon).
Gros avantages de cette solution :
Bref, ça n'a vraiment que des avantages et tout le monde devrait fonctionner comme ça. D'ailleurs c'est surtout pour cela que les workspaces ont été intégrés dans Xcode4, et ça serait un tort de s'en passer alors que ça n'apporte que du bon.
Grace à ce système, c'est très simple d'intégrer une librairie / un composant tierce à votre projet, sans risque de le polluer, sans risquer que les réglages de ce composant (ARC ou non-ARC, en particulier) ne viennent entrer en conflit avec ceux de votre application car chacun a son projet dédié, sans avoir à rajouter un flag partout sur chaque fichier de votre librairie (sinon je vous raconte pas la galère quand c'est un composant qui inclus 50 fichiers ou pire quand vous mettez à jour ce composant qui rajoute des fichiers qu'il ne faut pas oublier ou qu'il faut tous les reflaguer "-fobj-no-arc"...).
Bref, utilisez les workspaces, et des projets dédiés pour vos composants tierces (c'est comme ça que je fais sur OHAttributedLabel par exemple), ça vous épargnera bien des galères.
En français :
http://www.vtourraine.net/blog/xcode-4-workspaces
En anglais :
http://pymatics.com/2011/12/23/tutorial-develop-a-private-framework-for-your-mac-app-using-xcode-4s-workspace-feature/
Bon ce ne sont que 2 liens mais sa peut-être utile
La lisibilité du code tient compte de plusieurs principes à respecter, comme les conventions de nommage pour ne citer qu'un exemple.
Et encore une fois, ça n'est pas parce que ARC facilite la gestion mémoire qu'il faut éviter le sujet. Je considère que c'est une erreur de se mettre à ARC sans avoir une bonne connaissance de la gestion mémoire.
Le danger d'ARC c'est de se dire "oh c'est cool ARC gère la mémoire pour moi j'ai pas besoin de comprendre comment ça marche".
Ca serait votre plus grosse erreur de vous dire ça.
ARC facilite la gestion de la mémoire car il gère pour vous les retain/release. Mais ça ne vous dispense en aucun cas de comprendre les principes de gestion mémoire de Cocoa, en particulier les principes d'ownership (et donc les conséquences de choisir "weak" ou "strong" pour une politique mémoire d'une variable ou d'une propriété), ou les cas de retain cycle et comment les éviter...
Tout ça est toujours d'actualité même avec ARC, même plus encore, car ARC gérant les retain/release, ces cas-là deviennent plus subtils / moins flagrants qu'avec la gestion manuelle de la mémoire.
En convertissant mon projet, j'ai bien vu où j'ai dû mettre du strong et non du weak sur certains outlets et sur certaines vues.
C'est intéressant.