Неочевидные вопросы с собесов

Технические пост про вопросы, которые были на недавних собесах⬇️⬇️⬇️

Disclaimer: не буду приводить очень подробных ответов, дам короткие, при необходимости сможете поискать по ним более подробную информацию.

1️⃣ Допустим при вставке в HashMap произойдет коллизия и в один бакет попадет много элементов, список поменятся на красно-черное дерево. На основе чего будет балансироваться это дерево, если ключи не наследуют Comparable

Ответ:
Для этого случая используется метод System.identityHashCode(obj: Object). Он всегда возвращает уникальный хэшкод для объекта, который связан с местом в памяти где он хранится. Кстати, он же используется для дефолтной реализации hashCode()

2️⃣ Когда лучше использовать Serializable чем Parcelable ?

Ответ(спорный, но его ждал интервьюер):
Несмотря на то что Parcelable быстрее и для большинства кейсов более предпочтителен, при сериализации объектов на диск или БД лучше использовать Serializable, т.к. при изменении структуры класса, Serializable позволит не потерять данные. В Parcelable сложно поддерживать структуру, если нарушить порядок записи или чтения данных, будут проблемы с восстановлением объекта.

3️⃣ inline функции - на чем все таки экономим

Ответ:
Inline имеет смысл использовать в функциях высшего порядка (т.к. тех, которые имею лямбды в параметрах) и часто принято отвечать на этот вопрос, что экономия достигается за счет того что не будут созданы объекты типа FunctionX. Обычно такой ответ удовлетворяет интервьюера, но не всегда. На самом деле нет ничего страшного в создании дополнительного объекта, есть кое-что потяжелее, на чем позволяет экономить inline, а именно на замыканиях (closure). Closure (замыкание) — это функция, которая захватывает переменные из своей внешней области видимости и может использовать их даже после завершения выполнения этой области.

4️⃣ Как работают под капотом Atomic-и

Ответ:
Внутри класса переменная, с которой работает Atomic, объявлена как volatile. Это гарантирует видимость изменений переменной между потоками, так как volatile обязывает процессор и память синхронизировать значение. Atomic-и поддерживают потокобезопасные операции с переменными без использования блокировок (lock, sychronized). Это достигается благодаря использованию низкоуровневых примитивов процессора, таких как CAS (Compare-And-Swap).

5️⃣ Choreographer и методы invalidate / requestLayout

Ответ:
Choreographer — это системный класс Android, который управляет таймингом для обновления UI. Он используется для синхронизации операций отрисовки с частотой обновления экрана (vsync).
invalidate() и requestLayout() добавляют задачи в очередь на следующий кадр через Choreographer. Это гарантирует, что изменения произойдут синхронно с циклом отрисовки. При этом:
- invalidate() добавляет задачу отрисовки.
- requestLayout() добавляет задачу измерения и расположения.
- Т.о. requestLayout() не вызовет перерисовку, для нее нужно вызвать invalidate()
Если вызвать invalidate() 100 раз - Choreographer схлопнет вызовы до одного, перерисовка не вызовется 100 раз.

💥Если готовитесь на позицию Middle/Senior разработчик, будьте готовы к вопросам про коллекции, многопоточку, GC, корутины, custom views - как правило на эти темы заходит разговор практически на любом собесе, чем выше грейд, тем больше вопросов вглубь о том как это работает под капотом. Часть из таких вопросов я сегодня и привел, надеюсь для кого-то будет полезно.