Эта страница переведена с помощью Cloud Translation API.

Отладка фрагментов

В этом руководстве рассматриваются инструменты, которые можно использовать для отладки фрагментов .

Ведение журнала FragmentManager

FragmentManager может отправлять в Logcat различные сообщения. По умолчанию это отключено, но иногда эти сообщения журнала могут помочь вам устранить проблемы с вашими фрагментами. FragmentManager выдает наиболее значимые выходные данные на уровнях журнала DEBUG и VERBOSE .

Вы можете включить ведение журнала, используя следующую команду adb shell :

adb shell setprop log.tag.FragmentManager DEBUG

Альтернативно вы можете включить подробное ведение журнала следующим образом:

adb shell setprop log.tag.FragmentManager VERBOSE

Если вы включите подробное ведение журнала, вы сможете применить фильтр уровня журнала в окне Logcat. Однако при этом фильтруются все журналы, а не только журналы FragmentManager . Обычно лучше включать ведение журнала FragmentManager только на том уровне журнала, который вам нужен.

ведение журнала отладки

На уровне DEBUG FragmentManager обычно выдает сообщения журнала, относящиеся к изменениям состояния жизненного цикла. Каждая запись журнала содержит дамп toString() из Fragment . Запись журнала состоит из следующей информации:

Простое имя класса экземпляра Fragment .
Идентификатор хеш-кода экземпляра Fragment .
Уникальный идентификатор экземпляра фрагмента диспетчера Fragment . Это стабильно при изменении конфигурации, а также при смерти и восстановлении процесса.
Идентификатор контейнера, в который добавляется Fragment , но только если он установлен.
Тег Fragment , но только если он установлен.

Ниже приведен пример записи журнала DEBUG :

D/FragmentManager: moveto ATTACHED: NavHostFragment{92d8f1d} (fd92599e-c349-4660-b2d6-0ece9ec72f7b id=0x7f080116)

Класс Fragment — NavHostFragment .
Идентификационный хеш-код — 92d8f1d .
Уникальный идентификатор: fd92599e-c349-4660-b2d6-0ece9ec72f7b .
Идентификатор контейнера — 0x7f080116 .
Тег опущен, поскольку он не был установлен. Если он присутствует, он следует за идентификатором в формате tag=tag_value .

Для краткости и удобства чтения UUID в следующих примерах сокращены.

Вот инициализируется NavHostFragment , а затем создается Fragment startDestination типа FirstFragment и переходит в состояние RESUMED :

D/FragmentManager: moveto ATTACHED: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager:   mName=null mIndex=-1 mCommitted=false
D/FragmentManager:   Operations:
D/FragmentManager:     Op #0: SET_PRIMARY_NAV NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager: moveto CREATED: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager:   mName=null mIndex=-1 mCommitted=false
D/FragmentManager:   Operations:
D/FragmentManager:     Op #0: REPLACE FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager:     Op #1: SET_PRIMARY_NAV FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto ATTACHED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto CREATED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto CREATE_VIEW: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager: moveto CREATE_VIEW: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto ACTIVITY_CREATED: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager: moveto RESTORE_VIEW_STATE: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager: moveto ACTIVITY_CREATED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto RESTORE_VIEW_STATE: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto STARTED: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager: moveto STARTED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto RESUMED: NavHostFragment{92d8f1d} (<UUID> id=0x7f080116)
D/FragmentManager: moveto RESUMED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)

После взаимодействия с пользователем FirstFragment выходит из различных состояний жизненного цикла. Затем создается экземпляр SecondFragment и он переходит в состояние RESUMED :

D/FragmentManager:   mName=07c8a5e8-54a3-4e21-b2cc-c8efc37c4cf5 mIndex=-1 mCommitted=false
D/FragmentManager:   Operations:
D/FragmentManager:     Op #0: REPLACE SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager:     Op #1: SET_PRIMARY_NAV SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: movefrom RESUMED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: movefrom STARTED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: movefrom ACTIVITY_CREATED: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto ATTACHED: SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: moveto CREATED: SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: moveto CREATE_VIEW: SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: moveto ACTIVITY_CREATED: SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: moveto RESTORE_VIEW_STATE: SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: moveto STARTED: SecondFragment{84132db} (<UUID> id=0x7f080116)
D/FragmentManager: movefrom CREATE_VIEW: FirstFragment{ccd2189} (<UUID> id=0x7f080116)
D/FragmentManager: moveto RESUMED: SecondFragment{84132db} (<UUID> id=0x7f080116)

Все экземпляры Fragment имеют суффикс идентификатора, чтобы вы могли отслеживать разные экземпляры одного и того же класса Fragment .

ПОДРОБНОЕ ведение журнала

На уровне VERBOSE FragmentManager обычно выдает сообщения журнала о своем внутреннем состоянии:

