Производительность отображения с относительной выкладкой, содержащей много TextView

Question

Я сталкиваюсь с проблемами производительности при использовании RelativeLayout (обернутого в ScrollView), содержащего 153 TextView.Каждый из TextView имеет 9 фоновых патчей.

Основной макет:

<ScrollView 
    android:id="@+id/forum_accueil_ScrollView"
    android:layout_width="fill_parent" android:layout_height="fill_parent"
    android:background="@color/white">
    <RelativeLayout android:id="@+id/forum_accueil_RelativeLayout"
        android:layout_width="fill_parent" android:layout_height="fill_parent"
        android:background="@color/white">
    </RelativeLayout>
</ScrollView>

RelativeLayout программно заполнен TextViews (количество элементов и описание получены из WS).У каждого из TextView есть селектор фона 9 патчей.Описание TextView ниже:

<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content" android:layout_height="35dip"
    android:textColor="@color/myblue"
    android:textStyle="bold"
    android:gravity="center_vertical" android:layout_gravity="center_vertical"
    android:background="@drawable/selector_forum_accueil_item">
</TextView>

В конце у меня есть RelativeLayout, содержащий 153 TextView.Дисплей и прокрутка очень медленно.Даже возвращение к этому занятию занимает некоторое время.

Я открыл окно просмотра иерархии, а ScrollView отображает следующее время:

Измерение: 28 мс Макет: 1,2 мс Рисование: 18 мс

Есть ли способ ускорить отображение и отзывчивость?Является ли единственный RelativeLayout, содержащий как можно больше видов, лучшим способом сделать это (я попытался максимально сгладить иерархию с помощью этой техники)?Я попытался удалить 9 патчей фона для теста, кажется, гораздо более отзывчивым.Почему?

Answer 1

Это неприличное количество TextViews. В этот момент используйте ListView. Что ваш RelativeLayout делает для вас (в данном случае), что ListView не может?

Answer 2

Ваш вопрос предельно ясен: почему время рендеринга / макета намного быстрее после удаления фона из 9 патчей? На самом деле есть 2 хороших ответа:

1. указание атрибута фона против использования стиля, который включает атрибут фона, намного медленнее. Стили кэшируются с помощью графического процессора, поэтому он уже знает о фоне и использует его. Если стиль не указан, стиль (стиль по умолчанию) используется в любом случае, и он включает некоторый фон, и он применяется первым. Затем применяются специфичные для вида атрибуты, т. Е. Заданный вами фон повторно визуализируется.
2. 9-патч-изображений может занять много больше для рендеринга. Сопоставьте это с тем фактом, что вы запрашиваете его рендеринг в 153 раза, и производительность будет экспоненциально хуже. Сейчас я смотрю на случай, когда я вижу «обычные» растровые изображения .png, отрисованные за 1,5 мс, в то время как очень простой 9-патч в той же компоновке медленнее в 30 раз за 45 мс.

Caveat emptor: рендеринг с 9 патчами часто , но не всегда, на который влияет цикл GC, на который приходится 80% времени рендеринга. В некоторых случаях я вижу, что этот цикл GC происходит при рендеринге других растровых / растровых изображений, но он действительно , как представляется, происходит чаще при рендеринге с 9 патчами.