Я работаю над приложением, которое использует Recyclerview для отображения mp3-файлов, предоставляя изображение обложки вместе с другой информацией. Это работает, но медленно, как только он начинает иметь дело с дюжиной или более обложек для извлечения, как я сейчас делаю это с id3 в главном потоке, что, я знаю, не очень хорошая идея. В идеале я бы работал с местозаполнителями, чтобы изображения можно было добавлять по мере их появления. Я пытался переместить поиск в фоновый поток и рассмотрел различные варианты: AsyncTask, Service, WorkManager. AsyncTask, похоже, не подходит для go, так как я сталкиваюсь с утечками памяти (мне нужен контекст, чтобы получить обложку через MetadataRetriever). Так что я от этого отклоняюсь. Тем не менее, я изо всех сил пытаюсь выяснить, какой подход является лучшим в моем случае.
Из того, что я понимаю, мне нужно найти подход, который позволяет использовать многопоточность, а также способ отменить поиск в случае, если пользователь уже перешел (прокрутка или навигация). Я уже использую Glide, который, как я понимаю, должен помочь с кэшированием. Я знаю, что мог бы переработать весь подход и представить обложку в виде изображений отдельно, но это кажется мне последним средством, так как я бы не стал загружать приложение еще большим количеством данных.
Текущая версия приложение здесь (обратите внимание, оно не запустится, поскольку я не могу открыто разглашать некоторые аспекты). Я извлекаю обложку следующим образом (в главном потоке):
static public Bitmap getCoverArt(Uri medUri, Context ctxt) {
MediaMetadataRetriever mmr = new MediaMetadataRetriever();
mmr.setDataSource(ctxt, medUri);
byte[] data = mmr.getEmbeddedPicture();
if (data != null) {
return BitmapFactory.decodeByteArray(data, 0, data.length);
} else {
return null;
}
}
Я нашел много примеров с AsyncTask или просто оставил MetaDataRetriever в основном потоке, но пока не нашел пример, который позволяет получить дюжину или более обложек без замедления основного потока. Буду признателен за любую помощь и указатели.