Это НЕ проблема бета-версии. Я использую Xcode 6.0.1, производственный выпуск. Проблема, с которой я сталкиваюсь, заключается в том, что когда я пытаюсь выполнить сборку или запуск кода, над которым я работаю, Xcode перестает отвечать на запросы в течение значительных периодов времени, а SourceKitService потребляет более 400% ЦП (согласно Activity Monitor). Эта проблема возникла в последние несколько дней, хотя, как ни странно, я использовал Xcode 6.0 с тех пор, как она была официально выпущена 17 сентября. Я обновился до 6.0.1, надеясь, что она будет содержать исправление для этой проблемы.
Есть идеи, в чем может быть проблема?
Ответы:
Раньше сегодня днем столкнулся с этой проблемой с Xcode 6.1.1 (не бета, официальная выпущенная версия). Я запускал код на Playground и подозревал, что это причина. ЦП был привязан почти к 100%, и Xcode не мог завершить сборки.
Итак, вот что я сделал:
1. Открыл «Монитор активности», который показал SourceKitService в качестве основной нагрузки на ЦП.
2. В «Мониторе активности» дважды щелкните SourceKitService и щелкните раздел «Открыть файлы и порты», который показал, что он работает с файлами в каталоге / Users / myname / Library / Developer / Xcode / DerivedData / ModuleCache /. для конкретной папки.
3. Удалил указанную папку (из командной строки, используя rm -rf). Кеш регенерируется на основе Могу ли я безопасно удалить содержимое папки с производными данными Xcode? .
4. Снова используя Activity Monitor, принудительно завершите работу SourceKitServer. Увидел теперь уже слишком знакомый знак в Xcode, говорящий о том, что SourceKitService разбился (поэтому SourceKitService звучал знакомо!).
5. Повторяем шаг 3.
Mac снова мирный. Данные не были потеряны, и Xcode даже не нужно было перезапускать (что я безуспешно пытался). Суть в том, что ModuleCache, похоже, получает SourceKitService в цикле, и удаление папки, похоже, исправляет это. Надеюсь, это сработает и для вас.
Сноска:
Кстати, причиной проблемы SourceKitService было то, что у меня было слишком длинное объявление массива в моем классе Swift. У меня было более 200 записей в массиве. Снизил до 30 и ошибка исчезла. Таким образом, проблема могла возникнуть из-за переполнения стека в коде Apple (каламбур).
источник
Я увидел проблему, потому что объявлял массив примерно из 60 элементов, который выглядел так:
Явно аннотируя тип следующим образом:
Я смог остановить это. Я думаю, это должно быть связано с выводом типов и проверкой типов в Swift, что заставляет его зацикливаться, когда он встречает длинный массив.
Это было в Xcode 6.2. Я также удалил ModuleCache, как описано выше, и теперь все в порядке.
источник
return ["a", "b", "c", "d", "e", "f"]
функции, которая возвращает[String]
, у нее все еще были бы проблемы с выводом типа?Эта проблема возникала 10 раз, 8 раз возникала, когда я подключал реальное устройство и не запускал симулятор.
Я не уверен, что мое решение хорошее, но я считаю, что проблема была связана с переключением между симулятором и реальным устройством. Это может показаться странным, но это было так, как если бы это создавало помехи между файлами кеша .
Что решило мою проблему:
Alt + Shift + Command + K
Command + Shift + K
.Итак, в основном, прежде чем пытаться запустить на любом новом устройстве, просто удалите любой кеш.
РЕДАКТИРОВАТЬ
У меня просто возникла проблема без подключения какого-либо устройства. Я просто вышел из Xcode и снова открыл его, и проблема исчезла. Не уверен, что я предполагаю, что это может быть проблема с повторной индексацией после того, как вы загрузите / вытащите слияние новый код.
источник
Я решил еще одну проблему, из-за которой SourceKitService использовал до 13 ГБ памяти ...
У меня была строка (строка формата с множеством аргументов:
при замене на это он работал нормально (без накопления памяти и нормального потребления процессора)
источник
Я столкнулся с этой проблемой с Xcode 9 и изучил несколько решений. Мне показалось , что отключение управления версиями помогло.
Xcode -> Preferences -> Source Control -> uncheck "Enable Source Control"
Если это не сработает, я бы рекомендовал использовать команду renice в терминале . Подробнее об этом здесь
отключение управления версиями
Другие шаги, которые я предпринял, но не помогли:
источник
Для меня это сработало, чтобы удалить производные данные. Выберите «Продукт» в меню, удерживая клавишу Alt, выберите «Очистить папку сборки». Горячая клавиша: Alt + Shift + Command + K
источник
rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache/*
Обратите внимание на разницу между принятым ответом LNI и этим:
источник
Я трачу 4 часа на то, чтобы решить проблемы в длинной компиляции моего проекта. Первая попытка компиляции занимает 42 минуты.
Я
/Users/myname/Library/Developer/Xcode/DerivedData/ModuleCache/
очищаю весь кеш, как было предложено @LNI, после перезапускаSourceKitService
и применяю несколько изменений для кода:1) Чтобы
Из
2) Чтобы
Из
3)
Чтобы
Из
В итоге время компиляции - 3 мин, не так быстро, но лучше за 42 мин.
В итоге до
SourceKitService
- беру ~ 5,2Гб памяти и после ~ 0,37Гбисточник
У меня была такая же проблема с SourceKitService.
Я решил. НИКОГДА НЕ ДОБАВЛЯЙТЕ ПОДРОБНЕЕ В FOR LOOP.
Чтобы обнаружить проблему, я использую: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode
источник
Не создавайте словарь быстро без указания типов данных или с помощью [String: Any]
Если мы используем тип «Любой», компилятор может зайти в бесконечный цикл для проверки типа данных.
Это не создаст никаких ошибок компиляции, это заставит наш Mac зависать при «компиляции быстрых исходных файлов» с получением большого количества памяти для задач с именами «swift» и «SourceKitService».
источник
Я столкнулся с такой проблемой. Служба исходного набора использовала 10 ГБ. Быстрый процесс в мониторе активности достигает более 6 ГБ. Я использовал следующий код:
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]
Я изменил код на следующий, чтобы решить эту проблему:
детали 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
источник
Проблема по-прежнему возникает в XCode 10.0. Вы можете исправить это, отключив «Показать изменения в системе управления версиями» в параметрах системы управления версиями.
источник
Столкнулся с той же проблемой на
Xcode 7.2 (7C68)
Решением было реализовать метод протокола, который был у моего класса в определении.
источник
Это все еще проблема в xcode версии 7.3.1 (7D1014), потому что для меня причина была, как указал LNI, слишком длинным массивом, на самом деле не таким длинным. Я исправил свою проблему, разбив массив на различные массивы, например:
источник
У меня была такая же проблема с XCode 8.2.1 (8C1002) и следующим кодом:
и эти расширения:
Я решил это, прокомментировав эту строку в TestViewController:
Мне потребовалось больше часа, чтобы найти его, я надеюсь, что это поможет кому-то еще сэкономить время. Я отправил отчет об ошибке в Apple с номером 30103533.
источник
Я столкнулся с той же проблемой после переноса проекта на swift 3, выяснил, что решение требовало времени из-за словарей и массива, созданных без типа данных.
источник
Такое поведение появилось в моем проекте, когда я случайно объявил класс, унаследованный от самого себя. Xcode 8.2.1, используя Swift 3.
источник
У меня тоже была эта проблема, в моем случае я объявлял такой большой массив:
Я решил проблему, добавив элементы по 1 в строке, а не все одновременно:
это устранило проблему.
источник
Для проектов Objective-C:
У меня была такая же проблема, и в нашем проекте нет кода Swift, поэтому это не средство проверки вывода типов.
Я пробовал все другие решения здесь, и ничего не работало - что НАКОНЕЦ исправило для меня, так это перезагрузка компьютера в режиме восстановления и запуск восстановления диска. Наконец-то я снова могу спокойно работать!
Я предполагаю, что это произошло из-за некоторых сломанных символических ссылок, которые, вероятно, указывают друг на друга и заставляют службу работать в бесконечном цикле.
источник
У меня аналогичная проблема с Xcode 8.2.1 - с разделом из более чем 1000 строк кода, закомментированным через / * * /. Комментарий к разделу вызвал проблему, а удаление закомментированного кода исправило ее.
источник
Я столкнулся с чем-то похожим, сочетающим несколько ?? операторы для предоставления значения по умолчанию для необязательных строковых значений.
Я экспериментировал с приведенным ниже кодом отладки, когда вентилятор моего верного MacBook Pro середины 2010 года начал сильно работать. SourceKitService поглощал каждый цикл процессора, который мог получить. Комментируя и раскомментировав оскорбительную строку, стало очень ясно, чем подавился SourceKitService. Похоже, что используется более одного ?? Оператор по умолчанию - это проблема на старой машине. Решение просто не делайте этого. Разбейте его на несколько назначений, что сделает некрасивый код отладки еще более уродливым.
placeMark - это экземпляр CLPlacemark. Используемые здесь свойства возвращают необязательные строки.
Я использовал Xcode версии 8.3.2 (8E2002) под управлением OS 10.12.4 (16E195)
источник
"\() \()"
Вместо этого стоит попробовать (Преобразование длинных массивов в функции, похоже, решает проблему для меня:
кому:
источник
запустить в терминале:
вы также можете создать команду терминала, используя этот псевдоним:
а потом просто беги
источник
Со мной случилось в XCode 11.4.1 при вызове индексов @dynamicMemberLookup внутри блока SwiftUI @ViewBuilder.
источник
https://www.logcg.com/en/archives/2209.html
SourceKitService взял на себя работу по выводу типов в Swift.
изменить на явно тип
Использование CPU SourceKitService сразу же раскрывается。
источник
У меня была такая же проблема, и она была вызвана ошибкой программирования.
В моем случае я реализовал сопоставимые и равноправные протоколы, а lhs.param и rhs.param не соответствовали параметрам классов lhs и rhs.
источник