To NIE jest problem z wersją beta. Jestem na Xcode 6.0.1, wersja produkcyjna. Problem polega na tym, że kiedy próbuję zbudować lub uruchomić kod, nad którym pracuję, Xcode przestaje odpowiadać przez długi czas, a SourceKitService zużywa ponad 400% procesora (zgodnie z monitorem aktywności). Ten problem jest nowy od kilku dni, chociaż, co dziwne, korzystałem z Xcode 6.0, odkąd został oficjalnie wydany 17 września. Zaktualizowałem do 6.0.1, mając nadzieję, że będzie zawierał poprawkę dla tego problemu.

Masz jakiś pomysł, jaki może być problem?

Napotkałem ten problem z Xcode 6.1.1 wcześniej po południu (nie beta, oficjalna wydana wersja). Uruchomiłem kod na Playground i podejrzewałem, że to jest przyczyna. Procesor został ustalony na prawie 100%, a Xcode nie był w stanie ukończyć kompilacji.

Oto co zrobiłem:

1. Otwarto „Monitor aktywności”, który pokazał SourceKitService jako główny procesor.

2. W „Activity Monitor” dwukrotnie kliknąłem SourceKitService i kliknąłem sekcję „Otwórz pliki i porty”, co pokazało, że pracuje na plikach w katalogu / Users / myname / Library / Developer / Xcode / DerivedData / ModuleCache / dla określonego folderu.

3. Usunięto określony folder (z wiersza poleceń, używając rm -rf). Pamięć podręczna jest ponownie generowana w oparciu o Czy mogę bezpiecznie usunąć zawartość folderu danych pochodnych Xcode? .

4. Ponownie używając Monitora aktywności, wymuś zamknięcie SourceKitServer. Zobaczyłem już dobrze znany znak w Xcode, informujący, że SourceKitService uległ awarii (dlatego SourceKitService brzmiał znajomo!).

5. Powtórz krok 3.

Mac znów jest spokojny. Żadne dane nie zostały utracone, a Xcode nie musiał nawet być restartowany (co próbowałem bez powodzenia). Najważniejsze jest to, że ModuleCache wydaje się pobierać SourceKitService w pętli, a usunięcie folderu wydaje się to naprawiać. Mam nadzieję, że to działa również dla Ciebie.

Przypis:

Nawiasem mówiąc, przyczyną problemu z SourceKitService było to, że miałem zbyt długą deklarację tablicy w mojej klasie Swift. Miałem ponad 200 wpisów w tablicy. Zmniejszono go do 30 i błąd zniknął. Więc problem mógł powstać z powodu przepełnienia stosu w kodzie Apple (gra słów zamierzona).

Widziałem problem, ponieważ deklarowałem tablicę z około 60 elementami, która wyglądała tak:

