Android ListView Утечка памяти?

1

Я реализовал просмотр разделенного списка, чтобы каждый раздел имел адаптер, используя это руководство, и, вероятно, он заставляет просматривать виды снова и снова при прокрутке и повторном использовании, поскольку существуют разные адаптеры (но при прокрутке назад он повторно использует но для одного и того же адаптера), и метод getView аналогичен (упрощенному):

        Map< String, ? > object = null;
        String id = null, title = null, rating = null, pic_url = null;
        object = sectionContent.get(position).getMap();
        id = (String) object.get(EventRowValues.ROW_ID);
        title = (String) object.get(EventRowValues.ROW_TITLE);
        pic_url = (String) object.get(EventRowValues.ROW_PIC_URL);

        View hView = convertView;
        if ( hView == null ) {
            hView = mInflater.inflate(R.layout.popularity_row, null);
            ViewHolder holder = new ViewHolder();
            holder.pic = (ImageView) hView.findViewById(R.id.icon);
            holder.title = (TextView) hView.findViewById(R.id.label);
            hView.setTag(holder);
        }

        final ViewHolder holder = (ViewHolder) hView.getTag();

        holder.id = id;

        mImageWorker.loadImage(pic_url, holder.pic);

        holder.title.setText(title);

        return hView;

Метод loadImage приведен в этом примере Google.

Проблема в том, что при прокрутке это занимает больше памяти, например, 2 МБ для 5-10 строк. Когда я прокручиваю назад, он не занимает больше памяти, но, насколько я знаю, он не должен выделять такие объемы памяти, потому что он повторно использует представления, поскольку я ожидаю, что он возьмет память только тогда, когда она загрузится, и когда я прокручу, чтобы использовать те же представления и растровые изображения из кеша (поскольку большая часть чертежей является одним и тем же объектом, возвращаемым из кеша).

Что может быть проблемой? Любой другой вариант для более умного повторного использования разделенного listView?

Большое спасибо.

  • 0
    Так что ваша проблема была решена моим решением?
Теги:
listview
memory-management
drawable
android-listview

3 ответа

2
Лучший ответ

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

Благодарю.

2

Попробуйте следующее: ОБНОВЛЕНИЕ:

        ViewHolder holder = new ViewHolder();

        if ( convertView == null ) {
            holder = new ViewHolder();
            hView = mInflater.inflate(R.layout.popularity_row, null);
            holder.pic = (ImageView) hView.findViewById(R.id.icon);
            holder.title = (TextView) hView.findViewById(R.id.label);
            hView.setTag(holder);
        } else {
            holder = (ViewHolder) view.getTag();
        }

PS: Вы создали объект владельца дважды. Это действительно необходимо?

Какую версию для Android вы используете, потому что у меня тоже была такая же проблема, я использовал версию 11 и более высокую версию, если вы хотите быстро прокручивать список, вам нужно указать android:hardwareAccelerated="true" в activity tag в файле манифеста.

  • 0
    Спасибо, но в чем разница между этим кодом и моим? Вы выделяете владельца даже в тех случаях, когда это не нужно. И ты имеешь в виду уровень API? А что делает android: hardwareAclelerated делает? Спасибо
  • 0
    Пожалуйста, смотрите мой обновленный код. Здесь я создал только один объект-держатель и использовал его при последующих вызовах. Существует разница между созданием объекта, которому присваивается значение. Здесь я создал объект только в первый раз и присвоил ему значение для последующих вызовов. Информацию об аппаратном ускорении можно найти по адресу: developer.android.com/guide/topics/graphics/hardware-accel.html.
Показать ещё 1 комментарий
1

закомментируйте mImageWorker.loadImage(pic_url, holder.pic); и показать разницу в потреблении памяти

  • 0
    Это то же самое потребление. 7 МБ для прокрутки списка (30 элементов). Возможно, само представление распределения и его imageViews ответственны за это потребление, и, возможно, ячейки ячеек распределены и не используются повторно (но когда я возвращаюсь назад, это все еще 7 МБ).
  • 0
    Я удалил imageViews из xml и код, который соответствует этим представлениям, и теперь для этого списка требуется 3 МБ ... все еще слишком много ...
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню