Comment réduire les temps de compilation / accélérer le temps de compilation dans Xcode?
Quelles stratégies peuvent être utilisées en général pour réduire les temps de construction pour tout projet Xcode? Je suis principalement intéressé par les stratégies spécifiques à Xcode.
Je fais du développement iPhone avec Xcode, et mon projet devient de plus en plus gros. Je trouve que les phases de compilation/liaison commencent à prendre plus de temps que je ne le souhaiterais.
Actuellement, je suis:
Utiliser des bibliothèques statiques pour que la plupart de mon code n'ait pas besoin d'être compilé à chaque fois que je nettoie et crée mon projet principal
J'ai supprimé la plupart des ressources de mon application et testé avec un chemin d'accès au système de fichiers codé en dur dans le simulateur iPhone autant que possible afin que mes ressources n'aient pas à être constamment empaquetées lorsque je les modifie.
J'ai remarqué que la phase "Vérification des dépendances" semble prendre plus de temps que je ne le souhaiterais. Des conseils pour diminuer cela seraient également appréciés!
Souvent, la plus grande chose que vous puissiez faire est de contrôler votre inclusion de fichiers d'en-tête.
L'inclusion de fichiers d'en-tête "supplémentaires" dans le code source ralentit considérablement la compilation. Cela a également tendance à augmenter le temps requis pour la vérification des dépendances.
En outre, l'utilisation de déclaration directe au lieu d'avoir des en-têtes inclut d'autres en-têtes peut réduire considérablement le nombre de dépendances et aider tous vos horaires.
J'ai écrit un article de blog détaillé sur la façon dont j'ai amélioré le cycle de développement iOS sur Spotify:
Réduction du temps d'attente de 50% à partir du cycle iOS Edit-Build-Test
Cela se résumait à:
1) Arrêtez de générer des bundles dSYM.
2) Évitez de compiler avec -O4 si vous utilisez Clang.
Personnellement, j'ai basculé le compilateur sur LLVM-Clang pour mes projets de développement Mac et j'ai vu une diminution spectaculaire des temps de construction. Il y a aussi le compilateur LLVM-GCC mais je ne suis pas sûr que cela aiderait avec les temps de construction, c'est encore quelque chose que vous pouvez essayer si LLVM-Clang ne fonctionne pas pour la compilation d'applications iPhone.
Je ne suis pas sûr à 100% que LLVM soit pris en charge pour le développement sur l'iPhone, mais je pense que je me souviens avoir lu dans un fil d'actualité que c'était le cas. Ce n'est pas une optimisation que vous pouvez implémenter dans votre code mais ça vaut le coup d'essayer!
Si vous n'utilisez pas 8 Go de RAM, mettez à niveau maintenant.
Je viens de mettre à niveau mon macbook pro de 4 Go à 8 Go. Le temps de construction de mon projet est passé de 2:10 à 0:45. J'ai été stupéfait par l'amélioration. Il rend également la navigation Web plus rapide et les performances générales de Xcode lors de l'indexation, etc.
Le nombre de threads que Xcode utilisera pour effectuer les tâches par défaut sur le même nombre de cœurs que votre CPU possède. Par exemple, un Mac avec un Intel Core i7 a deux cœurs, donc par défaut Xcode utilisera un maximum de deux threads. Comme les temps de compilation sont souvent liés aux E/S plutôt qu'aux CPU, l'augmentation du nombre de threads utilisés par Xcode peut améliorer considérablement les performances des compilations.
Essayez de configurer Xcode pour utiliser 3, 4 ou 8 threads et voyez celui qui offre les meilleures performances pour votre cas d'utilisation.
Vous pouvez définir le nombre de processus que Xcode utilise à partir du terminal comme suit:
defaults write com.Apple.Xcode PBXNumberOfParallelBuildSubtasks 4
Veuillez voir Xcode User Defaults pour plus d'informations.
Réponse simple: ajoutez une autre machine exécutant Xcode sur votre réseau local. Xcode intègre distcc pour effectuer des compilations distribuées. Il peut même utiliser Bonjour pour trouver d'autres hôtes de build, ce qui simplifie considérablement le processus de configuration. Pour les versions volumineuses, la distribution peut vous permettre d'augmenter la vitesse de manière presque proportionnellement linéaire au nombre de machines de génération (2 machines prennent la moitié du temps, trois en prennent une troisième et ainsi de suite).
Pour voir comment configurer cela, vous pouvez consulter ce document de développement . Il propose également d'autres stratégies utiles d'amélioration du temps de génération, telles que l'utilisation d'en-têtes précompilés et de générations prédictives.
Edit: Malheureusement, il apparaît Apple a supprimé cette fonctionnalité à partir de Xcode 4.3: http://lists.Apple.com/archives/xcode-users/2012/Mar/msg00048 .html
Xcode 5 a une version serveur qui peut faire du CI, mais je doute que cela confère un avantage aux versions de développeur ad hoc. Cependant, certaines fonctionnalités inopinées devraient accélérer considérablement les temps de construction.
Une astuce énorme pour réduire de moitié les temps de compilation (pour les projets iOS au moins) consiste à définir Paramètres de construction/Architectures/Créer une architecture active uniquement à OUI .
Ce que cela fait (en particulier avec l'avènement des iPads 64 bits/compilateur 64 bits) est de pas construire le binaire pour les architectures que vous n'utilisez pas actuellement.
N'oubliez pas de réactiver ce paramètre lors de la soumission à l'App Store, sinon votre binaire ne sera pas validé.
J'ai utilisé un script pour utiliser un lecteur RAM, ainsi que quelques optimisations de "déclarations avancées" mon projet clean le temps de construction est passé de 53 secondes à 20 secondes.
J'ai été tenté d'obtenir l'interface utilisateur graphique sur l'AppStore, mais j'ai préféré opter pour la ligne de commande. J'ai mis le script dans le référentiel git.
Pour voir les temps de construction, entrez ceci dans un terminal: "par défaut, écrivez com.Apple.dt.Xcode ShowBuildOperationDuration YES"
Redémarrez Xcode pour remarquer les temps de construction dans la barre d'outils. (c'est mon temps de construction non propre en utilisant objective-c) 
Ajustez le script à votre guise. - Notez que le script efface le dossier de données dérivé.
#!/bin/sh
#2 GIG RAM
GIGA_BYTES=$((2*1024*1024*1024))
# a sector is 512 bytes
NUMSECTORS=$((${GIGA_BYTES}/512))
#ram disk
mydev=`hdiutil attach -nomount ram://$NUMSECTORS`
newfs_hfs $mydev
# make mount point
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData
# *******************************************
# ** WARNING - MOUNT POINT WILL BE DELETED **
# *******************************************
rm -rf ${MOUNT_POINT}
mkdir -p ${MOUNT_POINT}
# mount
mount -t hfs $mydev ${MOUNT_POINT}
echo unmount $(MOUNT_POINT)
Pour voir l'effet et contrôler le RAM Drive:
mount - see mount points
umount mount_point - unmount point
diskutil list - see disks
diskutil eject /dev/diskX - eject the disk
df -ahl - see free space
REMARQUE: J'utilise essentiellement le hdiutil fourni par macOs. J'ai essayé d'activer l'option -kernel (pas d'échange sur le disque) mais j'ai échoué sur ma machine, disant qu'elle n'est pas implémentée.
Peut-être que le nouveau système d'exploitation arrivera bientôt, nous verrons encore plus d'améliorations car la nouvelle fonction de copie du système de fichiers est très rapide et rend peut-être ce script redondant.
Vous avez mentionné l'utilisation de bibliothèques statiques pour vos fichiers les plus utilisés pour empêcher la compilation. Vous pouvez accomplir quelque chose de similaire en mettant des en-têtes dans votre code qu'il est fréquemment utilisé mais pas dans vos bibliothèques statiques dans l'en-tête précompilé. Au moins, ils ne seront compilés qu'une seule fois.
Des précautions doivent être prises pour éviter les problèmes si vous avez plusieurs types de compilation dans votre projet (par exemple Obj-C, Obj-C++, C++).
Hé là, je vous recommanderais d'optimiser la structure physique de votre projet. Il y a une bonne lecture à ce sujet (au moins dans le monde C++), mais je fais objectif-C et les mêmes principes s'appliquent souvent.
Voici un excellent article sur l'optimisation de la structure physique du projet, qui tend à améliorer les temps de compilation Games From Within: Physical Structure Part 1
Bonne chance :)
un mot: TmpDisk
- Utilisez TmpDisk pour créer un disque de 1,5 Go RAM
- Modifiez Xcode> Préférences> Emplacement> Données dérivées en /Volumes/1.5Gb/xcode data
- Profitez de la vitesse!
Si tout votre projet est reconstruit à chaque fois que vous appuyez sur Exécuter, c'est probablement le bogue de XCode 7.0 <= 8.1 qui vous donne du fil à retordre.
La création du paramètre de construction défini par l'utilisateur HEADERMAP_USES_VFS sur YES a réduit le temps de compilation du macbook de 75 secondes à chaque fois, à 25 secondes. Voir Xcode 8 fait une reconstruction complète du projet pour plus d'informations.
Note rapide concernant l'approche "Jetez plus de matériel".
RÉSUMÉ: J'ai connu une PETITE augmentation de la vitesse en effectuant une mise à niveau matérielle SIGNIFICATIVE
Test: construire/exécuter exactement le même projet sur des macbooks clonés (où la seule différence devrait être leur matériel)
Ancien Macbook Air (1.86GHZ Core 2 Duo SEULEMENT 2 Go de RAM) vs Brand New Macbook Pro (2.3GHZ Core i7 8 Go de RAM)
CONSTRUIRE SUR IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro ~ 1: 00
=> 0 à 0:15 d'augmentation de vitesse
CONSTRUIRE SUR IPHONE 4S
Macbook Pro ~ 0: 35
Macbook Air ~ 0: 50
=> ~ 15 secondes d'augmentation de vitesse
** Partiellement testé: IL N'Y A PAS de différence significative entre les temps de construction du SIMULATEUR entre les 2 machines
. le facteur limitant était le matériel téléphonique (pas le matériel informatique).
SO .. pour obtenir le temps de construction le plus rapide ..
option1) écrire du code et l'exécuter dans le simulateur sur un ordinateur rapide OU
option 2) construire sur l'appareil avec le dernier iphone