let byteMap = [

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

Poprzez jawne opisanie typu w następujący sposób:

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

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

Udało mi się to zatrzymać. Myślę, że musi to mieć coś wspólnego z wnioskami typu Swift i sprawdzaniem typów, które powodują, że przechodzi w pętlę, gdy napotka długą tablicę.

To było w Xcode 6.2. Usunąłem też ModuleCache, jak opisano powyżej i teraz wszystko jest w porządku.

Ten problem zdarzył się 10 razy, 8 razy, gdy podłączyłem rzeczywiste urządzenie i nie uruchomiłem symulatora.

Nie jestem pewien, czy moje rozwiązanie jest dobre, ale wydaje mi się, że problem wynikał z przełączania się między symulatorem a rzeczywistym urządzeniem. Może to zabrzmieć dziwnie, ale było tak, jakby powodowało zakłócenia między plikami pamięci podręcznej .

Co rozwiązało mój problem:

• Clean Build Folder: (w Xcode)Alt + Shift + Command + K
• Zresetuj zawartość i ustawienia: (w symulatorze) Command + Shift + K.
• Czekałem trochę dłużej niż normalnie i przeciążałem Xcode ciągłymi kliknięciami

Zasadniczo, zanim spróbujesz uruchomić na jakimkolwiek nowym urządzeniu, po prostu usuń dowolną pamięć podręczną.

EDYTOWAĆ

Po prostu miałem problem bez połączenia urządzenia. Po prostu zamknąłem Xcode i otworzyłem go ponownie, a problem zniknął. Nie jestem pewien, czy zgaduję, że może to być problem z ponownym indeksowaniem po pobraniu / ściągnięciu i scaleniu nowego kodu.

Rozwiązałem inny problem, który powodował, że SourceKitService zużywał do 13 GB pamięci ...

Miałem String (linia formatu z wieloma argumentami:

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)

po wymianie na to działało dobrze (bez gromadzenia się pamięci i normalnego zużycia procesora)

    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

Natknąłem się na ten problem z Xcode 9 i zbadałem kilka rozwiązań. Dla mnie wyłączenie kontroli źródła wydawało się działać.

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

Jeśli to nie zadziała, polecam użycie polecenia renice na terminalu . Więcej na ten temat tutaj

wyłączanie kontroli źródła

Inne kroki, które próbowałem, ale nie pomogły:

1. Zamknij Xcode -> Usuń pochodne dane
2. maszyna rowerowa
3. „czysty” projekt

U mnie działało, aby usunąć dane pochodne. Wybierz „Produkt” z menu, przytrzymaj klawisz Alt i wybierz „Wyczyść folder kompilacji”. Skrót: Alt + Shift + Command + K.

1. Zamknij Xcode
2. Uruchom w terminalu:

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

Zwróć uwagę na różnicę między zaakceptowaną odpowiedzią LNI a tą:

1. Zawsze lepiej nie upaść niż się rozbić. Zwłaszcza jeśli chodzi o procesy / komponenty Xcode.
2. Nie jestem programistą Apple, ale częściowe usunięcie pamięci podręcznej może naruszyć jej integralność. Po wyczyszczeniu całej pamięci podręcznej nie zauważyłem żadnych znaczących opóźnień.

Spędzam 4 godziny na rozwiązywaniu problemów w długiej kompilacji mojego projektu. Pierwsza próba zajmuje 42 minuty.

/Users/myname/Library/Developer/Xcode/DerivedData/ModuleCache/Wyczyszczam całą pamięć podręczną, zgodnie z sugestią @LNI, po ponownym uruchomieniuSourceKitService i wprowadzeniu kilku zmian w kodzie:

1) Do

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

Z

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

2) Do

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

Z

           let value1 = obj.property ?? defaultValue

3)

Do

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

Z

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

W rezultacie czas kompilacji - 3 minuty, nie tak szybko, ale lepiej przez 42 minuty.

W rezultacie przed SourceKitService- zajmij ~ 5,2 GB pamięci, a po ~ 0,37 GB

Miałem ten sam problem z SourceKitService.

Rozwiązałem. NIGDY NIE DODAJ PODGLĄDÓW ZA POMOCĄ FOR LOOP.

Aby wykryć problem, którego używam: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode

Nie twórz słownika w swift bez określenia typów danych lub z [String: Any]

Jeśli użyjemy typu „Any”, kompilator może napotkać nieskończoną pętlę sprawdzania typu danych.

Nie spowoduje to żadnego błędu kompilacji, sprawi, że nasz Mac zawiesi się przy „kompilowaniu szybkich plików źródłowych”, uzyskując dużo pamięci dla zadań o nazwie „swift” i „SourceKitService”.

Miałem do czynienia z takim problemem. Usługa zestawu źródłowego zużywała 10 GB. Szybki proces w monitorze aktywności osiąga ponad 6 GB wykorzystania. Używałem następującego kodu:

var details: [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]

Zmieniłem kod na następujący, aby rozwiązać ten problem:

szczegóły var: [String: Any] = [:]

szczegóły ["1"] = 1

szczegóły ["2"] = 2

szczegóły ["3"] = 3

szczegóły ["4"] = 4

szczegóły ["5"] = 5

szczegóły ["6"] = 6

szczegóły ["7"] = 7

szczegóły ["8"] = 8

szczegóły ["9"] = 9

szczegóły ["10"] = 10

szczegóły ["11"] = 11

szczegóły ["12"] = 12

szczegóły ["13"] = 13

szczegóły ["14"] = 14

szczegóły ["15"] = 15

szczegóły ["16"] = 16

Problem nadal występuje w XCode 10.0. Możesz to naprawić, wyłączając opcję „Pokaż zmiany kontroli źródła” w opcjach kontroli źródła.

W obliczu tego samego problemu Xcode 7.2 (7C68)

