Итак, я сейчас делаю список с плитками расширения и, анализируя производительность с помощью инструментов разработчика, я кое-что заметил. При расширении плитки номера сборки для текста заголовка go безумно высоки. При каждом нажатии на плитку номера сборки go увеличиваются примерно до 17. После некоторого тестирования (выполненного в отладочной сборке, так как я не могу отследить перестроения виджетов в режиме производительности), я понял, что это проблема с ExpansionTile , Это действительно имеет смысл для этой проблемы, поскольку стандартная стрелка в плитке расширения анимирована. Поэтому для каждого кадра анимации текст заголовка обновляется вместе с ним. К сожалению, при работе с плитками расширения в компоновщике списков это только ухудшает производительность. Есть ли какой-нибудь возможный обходной путь, чтобы сделать все более эффективным, или это просто недостаток использования ExpansionTile?
В качестве примечания: я знаю, что режим отладочной сборки не очень хорош для измерения производительности, но я получаю те же потери кадров по большей части по сравнению с режимом построения профиля.
Просто для получения дополнительной информации: я делаю приложение, которое составляет разные списки для нескольких проанализированных JSON файлов. В идеале я использую построитель списка (например, SliverChildBuilderDelegate или ListView.builder), поскольку информация меняется в зависимости от каждого файла JSON. Я выбрал ExpansionTile для использования в списках, так как это сделает их менее загроможденными и более удобными для пользователя.
Надеюсь, я достаточно хорошо это структурировал. Спасибо за любые возможные отзывы.