V/FragmentManager: Run: BackStackEntry{f9d3ff3}
V/FragmentManager: add: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: Added fragment to active set NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto ATTACHED: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: Commit: BackStackEntry{5cfd2ae}
D/FragmentManager:   mName=null mIndex=-1 mCommitted=false
D/FragmentManager:   Operations:
D/FragmentManager:     Op #0: SET_PRIMARY_NAV NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto CREATED: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: Commit: BackStackEntry{e93833f}
D/FragmentManager:   mName=null mIndex=-1 mCommitted=false
D/FragmentManager:   Operations:
D/FragmentManager:     Op #0: REPLACE FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager:     Op #1: SET_PRIMARY_NAV FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: Run: BackStackEntry{e93833f}
V/FragmentManager: add: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: Added fragment to active set FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto ATTACHED: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto CREATED: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 1 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto CREATE_VIEW: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 2 for FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto CREATE_VIEW: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 2 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 2 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto ACTIVITY_CREATED: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto RESTORE_VIEW_STATE: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto ACTIVITY_CREATED: FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto RESTORE_VIEW_STATE: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: SpecialEffectsController: Enqueuing add operation for fragment FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: SpecialEffectsController: For fragment FirstFragment{886440c} (<UUID> id=0x7f080130) mFinalState = VISIBLE -> VISIBLE.
V/FragmentManager: SpecialEffectsController: Container androidx.fragment.app.FragmentContainerView{7578ffa V.E...... ......I. 0,0-0,0 #7f080130 app:id/nav_host_fragment_content_fragment} is not attached to window. Cancelling pending operation Operation {382a9ab} {mFinalState = VISIBLE} {mLifecycleImpact = ADDING} {mFragment = FirstFragment{886440c} (<UUID> id=0x7f080130)}
V/FragmentManager: SpecialEffectsController: Operation {382a9ab} {mFinalState = VISIBLE} {mLifecycleImpact = ADDING} {mFragment = FirstFragment{886440c} (<UUID> id=0x7f080130)} has called complete.
V/FragmentManager: SpecialEffectsController: Setting view androidx.constraintlayout.widget.ConstraintLayout{3968808 I.E...... ......I. 0,0-0,0} to VISIBLE
V/FragmentManager: computeExpectedState() of 4 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: SpecialEffectsController: Enqueuing add operation for fragment NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: SpecialEffectsController: For fragment NavHostFragment{86274b0} (<UUID> id=0x7f080130) mFinalState = VISIBLE -> VISIBLE.
V/FragmentManager: SpecialEffectsController: Container androidx.fragment.app.FragmentContainerView{2ba8ba1 V.E...... ......I. 0,0-0,0 #7f080130 app:id/nav_host_fragment_content_fragment} is not attached to window. Cancelling pending operation Operation {f7eb1c6} {mFinalState = VISIBLE} {mLifecycleImpact = ADDING} {mFragment = NavHostFragment{86274b0} (<UUID> id=0x7f080130)}
V/FragmentManager: SpecialEffectsController: Operation {f7eb1c6} {mFinalState = VISIBLE} {mLifecycleImpact = ADDING} {mFragment = NavHostFragment{86274b0} (<UUID> id=0x7f080130)} has called complete.
V/FragmentManager: SpecialEffectsController: Setting view androidx.fragment.app.FragmentContainerView{7578ffa I.E...... ......I. 0,0-0,0 #7f080130 app:id/nav_host_fragment_content_fragment} to VISIBLE
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: Run: BackStackEntry{5cfd2ae}
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 4 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 5 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto STARTED: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 5 for FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto STARTED: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 5 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 5 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 5 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 5 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
D/FragmentManager: moveto RESUMED: NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for FirstFragment{886440c} (<UUID> id=0x7f080130)
D/FragmentManager: moveto RESUMED: FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for FirstFragment{886440c} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)
V/FragmentManager: computeExpectedState() of 7 for NavHostFragment{86274b0} (<UUID> id=0x7f080130)

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

StrictMode для фрагментов

Версия 1.4.0 и выше библиотеки Jetpack Fragment включает StrictMode для фрагментов. Он может обнаружить некоторые распространенные проблемы, которые могут привести к неожиданному поведению вашего приложения. Дополнительные сведения о работе со StrictMode см. в разделе StrictMode .

Пользовательская Policy определяет, какие нарушения обнаруживаются, и определяет, какое наказание применяется при обнаружении нарушений.

Чтобы применить пользовательскую политику StrictMode, назначьте ее FragmentManager . Сделайте это как можно раньше. В этом случае вы делаете это в блоке init или в конструкторе Java:

Котлин

class ExampleActivity : AppCompatActivity() {

    init {
        supportFragmentManager.strictModePolicy =
            FragmentStrictMode.Policy.Builder()
                .penaltyDeath()
                .detectFragmentReuse()
                .allowViolation(FirstFragment::class.java,
                                FragmentReuseViolation::class.java)
                .build()
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val binding = ActivityExampleBinding.inflate(layoutInflater)
        setContentView(binding.root)
        ...
   }
}

Ява

class ExampleActivity extends AppCompatActivity() {

    ExampleActivity() {
        getSupportFragmentManager().setStrictModePolicy(
                new FragmentStrictMode.Policy.Builder()
                        .penaltyDeath()
                        .detectFragmentReuse()
                        .allowViolation(FirstFragment.class,
                                        FragmentReuseViolation.class)
                        .build()
        );
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState)

        ActivityExampleBinding binding =
            ActivityExampleBinding.inflate(getLayoutInflater());
        setContentView(binding.getRoot());
        ...
   }
}

В случаях, когда вам необходимо знать Context , чтобы определить, следует ли включать StrictMode, например, по значению логического ресурса, вы можете отложить назначение политики StrictMode для FragmentManager с помощью OnContextAvailableListener :

Котлин

class ExampleActivity : AppCompatActivity() {

    init {
        addOnContextAvailableListener { context ->
            if(context.resources.getBoolean(R.bool.enable_strict_mode)) {
                supportFragmentManager.strictModePolicy = FragmentStrictMode.Policy.Builder()
                    .penaltyDeath()
                    .detectFragmentReuse()
                    .allowViolation(FirstFragment::class.java, FragmentReuseViolation::class.java)
                    .build()
            }
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val binding = ActivityExampleBinding.inflate(layoutInflater)
        setContentView(binding.root)
        ...
   }
}

Ява

class ExampleActivity extends AppCompatActivity() {

    ExampleActivity() {
        addOnContextAvailableListener((context) -> {
            if(context.getResources().getBoolean(R.bool.enable_strict_mode)) {
                getSupportFragmentManager().setStrictModePolicy(
                        new FragmentStrictMode.Policy.Builder()
                                .penaltyDeath()
                                .detectFragmentReuse()
                                .allowViolation(FirstFragment.class, FragmentReuseViolation.class)
                                .build()
                );
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState)

        ActivityExampleBinding binding = ActivityExampleBinding.inflate(getLayoutInflater());
        setContentView(binding.getRoot());
        ...
   }
}

Последний момент, когда вы можете настроить StrictMode для обнаружения всех возможных нарушений, — это onCreate() , перед вызовом super.onCreate() :

Котлин

class ExampleActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        supportFragmentManager.strictModePolicy = FragmentStrictMode.Policy.Builder()
            .penaltyDeath()
            .detectFragmentReuse()
            .allowViolation(FirstFragment::class.java, FragmentReuseViolation::class.java)
            .build()

        super.onCreate(savedInstanceState)

        val binding = ActivityExampleBinding.inflate(layoutInflater)
        setContentView(binding.root)
        ...
   }
}

Ява

class ExampleActivity extends AppCompatActivity() {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        getSupportFragmentManager().setStrictModePolicy(
                new FragmentStrictMode.Policy.Builder()
                        .penaltyDeath()
                        .detectFragmentReuse()
                        .allowViolation(FirstFragment.class, FragmentReuseViolation.class)
                        .build()
                );

        super.onCreate(savedInstanceState)

        ActivityExampleBinding binding = ActivityExampleBinding.inflate(getLayoutInflater());
        setContentView(binding.getRoot());
        ...
   }
}

Эта политика, используемая в этих примерах, обнаруживает только нарушения повторного использования фрагментов, и приложение завершает работу всякий раз, когда они происходят. penaltyDeath() может быть полезен в отладочных сборках, поскольку он дает сбой достаточно быстро, и вы не можете игнорировать нарушения.

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

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

Подробную информацию о настройке других нарушений см. в документации FragmentStrictMode.Policy.Builder .

Существует три вида штрафов.

penaltyLog() передает подробную информацию о нарушениях в Logcat.
penaltyDeath() завершает работу приложения при обнаружении нарушений.
penaltyListener() позволяет добавить собственный прослушиватель, который вызывается при обнаружении нарушений.

Вы можете применять любую комбинацию штрафов в своем Policy . Если ваша политика явно не определяет штраф, применяется значение по умолчанию penaltyLog() . Если вы применяете в своей пользовательской Policy штраф, отличный от penaltyLog() , то penaltyLog() отключается, если вы не установили его явно.

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

Чтобы установить глобальную политику StrictMode, установите политику по умолчанию, которая применяется ко всем экземплярам FragmentManager , с помощью метода FragmentStrictMode.setDefaultPolicy() :

Котлин

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()

        FragmentStrictMode.defaultPolicy =
            FragmentStrictMode.Policy.Builder()
                .detectFragmentReuse()
                .detectFragmentTagUsage()
                .detectRetainInstanceUsage()
                .detectSetUserVisibleHint()
                .detectTargetFragmentUsage()
                .detectWrongFragmentContainer()
                .apply {
                    if (BuildConfig.DEBUG) {
                        // Fail early on DEBUG builds
                        penaltyDeath()
                    } else {
                        // Log to Crashlytics on RELEASE builds
                        penaltyListener {
                            FirebaseCrashlytics.getInstance().recordException(it)
                        }
                    }
                }
                .build()
    }
}

