Как стать автором
Обновить

AppCode 2021.1: улучшения поддержки Swift Package Manager и быстродействия, обновление плагина Kotlin/Native и другое

Время на прочтение2 мин
Количество просмотров1.9K
Всего голосов 4: ↑3 и ↓1+2
Комментарии5

Комментарии 5

Спасибо. Отличный релиз. Но у вас все еще проблемы с автокомплишеном и навигацией в проектах с development pods и сложными associated types :(

Когда-то давно пользовался AppCode, но перестал из-за того, что на более-менее сложных проектах это просто невозможно. Сейчас вот запустил новую версию и уже 15 минут жду, пока идет индексация всего подряд при почти полной загрузке проца. Причем это происходит каждый раз при перезапуске IDE, хотя не очень понятно, зачем каждый раз индексировать iOS SDK. В течении этих 15 минут работать невозможно из-за того, что во время индексации не работает никакой функционал кроме базового.
После индексации поиск и резолв символов в первые разы занимает 5-7 секунд, так что быстрее воспользоваться обычным поиском по файлам.

image

Сразу же первая проблема — проект не собирается, AppCode почему-то игнорирует локальные SPM пакеты — не собирает их и ругается на «missing package».
И Select Opened File для файлов из локальных пакетов не работает.

Вот и все, AppCode уходит на дальнюю полку до следующего релиза.
Сейчас вот запустил новую версию и уже 15 минут жду, пока идет индексация всего подряд при почти полной загрузке проца.

В первый раз индексируется и кэшируется и проект, и SDK. Это долго, тут что можем — оптимизируем, но если проект крупный, в первый раз подождать необходимо. Полная загрузка проца тут by design, потому что если его не использовать весь — будет еще дольше, а мы хотим максимально ускорить данный процесс. Он тяжелый, да, крайне тяжелый.
Причем это происходит каждый раз при перезапуске IDE, хотя не очень понятно, зачем каждый раз индексировать iOS SDK.

Мы не индексируем каждый раз SDK. Мы каждый раз проверяем, что поменялось в проекте от перезапуска к перезапуску. Предсказать, что именно вы изменили (или не изменили) без повторной индексации нельзя — но при этом, она должна быть существенно быстрее. Или она у вас на тех же сорцах без изменений идет каждый раз 15 минут?
В течении этих 15 минут работать невозможно из-за того, что во время индексации не работает никакой функционал кроме базового.

Без дерева символов, увы, не существует магии, которая позволила бы быстрее что-то выдать. Хотя, вот сборка/отладка/тесты у нас работают и без индексации, в отличие от многих других продуктов JB, плюс должно на каком-то этапе включаться автодополнение через SourceKit (хотя и без подсветки)
После индексации поиск и резолв символов в первые разы занимает 5-7 секунд, так что быстрее воспользоваться обычным поиском по файлам.

Ну, кэши имеют свойство достраиваться пока идет подсветка для конкретного файла. Скорее всего, здесь вы пробовали когда они еще не достроились, либо строились для конкретного непростого случая в первый раз — но дальше должно быть быстрее. Вообще, тут бы конечно CPU snapshot к нам в трекер.
Сразу же первая проблема — проект не собирается, AppCode почему-то игнорирует локальные SPM пакеты — не собирает их и ругается на «missing package».
И Select Opened File для файлов из локальных пакетов не работает.

Хм. Вообще проблемы с локальными зависимостями вроде как все поправили. У вас случайно какого-нибудь минимального проекта, на котором воспроизводится, нет в свободном доступе? И нет ли в проекте приватных зависимостей откуда-либо, доступных по ключу в Git?
Мы не индексируем каждый раз SDK. Мы каждый раз проверяем, что поменялось в проекте от перезапуска к перезапуску.


Я понимаю, что так задумано — но в моем случае SDK индексируется каждый раз. Вот запустил проект прямо сейчас — индексация заняла 11 минут.
Более того, после неудачного билда я почистил проект и индексация снова запустилась — и снова там мелькали символы из SDK.

image

Полная загрузка проца тут by design

Идея понятна, но пользоваться чем-то, что фризит всю систему на 5-10 минут во время работы — очень напряжно. Собственно, я из-за этого и вернулся на Xcode какое-то время назад.

И нет ли в проекте приватных зависимостей откуда-либо, доступных по ключу в Git?

Попробовал сейчас собрать и действительно — проблема в приватных пакетах. Решилась подтверждением использования ключа из терминала. В Xcode все работало без проблем почему-то.
Кстати, Select Opened File для локальных пакетов все так же не работает.
Я понимаю, что так задумано — но в моем случае SDK индексируется каждый раз.

То есть вот именно фаза Processing Swift Modules каждый раз занимает 11 минут? Или вся повторная индексация целиком? Просто то, что там каждый раз мелькают модули SDK значит только то, что прошла проверка на наличие кэша и индексация полетела дальше. Почему так — ну вот скачали вы очередной свифтовый тулчейн, и нет никаких гарантий, что символы в нем те же, приходится перестраивать. Если без изменений, просто поняли, что содержимое модуля по ключу уже закэшировано и проскочили его.
Более того, после неудачного билда я почистил проект и индексация снова запустилась — и снова там мелькали символы из SDK.

Ну, тут спасибо компании Apple за то, что ряд исходников генерится в папке с билдом и соответственно их исчезновение при очистке вызывает переиндексацию.
Идея понятна, но пользоваться чем-то, что фризит всю систему на 5-10 минут во время работы — очень напряжно.

А вот если идет фриз всей системы — это какая-то проблема. А при фризе системы случайно не наблюдается куча процессов clang/swift? У нас там в силу необходимости сгенерить перед индексацией те самые исходники, которые генерятся в папке сборки, происходит определенная квантовая магия, возможно пара заклинаний не сходится.
Решилась подтверждением использования ключа из терминала. В Xcode все работало без проблем почему-то.

Это OC-21826. Если коротко, то ключи для GitHub сохраняются Xcode в свои Accounts, получить информацию из которых, мягко говоря, непросто. Из коробки с xcodebuild они не работают — мы там как бы просто xcodebuild -resolvePackageDependencies зовем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий