2010-02-26 13 views
3

J'ai une classe personnalisée que j'utilise fréquemment sur mes projets. Cette classe a plusieurs méthodes mais toutes ne sont pas utilisées dans tous les projets.iPhone et iPad - y compris une classe augmentera binaire?

Ma question est la suivante: inclure cette classe sur un projet va gonfler le projet avec du code inutile ou est-ce que le compilateur va juste inclure les méthodes utilisées? Je veux dire, si ma classe a 30 méthodes mais seulement 4 sont utilisées dans un projet donné, le compilateur inclura-t-il aussi les autres 26 non utilisées ou seulement les 4 utilisées dans le produit final?

Dans le cas où il inclut tout, y a-t-il un moyen de forcer à ne pas tenir compte des méthodes inutilisées et à réduire au minimum le binaire?

Répondre

4

L'éditeur de liens prend en charge dead-stripping, si vous l'allumez sur du code inutilisé ne devrait pas causer de ballonnement.

De l'Apple docs:

Le segment de liaison statique (ld) supporte le retrait de codes non utilisés et des blocs de données de fichiers exécutables. Ce processus (connu sous le nom de suppression de code mort) aide à réduire la taille globale des exécutables , ce qui à son tour améliore les performances en réduisant la mémoire empreinte de l'exécutable. Il permet également aux programmes de lier avec succès lorsque le code inutilisé fait référence à un symbole non défini (au lieu de résultant dans une erreur de liaison).

L'effacement du code mort n'est pas limité à en supprimant uniquement les fonctions inutilisées et le code exécutable d'un binaire. L'éditeur de liens supprime également les symboles non utilisés et les données qui résident dans les blocs de données. De tels symboles peuvent inclure des variables globales , des variables statiques et des données de chaîne, entre autres.

lors du décapage mort code est activé, les recherches de l'éditeur de liens statiques pour le code qui est injoignable à partir d'un initial ensemble de symboles et de blocs en direct.

+0

merci !!!!!!!!!! – SpaceDog

+2

Pour être précis, je ne suis pas sûr que cela soit correct avec Objective-C. Comme il s'agit d'un langage dynamique, les méthodes peuvent être appelées par leur nom. Ainsi, l'éditeur de liens ne sait pas quoi retirer et quoi conserver. –

+0

Fonctionne des merveilles pour moi! http://is.gd/bP8Do (developer.apple.com) –

4

Si les 26 autres méthodes ont du code dans @implementation, alors oui, elles seront utilisées dans le produit final.

La raison en est à cause du système d'exécution. Même si vous n'avez pas utilisé ces 26 méthodes lors de la compilation, il n'y a aucune garantie qu'elles ne seront pas référencées en cours d'exécution (rappelez-vous les codes NSSelectorFromString et -performSelector:).

Je ne sais pas s'il existe un moyen de forcer la suppression de ces codes. (-dead_strip ne fonctionne pas.)

+1

C'est ce que je pensais à l'origine aussi. jessecurry m'a fait douter de lui. –

+0

@jesse: Non non non, c'est l'inverse. Ce code ObjC n'est jamais supprimé, même si vous ajoutez '__attribute __ ((unused))' (qui est ignoré.) – kennytm

1

Ma question est: y compris cette classe sur un projet va enfler le projet avec le code inutile ou sera le compilateur Il suffit d'inclure les méthodes utilisées?

Je pense que vous parlez d'inclure l'en-tête et la mise en œuvre de votre classe d'assistance. Cela augmentera la taille binaire.Comme indiqué par jessecurry, le linker supporte l'effeuillage. C'est mauvais car il y a toujours la possibilité que quelqu'un veuille se lier avec l'API publique de votre binaire (heureusement ce n'est pas le cas car le lien dynamique n'est pas autorisé sur iphone mais considère les autres plateformes). Mais je parie que la différence de taille est trop marginale pour être significative.

Le plus gros impact en termes de taille est généralement les ressources que vous incluez dans votre application (images, chaînes, etc.).

2

On dirait que vous avez besoin de refactoriser et de renommer la grande classe mamma gros.

+0

Félicitations pour une réponse qui a vraiment du sens. Il n'y a pas de raison pour une classe grosse grosse maman en Objective-C. Les bibliothèques sont trop faciles à mincir et à inclure dans le fichier .pch lorsque cela est nécessaire pour utiliser des classes de gros-gros-maman plus. – Jann