🧬 Управление памятью: SideTable, RefCount, HeapObject, Object Lifecycle

Продолжаем углубляться в тему управления памятью. На этот раз мы углубимся в исходники Swift и узнаем для чего нужны:
🟣SideTable: когда создается и зачем нужна
🟣RefCount: какие бывают счетчики ссылок
🟣Зачем нужен HeapObject
🟣Object Lifecycle и жизненного цикла объекта:
🟣И другое

С этим материалом вы закрепите понимание более глубоких вещей и хорошо прокачаетесь. До конца января я хочу еще разборать темы с Copyable, borrowing and consuming, Memory Safety и другие непопулярные вещи. Поэтому статей будет больше.

Предыдущие статьи:
🔘Управление памятью в iOS: Stack, Heap, RAM
🔘Управление памятью: MRC/MRR, ARC, Auto Release, Memory Leaks
🔘100 вопросов для подготовки к собеседованию по управлению памятью

Наверное, это уже самый объемный публичный материал про память в рунете.

💎 Поддержать или получить доступ к материалам можно в бусти
🧬 И в боте трибьюта если вы не из СНГ (рекомендовано)

Размер имеет значение: исследование виртуальной памяти в iOS

Тренд на знание базы непоколебимо двигается вперед. Индустрия давно не придумала ничего нового, а желание разрабов конкурировать никуда не уходит. Так она выходит за границы стандартных вопросов про устройство SDK, фреймворков и либ. Начинает расширяться с помощью систем дизайна и алгоритмов. Углубляться, с помощью знаний архитектур и систем. Рилсы и шортсы все чаще выходят с разбором популярных алгосиков, а статьи про кишки.

Мы же давно разбираем эту тему, потому что просто нравится. В комментах прошлых постах мы обсуждали область применения кишков и вот попалась под руку статья, где автор с помощью знаний базы помог проекту:

При отладке крупного iOS-приложения на устройстве автор столкнулся с постоянными сбоями приложения сразу после запуска. Это мешало выявлению и исправлению ошибок.

Автор выяснил, что в iOS размер виртуального адресного пространства зависит от объема физической памяти устройства. Например, устройства с более чем 3 ГБ ОЗУ имеют адресное пространство 15,375 ГБ, из которых только 7,375 ГБ доступны для процесса. Остальная часть зарезервирована системой.

При отладке большие двоичные файлы с отладочной информацией занимают значительную часть доступного адресного пространства. В случае автора, суммарный размер исполняемого файла и библиотек превышал 3 ГБ, оставляя менее 370 МБ для кучи и стека потоков, что приводило к сбоям из-за нехватки памяти.

В iOS 14 было введено право Extended Virtual Addressing, позволяющее процессу использовать полное 64-битное адресное пространство. Добавив это право в файл прав приложения для отладочных сборок, автор смог устранить сбои, связанные с нехваткой памяти, и продолжить отладку.

🏥 Вывод:
Понимание особенностей виртуальной памяти в iOS и использование новых возможностей системы, таких как Extended Virtual Addressing, могут помочь разработчикам эффективно решать проблемы, связанные с ограничениями памяти при разработке и отладке приложений.

🧬 Flow: путь познания и создания смыслов

На прошлой недели, в посте про поиск глубины, Вася Усов дал комментарий:

Между «знанием» и «познанием» тонкая грань, но разница все же есть. По моему мнению, Лев, ты занимаешься познанием, поэтому читать тебя интересно. Было бы круто окунуться в тему чуть глубже.

Вася автор замечательной книги, которую я сам начинал читать еще ~7 лет назад, когда только начал изучать iOS. Слова Васи очень приятны, так как он сам авторитетный автор книг и разработчик. Приятно, когда такие слова говорят именно такие люди. Значит я двигаюсь в правильном направлении.

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

Я также находил похожие смыслы о познании в "потоке". Где ты стараешься двигаться по заключительному пути "создания смыслов". Для полного счастья человек должен найти одну осмысленную картину, а не бегать за времеными удовольствиями. Копаться в кишках, формулировать ту самую инженерность, искать практическую пользу своего ремесла, идти по пути познанию мне нравится больше, чем бегать за офферами или грейдами, в чем я все меньше перестаю видеть смысл. Такими же людьми мне хочется себя окружать.

До тех пор пока занятия и увлечения, приносящие нам удовлетворение, не связаны воедино высшим смыслом, мы не защищены от вторжения хаоса и разрушения нашей психической энергии

Мне нравятся такие люди, чей вес в индустрии познается делом и знаниями. Видно, что такой человек нашел ту самую редкую "высшую цель", чей интерес подпитывается ядерным реактором жажды знаний. Этот голод нельзя утолить и он не превращается в алчность.

Множество отличных и сильных разработчиков стараются не марать себя темами про бабки или крысиными бегами за грейды. Это, кстати, мы также подтвердили в опросе.

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

Конечно, слова "высшая цель" звучат довольно пафосно. Но моя она как раз совсем недавно сформулировалась.

Можете чаще давать приятные слова в комментах и я буду вас рекламировать😏

Шпаргалки для подготовки к System Design

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

Так я начал заполнять впервую очередь для себя темами, чтобы быстро войти в контекст стандартного формата интервью. Вообще я понял, что проходить интервью совсем другой скилл. Когда же вопросы для собеседований можно легко зазубрить, а легенду выдумать, то на алгоритмах или архитектуре ты сильно дебафаешься и тут почти невозможно обмануть интервьюера.

Ну и немного кринжа. Твой накрученный опыт или скиллы будут бросаться в глаза как паленные вещи абибас. А выдуманная "сеньорность" легко палится. О чем говорить, если даже можно банально зайти в ютуб с накрученным мок-собесом. Где зритель жалуется, что "данные знания не соответствуют сеньорным". Как же тогда у вас получится обмануть интервьюера, если даже не получается аудиторию?

Я все же сторонник прозрачного и честного роста впервую очередь перед самим собой. Живя в парадигме "как бы кого обмануть" ты становишься экспертом только в подделках, но не в оригиналах. Главное правило любого развития — честные показатели. Казаться научит любой ментор или даже чатгпт, заготовив методичку. А вот быть нужно регулярным трудом самому.

Мы за регулярный рост. Я собрал уже две статьи:
🟣Как и какие собирать требования к задаче
🟣Что такое DI и как его выбирать
В будущем буду обновлять темы (масштабирование, архитектура, модуляризация, тесты и тп)

💎 Поддержать или получить доступ к материалам можно в бусти
🧬 И в боте трибьюта если вы не из СНГ (рекомендовано)