Pull to refresh
25
0
Тимур Шафигуллин @Timbaev

iOS Разработчик

Send message

Да, хочется его попробовать, тем более что у нас получился не самый простой файл конфигурации. Думаю, пощупаем его, когда будем что-то менять/добавлять в файл конфигурации

Привет!
Спасибо за статью, кажется, вы сэкономили нам время на исследование Cilicon и tart, потому что тоже уже очень хотим двигаться в эту сторону.

Интересно было бы узнать, как вы совмещаете Ruby и Swift? У нас сейчас вся инфра в основном на Ruby (Fastlane и куча логики вокруг него), но хотим подумать в сторону Swift, чтобы большая часть инфры была на ней. Может уже смотрели в эту сторону, были ли с этим у вас какие-то сложности/интересные моменты?

Классно, что наш опыт пригодился, не стесняйтесь задавать вопросы, если будут! Можно, например, в наш Telegram чатик

Спасибо за комментарий и обратную связь!

Спасибо за указанные ошибки, я вполне мог что-то упустить при исследовании сторонних решений(

Согласен с ContextTask, можно использовать его для обновления данных на экране, странно что не увидел этого в доке при разработке демо-приложения ?

Возможно для каких-то кейсов требуется более сильное погружение в библиотеку, где-то могло не хватить документации.

1) Ох, это моя ошибка/недоглядка, тут вы совершенно правы, спасибо, что подметили, я поправлю!
2) Да, еще раз спасибо за замечание, помогаете сделать статью еще лучше :)
Вы верно описали, я ошибся тут, что unowned прибавляет к strong, как раз такие наоборот, strong прибавляет к unowned, а unowned к weak. Также поправлю


И да, это все для корректной работы state машины только необходимо.
С меня плюсы причитаются :)

Тема коллекций на самом деле достаточная большая, но если кратко, то Array в Swift представляет из себя некую обертку над данными, и позволяет соблюсти value семантику языка (данные неизменяемые, копируемые и тп). Это структура, у которой всегда известен заранее размер для MemoryLayout. А сами данные уже размещаются динамично в других участках памяти, на которые Array имеет ссылки. Именно поэтому MemoryLayout нам не отдает "настоящий" размер массива.


Также об этом сказано в документации метода size(ofValue:)


The result does not include any dynamically allocated or out of line storage. In particular, pointers and class instances all have the same contiguous memory footprint, regardless of the size of the referenced data.

Да, все так
Об этом еще описано в блоке Инварианты счетчиков ссылок

Спасибо за хороший вопрос! Насчет размера — я затрудняюсь сразу ответить, но могу предположить, что меньше, использую int32 для счетчиков. Сама SideTable представляет из себя такое хранилище, то есть может иметь еще дополнительные флаги:


HeapObjectSideTableEntry {
  SideTableRefCounts {
    object pointer
    atomic<SideTableRefCountBits> {
      strong RC + unowned RC + weak RC + flags
    }
  }   
}

Саму реализацю SideTable можно посмотреть тут
Я попробую покопать и узнать примерные размеры и вернусь к вам с ответом)


Второй вопрос, про то, когда удаляются боковые таблицы — да, проверка осуществляется при обращении по ссылке, поэтому важно, чтобы SideTable была максимально маленькой.

Information

Rating
Does not participate
Location
Казань, Татарстан, Россия
Works in
Registered
Activity