Почему создание View в Android является дорогой операцией
Что проверяют
Понимаете ли вы, из чего складывается стоимость, и знаете ли, почему из-за этого существует переиспользование в списках.
Как отвечать
Стоимость складывается из нескольких слагаемых, и не все очевидны.
Разбор XML. LayoutInflater читает скомпилированную разметку, и на каждый элемент это чтение атрибутов, разрешение ссылок на ресурсы и темы. Дальше объект создаётся через рефлексию по имени класса, что заметно дороже обычного конструктора.
Создание объектов. Один View это довольно тяжёлый объект: параметры разметки, фон, слушатели, состояние. Сложный элемент списка легко разворачивается в несколько десятков объектов, и всё это нагрузка на сборщик мусора.
Три прохода отрисовки. Каждый новый элемент участвует в измерении, размещении и рисовании. Измерение в глубоко вложенной иерархии может выполняться дважды на уровень: RelativeLayout и LinearLayout с весами измеряют детей повторно, и в глубоком дереве это растёт экспоненциально. Отсюда рекомендация плоской иерархии и ConstraintLayout.
Главный поток. Всё это происходит в потоке интерфейса, а на кадр есть примерно 16 миллисекунд. Развернуть сложный элемент прямо во время прокрутки значит пропустить кадр.
Отсюда и решения: RecyclerView переиспользует держатели вместо создания новых; ViewStub откладывает разворачивание редко нужной части; AsyncLayoutInflater уводит работу с главного потока; merge и ConstraintLayout убирают лишние уровни вложенности.
Про Compose стоит добавить: там нет разворачивания XML и рефлексии, дерево строится из легковесных узлов, а перерисовка точечная. Часть этой стоимости просто исчезает, но появляется своя цена в виде лишних перекомпозиций.
Где спотыкаются
Называют только разбор XML, забывая про рефлексию и измерение.
Не знают про двойное измерение и делают глубокую вложенность.
Создают элементы в onBindViewHolder вместо onCreateViewHolder.
Считают, что RecyclerView быстрее просто потому, что новее.