Ce n'est PAS un problème bêta. Je suis sur Xcode 6.0.1, version de production. Le problème que je rencontre est que lorsque j'essaie de créer ou d'exécuter le code sur lequel je travaille, Xcode ne répond plus pendant de longues périodes et le SourceKitService consomme plus de 400% du processeur (selon Activity Monitor). Ce problème est nouveau depuis quelques jours, même si, curieusement, j'étais sur Xcode 6.0 depuis sa sortie officielle le 17 septembre. J'ai mis à niveau vers 6.0.1 en espérant qu'il contiendrait un correctif pour ce problème.

Une idée de ce que pourrait être le problème?

Ran dans ce problème avec Xcode 6.1.1 plus tôt cet après-midi (pas bêta, version officielle publiée). J'avais exécuté du code sur Playground et je soupçonnais que c'était la cause. Le processeur a été indexé à près de 100% et Xcode n'a pas pu terminer les builds.

Alors voici ce que j'ai fait:

1. Ouverture du "Moniteur d'activité", qui montrait SourceKitService comme le principal processeur du processeur.

2. Dans "Moniteur d'activité", double-cliquez sur le SourceKitService et cliquez sur la section "Ouvrir les fichiers et les ports", qui montrait qu'il travaillait sur des fichiers sous le répertoire / Users / myname / Library / Developer / Xcode / DerivedData / ModuleCache / pour un dossier spécifique.

