Блог

Виджет Gallery по умолчанию на Android не перерабатывает просмотры — каждый раз, когда вызывается view для новой позиции, виджет всегда вызывает getView метод адаптера с convertView значением null.

При прокрутке назад и вперед создается множество просмотров, которые компонент recycler, в котором они хранятся в галерее, похоже, не перерабатывает достаточно быстро, что приводит к ситуации с ООМ.

Вы можете легко протестировать это с помощью нескольких изображений большого размера в качестве элементов вашей галереи, но в конечном итоге это приведет только к TextView. Также поместите оператор log со счетчиком в getView метод вашего адаптера, чтобы увидеть, сколько новых просмотров создано.

Существует ли сторонний виджет, который ведет себя как галерея, но который также реализует переработку вида?

В конце концов, я принял решение, согласившись с предложением @CommonsWare изменить исходный код Gallery. Для этого также требуется скопировать следующие файлы:

• AdapterView
• AbsSpinner

но это довольно просто.

После этого я изменил код, чтобы выполнить следующее:

RecycleBin ( AbsSpinner )

• Размещайте объекты в утилизаторе один за другим, а не в соответствии с положением
• Извлекайте объекты из нижней части утилизатора, независимо от запрошенной позиции
• Существующая реализация предполагала, что каждая отдельная позиция в адаптере приводила к уникальному представлению. Вышеуказанные изменения хороши только в том случае, если ваша галерея содержит только один тип элементов, в противном случае вам нужно будет добавить какой-то ключ, основанный на типе элемента и требуемом количестве этого типа

Gallery

• Использовал отражение (тьфу), чтобы изменить закрытую mGroupFlags переменную ViewGroup , чтобы разрешить повторный порядок дочерних элементов — я также установил логическое значение, указывающее, был ли выполнен успешный доступ к полю, который я тестирую перед использованием компонента.
• Удалены все вызовы для mRecycler.clear()
• Количество элементов, которые галерея должна отображать, изменяется по мере прокрутки, и существующая реализация очистит переработчик при (а) вызове setSelection (б) возникновении прокрутки движения

С этими изменениями мой счетчик в моем newView методе в моем адаптере достиг … 7.

Вот код (Размещен в общественном достоянии 08.03.07 под http://en.wikipedia.org/wiki/WTFPL )

На самом деле есть альтернатива, хотя я лично ее не тестировал:

https://github.com/falnatsheh/EcoGallery

Я использовал патч от http://code.google.com/p/android/issues/detail?id=3376#c19

Очень поздно на вечеринку, но я изменил EcoGallery, чтобы сделать еще несколько вещей (и избежать некоторых сбоев).

Я назвал его TimelineGallery, и это та же ерунда, что и Галерея, но он может выполнять плавную прокрутку и не делает странных вещей, когда изображения загружаются асинхронно.

Чтобы продемонстрировать это, в примере используются Picasso и PullToRefresh.

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

Заключительное замечание: я не рекомендую использовать галерею, она старая, глючная, взломанная и, вероятно, никогда не будет поддерживаться. Проблема не в исправлении его ошибок, проблема в том, что вся архитектура Gallery неверна, и поэтому ее исправление невозможно без внесения дополнительных взломов.

Google понял это и устарел. Используйте ViewPager или Horizontalscrollist и учитывайте ограничения каждого из них.

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

Другой более быстрый способ решения проблем с OutOfMemory — попробовать / перехватить код, в котором вы декодируете изображение, и, если выдается исключение OutOfMemory, вы пытаетесь декодировать его с меньшим разрешением снова..

что-то вроде этого:

 private static Bitmap decodeFile(File f, int size, int suggestedScale) {

    int scale = 1;
    Bitmap bmp = null;
    try {
        // Decode image size
        BitmapFactory.Options o = new BitmapFactory.Options();
        o.inJustDecodeBounds = true;
        BitmapFactory.decodeStream(new FileInputStream(f), null, o);

        // Find the correct scale value. It should be the power of 2.
        int width_tmp = o.outWidth, height_tmp = o.outHeight;

        if(suggestedScale > 0)
            scale = suggestedScale;
        else {
            if (width_tmp >= height_tmp) {
                scale = Math.round((float)(width_tmp) / size);
            } else {
                scale = Math.round((float)(height_tmp) / size);
            }
        }

        if(scale < 2)
            return BitmapFactory.decodeFile(f.getPath()); 

        Debug.i(TAG, "width: "   width_tmp   "  height: "   height_tmp   "  scale: "   scale);


        // Decode with inSampleSize
        BitmapFactory.Options o2 = new BitmapFactory.Options();
        o2.inSampleSize = scale;
        bmp = BitmapFactory.decodeStream(new FileInputStream(f), null, o2);
    } catch (FileNotFoundException e) {

    } catch(OutOfMemoryError e) {
        Debug.i(TAG, "we retry it cause of an OutOfMemoryException");
        return decodeFile(f, size, scale 1);
    } catch(Exception e){
        Debug.w(TAG, e);
    }
    return bmp;
}
  

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