Rozwiązaniem było zaimplementowanie metody protokołu, którą moja klasa miała w definicji.

Jest to nadal problem w xcode w wersji 7.3.1 (7D1014). Przyczyną dla mnie była, jak wskazała LNI, zbyt długa tablica, właściwie nie tak długa. Rozwiązałem swój problem, dzieląc tablicę na różne tablice, takie jak to:

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]

Miałem ten sam problem z XCode 8.2.1 (8C1002) i następującym kodem:

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") + "%")
    }
}

i te rozszerzenia:

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)
    }
}

Rozwiązałem to, komentując tę ​​linię w TestViewController:

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

Znalezienie go zajęło mi ponad godzinę, mam nadzieję, że zaoszczędzę trochę czasu komuś innemu. Złożyłem raport o błędzie do Apple pod numerem 30103533

Miałem ten sam problem po migracji projektu do Swift 3, znajdź rozwiązanie, że zajęło to trochę czasu z powodu słowników i tablic utworzonych bez typu danych.

Takie zachowanie pojawiło się w moim projekcie, gdy przypadkowo zadeklarowałem klasę, która odziedziczyła po sobie. Xcode 8.2.1 przy użyciu języka Swift 3.

Miałem też ten problem, w moim przypadku deklarowałem dużą tablicę w ten sposób:

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

Rozwiązałem problem, dodając pozycje 1 w wierszu zamiast wszystkich jednocześnie:

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

to rozwiązało problem.

W przypadku projektów w ramach celu C:

Miałem ten sam problem i nie ma kodu Swift w naszym projekcie, więc nie był to moduł sprawdzania wnioskowania o typie.

Wypróbowałem tutaj każde inne rozwiązanie i nic nie działało - to, co KOŃCOWO naprawiłem to dla mnie, to ponowne uruchomienie komputera w trybie odzyskiwania i uruchomienie naprawy dysku. Wreszcie mogę znów pracować w spokoju!

Domyślam się, że stało się to z powodu zepsutych linków symbolicznych, prawdopodobnie wskazujących na siebie i powodujących, że usługa działa w nieskończonej pętli.

Mam podobny problem z Xcode 8.2.1 - z sekcją ponad 1000 wierszy kodu zakomentowanych za pomocą / * * /. Skomentowanie sekcji spowodowało problem, a usunięcie zakomentowanego kodu rozwiązało problem.

Wpadłem na coś podobnego, łącząc wiele ?? operatory, aby zapewnić domyślne dla opcjonalnych wartości ciągów.

Eksperymentowałem z poniższym kodem debugowania, gdy wentylator mojego zaufanego MacBooka Pro z połowy 2010 roku zaczął ciężko pracować. SourceKitService pochłaniał każdy cykl procesora, jaki mógł uzyskać. Komentowanie i usuwanie komentarzy w obraźliwej linijce było bardzo jasne, czym dławi się SourceKitService. Wygląda na to, że używasz więcej niż jednego? dostarczenie przez operatora wartości domyślnej jest problemem na starym komputerze. Problem polega na tym, że po prostu tego nie rób. Podziel go na wiele przypisań, co sprawia, że ​​brzydki kod debugowania jest jeszcze brzydszy.

placeMark jest instancją klasy CLPlacemark. Właściwości użyte tutaj zwracają opcjonalne ciągi.

Używałem Xcode w wersji 8.3.2 (8E2002) działającego na systemie operacyjnym 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 ?? "")

Przekształcenie długich tablic w funkcje wydaje mi się rozwiązywać problem:

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

do:

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

uruchomić w terminalu:

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

możesz również utworzyć polecenie terminala, używając tego aliasu:

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

a potem po prostu biegnij

xcodeFix

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

SourceKitService przejął kontrolę nad wnioskami typu Swift.

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

zmienić na jawny typ

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

Zużycie procesora SourceKitService natychmiast spada。

Zdarzyło mi się w XCode 11.4.1 podczas wywoływania skryptów @dynamicMemberLookup wewnątrz bloku SwiftUI @ViewBuilder.

Miałem ten sam problem i był on spowodowany błędem programowania.

W moim przypadku implementowałem protokoły porównywalne i wyrównane, a parametry lhs.param i rhs.param nie odpowiadały parametrom klas lhs i rhs.