Ява

public class MyApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        FragmentStrictMode.Policy.Builder builder = new FragmentStrictMode.Policy.Builder();
        builder.detectFragmentReuse()
                .detectFragmentTagUsage()
                .detectRetainInstanceUsage()
                .detectSetUserVisibleHint()
                .detectTargetFragmentUsage()
                .detectWrongFragmentContainer();
        if (BuildConfig.DEBUG) {
            // Fail early on DEBUG builds
            builder.penaltyDeath();
        } else {
            // Log to Crashlytics on RELEASE builds
            builder.penaltyListener((exception) ->
                    FirebaseCrashlytics.getInstance().recordException(exception)
            );
        }
        FragmentStrictMode.setDefaultPolicy(builder.build());
    }
}

В следующих разделах описаны типы нарушений и возможные обходные пути.

Повторное использование фрагментов

Нарушение повторного использования фрагмента включается с помощью detectFragmentReuse() и выдает FragmentReuseViolation .

Это нарушение указывает на повторное использование экземпляра Fragment после его удаления из FragmentManager . Такое повторное использование может вызвать проблемы, поскольку Fragment может сохранить состояние предыдущего использования и вести себя нестабильно. Если вы каждый раз создаете новый экземпляр, он всегда находится в исходном состоянии при добавлении в FragmentManager .

