Судя по всему, какое-то время назад ваше решение считалось приватным апи, поэтому не известно широкой публике (что, конечно, не умаляет костыльности решения с проигрыванием пустого звука)
Флагов -F у нас немного (порядка десятков), так как при сборке мы не используем фреймворки, за исключением бинарных. Подавляющее количество флагов — -Xcc -fmodule-map-file=... — их около тысячи.
Я правильно понял, что чем больше либ на objc содержит твой podfile, тем хорошо если квадратично больше время запуска дебаггера?
Не совсем так, взрывной рост флажков clang-а вызывает как раз рост количества Swift-модулей, а не ObjC. Как можно понять из нашего локального решения, позволившего смягчить проблему, если бы у вас был один Swift-модуль на все приложение, описанное в статье на вас бы не повлияло :)
Тем не менее, это не делает ваше наблюдение неправильным, ведь у cocoapods своя атмосфера. Вот пара фактов:
1. Даже если под написан только на Swift без примесей ObjC, поды добавляют к нему сгенерированные заголовок и m-файл.
2. Каждому поду в header search paths записываются пути поиска до всех остальных подов, вне зависимости от того, от чего он на самом деле зависит (простите за каламбур).
Вследствие этих фактов получаем такую картину: допустим, у нас были поды A, B, C, все на Swift. Поды сгенерируют проект таким образом, что, в числе прочих, у Swift-модулей будут такие флажки:
И, таким образом, количество флажков возросло с 6 до 12 (в асимптотике тут будет квадратичный рост: всего их будет N * (N - 1)). Напомню, что, как мы уже выяснили в статье, все эти флажки склеятся, несмотря на то, что они дублируют друг друга.
Давайте добавим еще один под E, но уже на ObjC. Для него не будет Swift-модуля, пагубным образом влияющего на дебаггер, поэтому картина будет такая:
Количество флажков возросло с 12 до 16, но, если бы модуль E содержал Swift (или был бы полностью на нем, это уже никакой роли не играет), то мы бы увидели не 16, а целых 20 флажков (т.к. добавилась бы еще такая же строчка для E).
tl;dr: количество флажков при использовании подов растет как M * N, где M — количество подов, использующих Swift (неважно при этом содержат ли они ObjC), а N — общее количество подов (причем во всем этом учитываются не только те поды, которые вы используете непосредственно в вашем приложении, но и их зависимости, которые вы, возможно, напрямую не используете). Таким образом, как ни парадоксально, чем больше доля подов на чистом ObjC, тем меньше взрыв флажков при сборке контекста дебаггера.
Меня мучает такой вопрос: какие преимущества у лазерной коррекции перед ИОЛ? Вроде как замена хрусталика — операция, которая отработана на огромном количестве пациентов с катарактой, риск осложнений минимален, и, насколько я знаю, ее можно делать повторно без особых ограничений. С другой стороны, лазерная коррекция — это необратимые изменения, и докоррекция там довольно нетривиальна, плюс травмируется Боуменова мембрана.
Я тоже слышал, что Йота использует мегафоновскую физическую сеть, но у меня есть еще одно свидетельство того, что что-то тут нечисто – друг также перешел с Мегафона на Йоту и тоже жалуется на отвратительное качество связи, планирует вернуться обратно.
Возможно, спорить не буду, опыта использования IB у меня нет. Доводилось просто видеть проекты с описанной мной кашей, в которой очень сложно разобраться.
Имхо, смысл не использовать IB есть, когда в приложении сложный UI с большим количеством переходов. В этом случае ваши макеты превратятся в вечнотормозящую (в Xcode) мешанину.
Дело в том, что constraints удобны для использования только в IB. Если отрисовывать интерфейс полностью кодом, то проще реализовать старый добрый layoutSubviews. А уже IB vs программная отрисовка — это отдельная большая тема для рассуждений: в каких-то случаях лучше одно, в других — другое.
Когда добавят поддержку арма и релизных сборок — можно начинать пробовать. Кроме этого из списка в нашем проекте есть только MapKit. Ехидно посмеиваюсь над любителями IB, автолэйаутов и свифта :)
Хм, а как в тройке реализована защита от несанкционированной записи? Иными словами, если хитрый человек каким-либо образом разберет алгоритм пополнения (реверс, утечка информации, etc), то он теоретически сможет ездить бесплатно, ведь карта-то оффлайновая?
Тулза, бесспорно, полезная, но это отнюдь не статический анализатор, а очень даже инструмент для выявления рейсов в рантайме, причем с недетерминированным результатом (нельзя гарантировать, что если рейс есть, то эта тулза его обязательно найдет).
Судя по всему, какое-то время назад ваше решение считалось приватным апи, поэтому не известно широкой публике (что, конечно, не умаляет костыльности решения с проигрыванием пустого звука)
Не скажу про динамику заболеваемости, а вот смертность у них практически на нуле, в отличие от нас, и не растет.
-F
у нас немного (порядка десятков), так как при сборке мы не используем фреймворки, за исключением бинарных. Подавляющее количество флагов —-Xcc -fmodule-map-file=...
— их около тысячи.Не совсем так, взрывной рост флажков
clang
-а вызывает как раз рост количестваSwift
-модулей, а неObjC
. Как можно понять из нашего локального решения, позволившего смягчить проблему, если бы у вас был одинSwift
-модуль на все приложение, описанное в статье на вас бы не повлияло :)Тем не менее, это не делает ваше наблюдение неправильным, ведь у
cocoapods
своя атмосфера. Вот пара фактов:1. Даже если под написан только на
Swift
без примесейObjC
, поды добавляют к нему сгенерированные заголовок иm
-файл.2. Каждому поду в header search paths записываются пути поиска до всех остальных подов, вне зависимости от того, от чего он на самом деле зависит (простите за каламбур).
Вследствие этих фактов получаем такую картину: допустим, у нас были поды
A
,B
,C
, все наSwift
. Поды сгенерируют проект таким образом, что, в числе прочих, уSwift
-модулей будут такие флажки:A
:-Ipath/to/B -Ipath/to/C
B
:-Ipath/to/A -Ipath/to/C
C
:-Ipath/to/A -Ipath/to/B
Теперь мы хотим добавить еще один под
D
, и картина будет выглядеть уже таким образом:A
:-Ipath/to/B -Ipath/to/C -Ipath/to/D
B
:-Ipath/to/A -Ipath/to/C -Ipath/to/D
C
:-Ipath/to/A -Ipath/to/B -Ipath/to/D
D
:-Ipath/to/A -Ipath/to/B -Ipath/to/C
И, таким образом, количество флажков возросло с 6 до 12 (в асимптотике тут будет квадратичный рост: всего их будет
N * (N - 1)
). Напомню, что, как мы уже выяснили в статье, все эти флажки склеятся, несмотря на то, что они дублируют друг друга.Давайте добавим еще один под
E
, но уже наObjC
. Для него не будетSwift
-модуля, пагубным образом влияющего на дебаггер, поэтому картина будет такая:A
:-Ipath/to/B -Ipath/to/C -Ipath/to/D -Ipath/to/E
B
:-Ipath/to/A -Ipath/to/C -Ipath/to/D -Ipath/to/E
C
:-Ipath/to/A -Ipath/to/B -Ipath/to/D -Ipath/to/E
D
:-Ipath/to/A -Ipath/to/B -Ipath/to/C -Ipath/to/E
Количество флажков возросло с 12 до 16, но, если бы модуль
E
содержалSwift
(или был бы полностью на нем, это уже никакой роли не играет), то мы бы увидели не 16, а целых 20 флажков (т.к. добавилась бы еще такая же строчка дляE
).tl;dr: количество флажков при использовании подов растет как
M * N
, гдеM
— количество подов, использующихSwift
(неважно при этом содержат ли ониObjC
), аN
— общее количество подов (причем во всем этом учитываются не только те поды, которые вы используете непосредственно в вашем приложении, но и их зависимости, которые вы, возможно, напрямую не используете). Таким образом, как ни парадоксально, чем больше доля подов на чистомObjC
, тем меньше взрыв флажков при сборке контекста дебаггера.Последние 3 слова в названии метода относятся к параметру.