3. Supprimé le dossier spécifié (à partir d'une ligne de commande, en utilisant rm -rf). Le cache est régénéré en fonction de Puis-je supprimer en toute sécurité le contenu du dossier de données dérivées de Xcode? .

4. En utilisant à nouveau Activity Monitor, forcez la fermeture de SourceKitServer. J'ai vu le signe maintenant trop familier dans Xcode indiquant que SourceKitService s'était écrasé (c'est pourquoi SourceKitService semblait familier!).

5. Répétez l'étape 3.

Le Mac est encore une fois paisible. Aucune donnée n'a été perdue et Xcode n'a même pas eu besoin d'être redémarré (ce que j'avais essayé sans succès). L'essentiel est que ModuleCache semble obtenir SourceKitService dans une boucle et que la suppression du dossier semble le corriger. J'espère que cela fonctionne pour vous aussi.

Note de démarrage:

À propos, la cause du problème de SourceKitService était que j'avais une déclaration de tableau trop longue dans ma classe Swift. J'ai eu plus de 200 entrées dans un tableau. Réduit à 30 et l'erreur a disparu. Le problème peut donc être survenu en raison d'une sorte de débordement de pile dans le code Apple (jeu de mots prévu).

Je voyais le problème parce que je déclarais un tableau avec environ 60 éléments qui ressemblaient à ceci:

let byteMap = [

["ECG" : (0,12)],
["PPG" : (12,3)],
["ECG" : (15,12)],
["PPG" : (27,3)],
["ECG" : (30,12)]

En annotant explicitement le type comme ceci:

let byteMap : [String: (Int, Int)] = [

["ECG" : (0,12)],
["PPG" : (12,3)],
["ECG" : (15,12)],
["PPG" : (27,3)],
["ECG" : (30,12)],

J'ai pu l'arrêter. Je pense que cela doit avoir quelque chose à voir avec l'inférence de type et la vérification de type de Swift qui le fait entrer dans une boucle lorsqu'il rencontre un tableau long.

C'était dans Xcode 6.2. J'ai également supprimé le ModuleCache comme décrit ci-dessus et maintenant tout va bien.

Ce problème s'est produit 10 fois, 8 fois lorsque j'ai connecté un appareil réel et que je ne suis pas passé par le simulateur.

Je ne suis pas sûr que ma solution soit la bonne, mais pour moi, je pense que le problème était dû au passage d'un simulateur à un appareil réel. Cela peut sembler étrange, mais c'était comme si cela créait des interférences entre les fichiers de cache .

Ce qui a résolu mon problème:

• Nettoyer le dossier de construction: (sur Xcode)Alt + Shift + Command + K
• Réinitialiser le contenu et les paramètres: (sur le simulateur) Command + Shift + K.
• Attendu un peu plus longtemps que la normale et surcharge Xcode avec des clics constants

Donc, fondamentalement, avant d'essayer de fonctionner sur un nouvel appareil, supprimez simplement tout cache.

ÉDITER

J'ai juste eu le problème sans aucune connexion de périphérique. Je viens de quitter Xcode et de l'ouvrir à nouveau et le problème a disparu. Je ne suis pas sûr que je suppose que cela pourrait être un problème de réindexation après avoir récupéré / extrait le nouveau code de fusion.

J'ai résolu un autre problème qui faisait que SourceKitService utilisait jusqu'à 13 Go de mémoire ...

J'avais String (ligne de format avec beaucoup d'arguments:

return String(format: "%d,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f,%.3f", samples.count,sum1.x,sum1.y,sum1.z,sum1.rx,sum1.ry,sum1.rz,sum2.x,sum2.y,sum2.z,sum2.rx,sum2.ry,sum2.rz,sum3.x,sum3.y,sum3.z,sum3.rx,sum3.ry,sum3.rz)

une fois remplacé par celui-ci, cela fonctionnait bien (aucune accumulation de mémoire et consommation normale du processeur)

    var output: String = ""

    output += String(format: "%d,", samples.count)
    output += String(format: "%.3f,%.3f,%.3f,", sum1.x, sum1.y, sum1.z)
    output += String(format: "%.3f,%.3f,%.3f,", sum1.rx, sum1.ry, sum1.rz)
    output += String(format: "%.3f,%.3f,%.3f,", sum2.x, sum2.y, sum2.z)
    output += String(format: "%.3f,%.3f,%.3f,", sum2.rx, sum2.ry, sum2.rz)
    output += String(format: "%.3f,%.3f,%.3f,", sum3.x, sum3.y, sum3.z)
    output += String(format: "%.3f,%.3f,%.3f", sum3.rx, sum3.ry, sum3.rz)

    return output

J'ai rencontré ce problème avec Xcode 9 et j'ai exploré plusieurs solutions. Pour moi, la désactivation du contrôle de la source semblait faire l'affaire.

Xcode -> Preferences -> Source Control -> uncheck "Enable Source Control"

Si cela ne fonctionne pas, je recommanderais d'utiliser la commande renice sur le terminal . Plus à ce sujet ici

désactivation du contrôle de la source

Autres étapes que j'ai essayées, mais qui n'ont pas aidé:

1. Fermer Xcode -> Supprimer les données dérivées
2. machine à vélo
3. projet "propre"

Pour moi, cela a fonctionné pour supprimer les données dérivées. Sélectionnez «Produit» dans le menu et maintenez la touche Alt enfoncée et sélectionnez «Nettoyer le dossier de construction». Raccourci: Alt + Maj + Commande + K

1. Quitter Xcode
2. Exécuter dans le terminal:

rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache/*

Notez la différence entre la réponse acceptée de LNI et celle-ci:

1. Il vaut toujours mieux ne pas planter que de s'écraser. Surtout en ce qui concerne les processus / composants Xcode.
2. Je ne suis pas un développeur Apple, mais la suppression partielle du cache peut briser son intégrité. Je n'ai pas remarqué de retards importants après le nettoyage de tout le cache.

Je passe 4 heures à résoudre les problèmes dans une longue compilation de mon projet. Le premier essai prend 42 minutes à compiler.

Je /Users/myname/Library/Developer/Xcode/DerivedData/ModuleCache/vide tout le cache comme suggéré par @LNI, après le redémarrage SourceKitServiceet j'applique quelques modifications au code:

1) À

    var initDictionary:[String:AnyObject] = [
                    "details" : "",
                    "duration" : serviceDuration,
                    "name" : serviceName,
                    "price" : servicePrice,
                    "typeId" : typeID,
                    "typeName" : typeName,
                    "url" : "",
                    "serviceId" : serviceID,
                    "imageName" : ""
                ]

De

    var initDictionary= [
                    "details" : "",
                    "duration" : serviceDuration,
                    "name" : serviceName,
                    "price" : servicePrice,
                    "typeId" : typeID,
                    "typeName" : typeName,
                    "url" : "",
                    "serviceId" : serviceID,
                    "imageName: "" ]

2) À

            if let elem = obj.property,
                let elem2 = obj.prop2,
                etc
                 {
                 // do stuf here
            }

De

           let value1 = obj.property ?? defaultValue

3)

À

           let serviceImages = images.filter { $0.serviceId == service.id }
           let sorted = serviceImages.sort { $0.sort > $1.sort }

De

            let serviceImages = images.filter { $0.serviceId == service.id }. sort { $0.sort > $1.sort }

En conséquence, temps de compilation - 3 min, pas si rapide mais mieux pendant 42 min.

Par conséquent, avant SourceKitService- prenez ~ 5,2 Go de mémoire et après ~ 0,37 Go

J'ai eu le même problème avec SourceKitService.

J'ai résolu. NE JAMAIS AJOUTER DE SOUS-VUES AVEC FOR LOOP.

Pour détecter le problème, j'utilise: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode

Ne créez pas de dictionnaire en Swift sans spécifier les types de données ou avec [String: Any]

Si nous utilisons le type 'Any', le compilateur peut s'exécuter dans une boucle infinie pour vérifier le type de données.

Cela ne créera aucune erreur de compilation, cela obligera notre mac à se figer lors de la `` compilation des fichiers source swift '' en acquérant beaucoup de mémoire pour les tâches nommées `` swift '' et `` SourceKitService ''.

J'ai fait face à un tel problème. Le service du kit source utilisait 10 Go d'utilisation. Le processus Swift dans le moniteur d'activité atteint plus de 6 Go d'utilisation. J'utilisais le code suivant:

détails de la var: [String: Any] = ["1": 1, "2": 2, "3": 3, "4": 4, "5": 5, "6": 6, "7": 7, "8": 8, "9": 9, "10": 10, "11": 11, "12": 12, "13": 13, "14": 14, "15": 15, "16": 16]

J'ai changé le code en suivant pour résoudre ce problème:

détails var: [String: Any] = [:]

détails ["1"] = 1

détails ["2"] = 2

détails ["3"] = 3

détails ["4"] = 4

détails ["5"] = 5

détails ["6"] = 6

détails ["7"] = 7

détails ["8"] = 8

détails ["9"] = 9

détails ["10"] = 10

détails ["11"] = 11

détails ["12"] = 12

détails ["13"] = 13

détails ["14"] = 14

détails ["15"] = 15

détails ["16"] = 16

Le problème se produit toujours dans XCode 10.0. Vous pouvez résoudre ce problème en désactivant «Afficher les modifications du contrôle de code source» dans les options de contrôle de code source.

Face au même problème sur Xcode 7.2 (7C68)

La solution était d'implémenter une méthode de protocole, que ma classe avait dans la définition.

C'est toujours un problème dans la version 7.3.1 de xcode (7D1014), la cause pour moi était, comme LNI l'a souligné, un tableau trop long, pas si longtemps en fait. J'ai résolu mon problème en divisant le tableau en différents tableaux comme ceci:

let firstLevel = [
            [1, 0, 1, 0, 1],
            [0, 0, 0, 0, 0],
            [1, 0, 1, 0, 1],
            [0, 0, 0, 0, 0],
            [1, 0, 1, 0, 1],
            [0, 0, 0, 0, 0]
        ]
        let secondLevel = [
            [0, 0, 0, 0, 0],
            [0, 1, 0, 1, 0],
            [0, 0, 0, 0, 0],
            [0, 1, 0, 1, 0],
            [0, 0, 0, 0, 0],
            [0, 0, 0, 0, 0]
        ]
        let thirdLevel =     [
            [0, 0, 0, 0, 0],
            [0, 0, 0, 0, 0],
            [0, 0, 1, 0, 0],
            [0, 0, 0, 0, 0],
            [0, 0, 0, 0, 0],
            [0, 0, 0, 0, 0]
        ]
        let map = [firstLevel, secondLevel, thirdLevel]

J'ai eu le même problème avec XCode 8.2.1 (8C1002) et le code suivant:

import UIKit
import AVFoundation
import Photos
import CoreMotion
import Foundation


class TestViewController: UIViewController
{
    let movieFileOutput = AVCaptureMovieFileOutput()


var anz_total_frames = 0, anz_total_miss = 0

@IBOutlet weak var tfStatistics: UITextView!


func showVideoStatistics()
{
    let statisticText:String =             "frames: \(self.anz_total_frames)" + String.newLine +

        "frames/s: \(self.anz_total_frames / self.movieFileOutput.recordedDuration.seconds)" + String.newLine +

        "miss: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
    "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine +
        "nicht erkannt: " + formatText4FramesPercent(self.anz_total_miss) + String.newLine


    self.tfStatistics.text = statisticText
}

func formatText4FramesPercent(_ anz:Int) -> String
    {
        let perc = Double(anz)*100.0/Double(anz_total_frames)
        return String(perc.format(".1") + "%")
    }
}

et ces extensions:

extension String {
    var localized: String {
        return NSLocalizedString(self, tableName: nil, bundle: Bundle.main, value: "", comment: "")
    }

    static var newLine: String {
        return "\r\n"
    }
}

extension Int {
    func format(_ f: String) -> String {
        return String(format: "%\(f)d", self)
    }
}

extension Double {
    func format(_ f: String) -> String {
        return String(format: "%\(f)f", self)
    }
}

Je l'ai résolu en commentant cette ligne dans TestViewController:

        "frames/s: \(self.anz_total_frames / self.movieFileOutput.recordedDuration.seconds)" + String.newLine +

Il m'a fallu plus d'une heure pour le trouver, j'espère qu'un peut faire gagner du temps à quelqu'un d'autre. J'ai déposé un rapport de bogue à Apple avec le numéro 30103533

J'étais confronté au même problème après la migration du projet vers swift 3, découvrez la solution que cela prenait du temps à cause des dictionnaires et des tableaux créés sans type de données.

Ce comportement est apparu dans mon projet lorsque j'ai accidentellement déclaré une classe héritée d'elle-même. Xcode 8.2.1, en utilisant Swift 3.

J'ai également eu ce problème, dans mon cas, je déclarais un grand tableau comme celui-ci:

var myArray: [(String, Bool?)]?
myArray = [("someString", someBool),
("someString", someBool),
("someString", someBool),
("someString", someBool),
("someString", someBool)
.
.
("someString", someBool)]

J'ai résolu le problème en ajoutant les éléments 1 par ligne au lieu de tous en même temps:

var myArray = [(String, Bool?)]()
myArray.append(("someString", someBool))
myArray.append(("someString", someBool))
myArray.append(("someString", someBool))
myArray.append(("someString", someBool))
myArray.append(("someString", someBool))
.
.
.

cela a résolu le problème.

Pour les projets Objective-C:

J'ai eu le même problème, et il n'y a aucun code Swift dans notre projet, donc ce n'était pas le vérificateur d'inférence de type.

J'ai essayé toutes les autres solutions ici et rien n'a fonctionné - ce qui a finalement résolu pour moi était de redémarrer l'ordinateur en mode de récupération et d'exécuter la réparation du disque. Je peux enfin travailler à nouveau en paix!

Je suppose que cela s'est produit à cause de quelques liens symboliques rompus, pointant probablement l'un vers l'autre et faisant tourner le service dans une boucle sans fin.

J'ai un problème similaire avec Xcode 8.2.1 - avec une section de plus de 1000 lignes de code commentées via / * * /. La mise en commentaire de la section a causé le problème et la suppression du code commenté l'a résolu.

Je suis tombé sur quelque chose de similaire combinant plusieurs ?? opérateurs pour fournir une valeur par défaut pour les valeurs de chaîne facultatives.

J'expérimentais le code de débogage ci-dessous lorsque le ventilateur de mon fidèle MacBook Pro mi-2010 a commencé à fonctionner dur. SourceKitService absorbait chaque cycle CPU qu'il pouvait obtenir. Le fait de commenter et de décommenter la ligne incriminée a montré très clairement sur quoi SourceKitService s'étouffait. On dirait en utiliser plus d'un ?? l'opérateur pour fournir une valeur par défaut est un problème sur une ancienne machine. Le travail autour est de ne pas le faire. Divisez-le en plusieurs affectations, ce qui rend un code de débogage laid encore plus laid.

placeMark est une instance de CLPlacemark. Les propriétés utilisées ici renvoient des chaînes facultatives.

J'utilisais Xcode Version 8.3.2 (8E2002) fonctionnant sous OS 10.12.4 (16E195)

// one term is not an issue
let debugString1 = (placeMark.locality ?? "")

// two terms pushes SourceKitService CPU use to 107% for about 60 seconds then settles to 0%
let debugString1 = (placeMark.locality ?? "")  + ", " +  (placeMark.administrativeArea ?? "") 

// three terms pushes SourceKitService CPU use to 187% indefinitely 
let debugString1 = (placeMark.locality ?? "")  + ", " +  (placeMark.administrativeArea ?? "")  + (placeMark.postalCode ?? "")

// ugly but it's safe to use
var debugString1 = placeMark.locality ?? ""
debugString1 = debugString1 + ", " +  (placeMark.administrativeArea ?? "")
debugString1 = debugString1 + " " + (placeMark.postalCode ?? "")

La conversion de longs tableaux en fonctions semble résoudre le problème pour moi:

var color: [UIColor] {
    return [
        UIColor(...),
        UIColor(...),
        ...
    ]
}

à:

func color() -> [UIColor] {
    return [
        UIColor(...),
        UIColor(...),
        ...
    ]
}

exécuter dans le terminal:

killall Xcode
rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache
open /Applications/Xcode.app

vous pouvez également créer une commande de terminal en utilisant cet alias:

echo alias xcodeFix='killall Xcode;rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache;open /Applications/Xcode.app' >> ~/.profile
source ~/.profile

et puis juste courir

xcodeFix

https://www.logcg.com/en/archives/2209.html

SourceKitService a pris en charge le travail d'inférence de type de Swift.

private lazy var emojiFace = ["?", "?", "?", "?"]

changer pour taper explicitement

private lazy var emojiFace:[String] = ["?", "?", "?", "?"]

L'utilisation du processeur de SourceKitService descend immédiatement。

Cela m'est arrivé sur XCode 11.4.1 lors de l'appel des sous-scripts @dynamicMemberLookup dans un bloc SwiftUI @ViewBuilder.

J'ai eu le même problème et il a été causé par une erreur de programmation.

Dans mon cas, j'implémentais les protocoles comparables et équatable et les lhs.param et rhs.param ne correspondaient pas aux paramètres des classes lhs et rhs.