Использование тега фрагмента

Нарушение использования тега фрагмента включается с помощью detectFragmentTagUsage() и выдает FragmentTagUsageViolation .

Это нарушение указывает на то, что Fragment раздувается с помощью тега <fragment> в макете XML. Чтобы решить эту проблему, раздуйте свой Fragment внутри <androidx.fragment.app.FragmentContainerView> а не в теге <fragment> . Фрагменты, раздутые с помощью FragmentContainerView могут надежно обрабатывать транзакции Fragment и изменения конфигурации. Они могут работать не так, как ожидалось, если вместо этого вы используете тег <fragment> .

Сохранять использование экземпляра

Нарушение использования экземпляра сохранения включается с помощью detectRetainInstanceUsage() и выдает RetainInstanceUsageViolation .

Это нарушение указывает на использование сохраненного Fragment , в частности, если есть вызовы setRetainInstance() или getRetainInstance() , которые оба устарели.

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

Установить видимую пользователю подсказку

Нарушение подсказки, установленной пользователем, включается с помощью detectSetUserVisibleHint() и выдает SetUserVisibleHintViolation .

Это нарушение указывает на вызов метода setUserVisibleHint() , который устарел.

Если вы вызываете этот метод вручную, вместо этого вызовите setMaxLifecycle() . Если вы переопределите этот метод, переместите поведение в onResume() при передаче true и onPause() при передаче false .

Использование целевого фрагмента

Нарушение использования целевого фрагмента включается с помощью detectTargetFragmentUsage() и выдает TargetFragmentUsageViolation .

Это нарушение указывает на вызов методов setTargetFragment() , getTargetFragment() или getTargetRequestCode() , которые устарели. Вместо использования этих методов зарегистрируйте FragmentResultListener . Дополнительные сведения о передаче результатов см. в разделе Передача результатов между фрагментами .

Неправильный контейнер фрагментов

Нарушение контейнера неправильного фрагмента включается с помощью detectWrongFragmentContainer() и выдается WrongFragmentContainerViolation .

Это нарушение указывает на добавление Fragment в контейнер, отличный от FragmentContainerView . Как и в случае с использованием тега Fragment , транзакции фрагментов могут работать не так, как ожидалось, если они не размещены внутри FragmentContainerView . Использование представления контейнера также помогает решить проблему в API View , из-за которой фрагменты, использующие анимацию выхода, рисуются поверх всех остальных фрагментов.

Отладка фрагментов Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Ведение журнала FragmentManager

ведение журнала отладки

ПОДРОБНОЕ ведение журнала

StrictMode для фрагментов

Котлин

Ява

Котлин

Ява

Котлин

Ява

Котлин

Ява

Повторное использование фрагментов

Использование тега фрагмента

Сохранять использование экземпляра

Установить видимую пользователю подсказку

Использование целевого фрагмента

Неправильный контейнер фрагментов

Отладка фрагментов