Что делают методы attach и detach у Fragment и когда они вызываются в Android

Что проверяют

Различаете ли вы два разных набора: колбэки жизненного цикла onAttach и onDetach у самого фрагмента и операции транзакции attach() и detach() у FragmentTransaction. Названия похожи, но это разные вещи, и путаница здесь показывает, что жизненный цикл учили по пересказам.

Как отвечать

Разведите их прямо в ответе.

onAttach(Context) это первый колбэк фрагмента: он получил хост, аргументы уже доступны, но View ещё нет. onDetach() последний, вызывается после onDestroy, фрагмент теряет связь с активностью.

Операции транзакции работают с фрагментом, который уже добавлен в менеджер. detach(fragment) уничтожает только иерархию View: доходит до onDestroyView, состояние сохраняется, экземпляр фрагмента остаётся в FragmentManager, его жизненный цикл опускается до CREATED. attach(fragment) возвращает его обратно через onCreateView и onViewCreated, а дальше поднимает до состояния хоста.

Полезно сравнить с соседями: remove() выкидывает фрагмент из менеджера целиком, hide() и show() только переключают видимость, оставляя вёрстку в памяти. detach и attach это середина: тяжёлую разметку выгружаем, объект и его данные держим.

supportFragmentManager.commit {
    detach(fragment)
    attach(fragment)
}

Такая пара пересобирает вёрстку, например после смены языка в настройках.

Где спотыкаются

Говорят, что attach() вызывается при создании фрагмента. Фрагмент добавляют через add() или replace(), а attach() осмыслен только для того, кого ранее открепили.

Считают, что при detach View сохраняется и вернётся та же самая. View уничтожается, поэтому ссылку на биндинг обязательно обнуляют в onDestroyView: фрагмент живёт дольше своей вёрстки, и удержанная ссылка это утечка.

Отвечают, что detach происходит при повороте экрана. При смене конфигурации фрагмент пересоздаётся вместе с активностью или восстанавливается менеджером, а состояние переживает поворот через ViewModel и onSaveInstanceState.