У вас метод sendRequest является блокирующим, наверное лучше ему дать имя sendSyncRequest. Да и вызывающий тред будет заблокан на время запроса, думаю ему можно найти более нужное применение чем ждать ответа от сервера. Вы реализовали своего рода корутины, но очень не оптимально по ресурсам.
Верно говорите. Надо чтобы приложение было написано на свифте >= 5.0 (или 5.1 уже не помню, в общем ABI стабилити), начиная с этих версий системные либы уже лежат в самой OS, а не идут вместе с приложение в apk. И на старте приложения их уже не надо подгружать так как они уже в памяти ОС имеются. Отсюда и быстрый старт.
Спасибо, пользуюсь 2019.1, но мне кажется 2018 версия была шустрее. После следующих изменений стало, вроде, лучше:
1. Добавил некоторые JVM флаги ( stackoverflow.com/questions/5651538/speedup-intellij-idea). После настроек сделал max 2Gb и min 1Gb и это оказалось лучше чем я когда выставлял max 7Gb, все равно AppCode всегда показывает использование памяти ок 800Мб.
2. Комплишен оооочень медленный, в итоге убрал галочки на smart и base completion, мне важно чтобы комплит появлялся, то что он мне помогал бы не совсем важно, иначе с этими галочками приходится по 5 — 10 секунд ждать первые подсказки, а без них всего пару секунд. Еще есть хак, если нужно вызвать метод или переменную из локального скоупа (class/struct/etc) то нужно всегда писать self. тогда видимо отсекаются глобальные области поиска и комплит почти сразу работает. Для глобальных функций/переменных как долго работал так и работает, проще дописать руками или открыть Xcode и там написать и потом обратно переключиться.
Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode. Тесты проводились следующим образом.
Xcode:
1. Закрыл Xcode
2. Почистил DerivedData (Library/.../Xcode/DerivedData)
3. Открыл Xcode и сразу нажал запустить проект на симуляторе (то есть полная сборка + запуск)
Время на всё ушло 3:50-4:00 минуты в Xcode
AppCode, тоже самое, только чистил его DerivedData (../Caches/../AppCode 2019/../DerivedData/) и AppCode мне выдавал больше 5 минут (нажимал на жука чтобы включить отладку я так понимаю).
Еще мне очень сильно не нравится в 2019 после 2018 версии, что довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20, то есть IDE UI не блокирован, но если попробовать посмотреть описание любой переменной или функции в классе (да хочь чего) через cmd+touchpad то ничего не показывает, если нажать на любой (тут я подчеркиваю, что работа с другой нетронутой функцией, а не которая была переименована) вызов функции то не переходит в ее дефенишен и более того эта функция даже не подсвечивается (что по ней можно перейти).
Еще замечаю (любая версия IDE), что бывают выражения, которые программа с другом вывозит. Вот например внутри функции был код
let obj1 // CoreData объект из другого модуля
let obj2 // еще CoreData объект из другого модуля
let ratio = 100 * obj1.price1 / obj2.price2
вот после того как написал знак деления сразу стали видны лаги UI причем постоянные толи пока курсор не убрал с этой линии, толи пока выражение не дописал, но суть в том, что после знака деления комплит наотрез отказался работать (ну или ждать минуту надо). Подобное поведение встречается в сложных выражениях и автокомплит работает после полуминуты ожидания. Ужас.
Очень плохо резолвится chaining, прям проблема
guard let obj = object?.array.first?.innerObject?.someFireld else { return }
Тут всегда даже подсветка не работает, я уже не говорю, что не может вывести тип. Такое часто когда тип объекта object из другого модуля.
2019 версия стала подсвечивать больше кода, конечно есть участки где IDE не может понять, но их стало меньше — за это спасибо.
Уже не помню, но вроде компишен дженериков тоже очень плохо работает
class A {
private let relay = RxSwift.BehaviorRelay</* с этого места комплит не работает */User?>(value: nil)
}
Вот всегда при объявлении подобных переменных тип приходится писать руками, автокомплит молчит.
На мой взгляд rebase очень удобен только при работе в своей feature ветке для выравнивания с общей (develop) веткой. С shared ветками довольно проблематично, учитывая, что в среднем многие разработчики не очень сильно разбираются в таких тонкостях, проще просто не создавать проблем коллегам и просто использовать merge. Вливание в основную ветку у нас в целом заведено делать через megre с опцией —no-ff.
— Про Xmx проверил показывает 1700 из 4000 (выставлено у меня в 4096).
— По rx будут примеры, сейчас с ходу не могу найти.
— Про associatedType еще раз проверил в чистом проекте и поведение отличное от Xcode.
protocol Service {
associatedtype Item
func apply(_ item: Item)
}
class UserService: Service {
func apply(_ item: Item) { }
}
struct Item { }
Перейдите в definition для Item в UserService и AppCode перейдет в протокол, а Xcode перейдет в структуру.
Здравствуйте. Ежедневно использую AppCode, замечательный продукт. Но на больших проектах очень тяжело в нем писать код, поэтому в основном использую только для навигации по проекту, так как он замечательно с этим справляется. Что немного раздражает, что даже базовый автокомплит очень медленный, пишешь let a: Str и ждешь секунд 5 чтобы он дополнил String, про функцию print() он видимо вообще ничего не знает — никогда ее не комплитит. Комплит имен локальных переменных во время их использования тоже очень долгое, благодаря вам я почти освоил слепую печать, ибо это намного быстрее чем ждать пока IDE дополнит, что я пишу. Про Rx я вообще молчу, дальше одной .map он сам вывести тип не может (да и с коллекциями также часто бывает), поэтому Rx в 80% случаев пишу в Xcode. Еще неверно переходит на тип associatedType у протоколов если тип в иплементаторе совпадает с именем associatedType, IDE переходит в описание протокола, но Xcode переходит куда надо. Самое забавное, что подобных проблем с автокомплитом в Xcode нет вообще — работает молниеносно по сравнению с AppCode. Всё выше написанное относится только к swift, в objc проблем нет. Что очень нравится, это поддержка git и автокомплит к сфивтовым enum'ам, Xcode c дополнениями кейсов, почему-то, работает довольно криво. Пока у меня такая статистика, что 60% времени провожу в AppCode (пишу в слепую, так как комплит не работает, но просто привычно после Java (IntelliJ Idea)), остальное время в Xcode. Уже который месяц (или год) надеюсь, что всё таки всё это почините. Когда писал на objc всегда коллегам хвалил ваш продукт, после перехода на свифт не вижу существенных преимуществ over Xcode.
Еще переименование методов приватных протоколов или классов может зафризить IDE очень долго, как будто идет поиск по всему проекту, ведь это всё private, что там так долго делать я до сих пор понять не могу. Приходится убивать IDE так как на cancel она не отменяет renaming. После перезапуска она может не сохранить последнюю минуту работы. Вот эти мелкие косяки портят общее впечатление о продукте.
А почему просто не собрать приложение в релизной конфигурации, но с дев сертификатом? Если у вас проблема с APNS в релизной сборке, то вы же все равно переподписываете приложение и весь смысл затеи теряется.
Оффтоп, был раз кейс когда в релизной конфигурации (максимально агрессивные оптимизации) почему-то объект в одном месте внезапно умирал и приложение падало в segmentation fault. Добавление строчки print(object) перед обращением к объекту решило проблему. Swift был 2-ой или 3-ий.
Есть плагины для Xcode чтобы генерировать иниты, например github.com/rjoudrey/swift-init-generator. Я так понимаю, что в классах у вас все проперти являются var, чтобы избавиться от конструктора, тогда мы теряем иммутабельность объекта. К тому же структуры более эффективны касательно работы с памятью, правда если все проперти так же являются value типами.
Спасибо. Ранее не слышал про Frida. Но мне было бы жалко столько времени потратить на простую подмену возвращаемого значения. Я предпочитаю свизлинг, у меня всегда в проекте есть один ObjC файл именно для такого рода баловства и я знаю, что ничего не сломаю в продакшене, потому что он у меня никогда не коммитается.
Миша, тут выдали мне 16 года прошку 17 с тачбаром на i7 с 4-мя ядрами, по сравнению с 13-шкой на i5 14 года прирост примерно на 30%, на проекте время с 9 минут упало до 6. Довольно приятно, но ожидал немного большего.
Вы rxswift используете? аппкод не видит проперти биндинги к эпловым классам, например tableView.rx. и дальше не работает, только показывает базовые методы, хотя в тоже время если написать по памяти то потом в дефинишен переходит без проблем. Поэтому постоянно пишу в обоих IDE, пока в одном автокоплишен отваливается или подсветка синтаксиса пишу в другом и на оборот.
Спасибо. К сожалению Xcode 9 beta не решает проблему со скоростью компиляции, хотя там и добавили «New build system», по моим расчетам она дает максимум 10% к скорости компиляции. Сижу надеюсь к осени улучшат.
После перехода не получили проблем с временем компиляции проекта? И вообще баговости xcode, в частности рандомной рекомпиляции проекта и отваливание подсветки синтаксиса? Размер приложения и время старта не сравнивали до и после перехода?
getArray лучше вынести из структуры в протокол с ассоциативным типом или как генерик расширение для data, чтобы сделать его более общим. Парсинг json'а в структуры отдал бы на сторону json парсеров библиотек, коих уже сотни. Вообще мы подсели на Rx + RxMoya (обертка над Alamofire) + любая json парсилка.
1. Добавил некоторые JVM флаги ( stackoverflow.com/questions/5651538/speedup-intellij-idea). После настроек сделал max 2Gb и min 1Gb и это оказалось лучше чем я когда выставлял max 7Gb, все равно AppCode всегда показывает использование памяти ок 800Мб.
2. Комплишен оооочень медленный, в итоге убрал галочки на smart и base completion, мне важно чтобы комплит появлялся, то что он мне помогал бы не совсем важно, иначе с этими галочками приходится по 5 — 10 секунд ждать первые подсказки, а без них всего пару секунд. Еще есть хак, если нужно вызвать метод или переменную из локального скоупа (class/struct/etc) то нужно всегда писать self. тогда видимо отсекаются глобальные области поиска и комплит почти сразу работает. Для глобальных функций/переменных как долго работал так и работает, проще дописать руками или открыть Xcode и там написать и потом обратно переключиться.
Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode. Тесты проводились следующим образом.
Xcode:
1. Закрыл Xcode
2. Почистил DerivedData (Library/.../Xcode/DerivedData)
3. Открыл Xcode и сразу нажал запустить проект на симуляторе (то есть полная сборка + запуск)
Время на всё ушло 3:50-4:00 минуты в Xcode
AppCode, тоже самое, только чистил его DerivedData (../Caches/../AppCode 2019/../DerivedData/) и AppCode мне выдавал больше 5 минут (нажимал на жука чтобы включить отладку я так понимаю).
Еще мне очень сильно не нравится в 2019 после 2018 версии, что довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20, то есть IDE UI не блокирован, но если попробовать посмотреть описание любой переменной или функции в классе (да хочь чего) через cmd+touchpad то ничего не показывает, если нажать на любой (тут я подчеркиваю, что работа с другой нетронутой функцией, а не которая была переименована) вызов функции то не переходит в ее дефенишен и более того эта функция даже не подсвечивается (что по ней можно перейти).
Еще замечаю (любая версия IDE), что бывают выражения, которые программа с другом вывозит. Вот например внутри функции был код
вот после того как написал знак деления сразу стали видны лаги UI причем постоянные толи пока курсор не убрал с этой линии, толи пока выражение не дописал, но суть в том, что после знака деления комплит наотрез отказался работать (ну или ждать минуту надо). Подобное поведение встречается в сложных выражениях и автокомплит работает после полуминуты ожидания. Ужас.
Очень плохо резолвится chaining, прям проблема
Тут всегда даже подсветка не работает, я уже не говорю, что не может вывести тип. Такое часто когда тип объекта object из другого модуля.
2019 версия стала подсвечивать больше кода, конечно есть участки где IDE не может понять, но их стало меньше — за это спасибо.
Уже не помню, но вроде компишен дженериков тоже очень плохо работает
Вот всегда при объявлении подобных переменных тип приходится писать руками, автокомплит молчит.
На мой взгляд rebase очень удобен только при работе в своей feature ветке для выравнивания с общей (develop) веткой. С shared ветками довольно проблематично, учитывая, что в среднем многие разработчики не очень сильно разбираются в таких тонкостях, проще просто не создавать проблем коллегам и просто использовать merge. Вливание в основную ветку у нас в целом заведено делать через megre с опцией —no-ff.
— По rx будут примеры, сейчас с ходу не могу найти.
— Про associatedType еще раз проверил в чистом проекте и поведение отличное от Xcode.
Перейдите в definition для Item в UserService и AppCode перейдет в протокол, а Xcode перейдет в структуру.
Еще переименование методов приватных протоколов или классов может зафризить IDE очень долго, как будто идет поиск по всему проекту, ведь это всё private, что там так долго делать я до сих пор понять не могу. Приходится убивать IDE так как на cancel она не отменяет renaming. После перезапуска она может не сохранить последнюю минуту работы. Вот эти мелкие косяки портят общее впечатление о продукте.
Оффтоп, был раз кейс когда в релизной конфигурации (максимально агрессивные оптимизации) почему-то объект в одном месте внезапно умирал и приложение падало в segmentation fault. Добавление строчки print(object) перед обращением к объекту решило проблему. Swift был 2-ой или 3-ий.
будем надеяться)
если вы знаете какие-то интересные библиотеки, был бы очень признателен за информацию, можно в личку. Спасибо.