TransactionTooLargeException с FragmentStatePagerAdapter - PullRequest
0 голосов
/ 29 сентября 2019

Я написал приложение для чтения с использованием ViewPager с offscreenPageLimit по умолчанию 1 и FragmentStatePagerAdapter, в котором у меня есть

override fun getItem(position: Int) = ComicFragment.newInstance(index = position + 1)

Здесь создается ComicFragment с index, который может быть больше 2000,комикс с таким индексом будет загружен во фрагмент.Значение setRetainInstance по умолчанию равно false

Также во фрагменте я сохранил индекс и логическое значение transMode в saveInstanceState, так что когда пользователи проведут несколько страниц назад и назад, они получат страницув том же состоянии, что и было.Также он будет поддерживать состояние при изменениях конфигурации.

Проблема заключается в том, что при каждом удаленном фрагменте из TooLargeTool существует

D/TooLargeTool: ComicFragment.onSaveInstanceState wrote: Bundle126358192 contains 4 keys and measures 0.8 KB when serialized as a Parcel
    * androidx.lifecycle.BundlableSavedStateRegistry.key = 0.1 KB
    * transMode = 0.0 KB
    * android:user_visible_hint = 0.1 KB
    * android:view_state = 0.6 KB
    * fragment arguments = Bundle247579945 contains 1 keys and measures 0.0 KB when serialized as a Parcel
    * index = 0.0 KB

0,8 КБбольшой, но он накапливается в родительском фрагменте viewpager и его контейнерной активности.Это означает, что при просмотре от индекса 1 до 1000 будет сохранено 800 КБ в состоянии родительского фрагмента.Здесь он достигает красной линии в 1 МБ TransactionTooLargeException, когда я начинаю новое действие.

Что еще хуже, пакет состояния в родительском фрагменте не освобождается.Я обнаружил, что при такой реализации, если я перехожу от 1 к 100, а затем обратно к 1, сохраненное состояние может быть применено к каждому фрагменту, но не освобождено, поскольку размер пакета состояний в родительском фрагменте удваивается до 160 КБ, а не 80 КБ.

Я едва что-то положил в пакет и не осмеливаюсь добавлять что-то большее, например, сериализуемый, поскольку нативное android:view_state потенциально достаточно для возникновения проблемы.

Интересно, как улучшить реализацию?Может ли это быть легко исправлено, или что-то более тяжелое, например, с использованием компонентов архитектуры Android, ViewPager2 или других зависимостей

...