LinearLayout или RelativeLayout: о выборе элементов пользовательского интерфейса Android

Разработка пользовательского интерфейса для Android OS основана на основополагающем принципе — использовать как можно меньше элементов! Но в силу разнообразия элементов интерфейса и их комбинаций иногда сложно сказать, какая реализация является наиболее производительной.

В процессе разработки можно выделить несколько групп элементов пользовательского интерфейса, которые различаются по своему назначению. В данной статье речь пойдет об элементах управления, роль которых состоит в том, чтобы расположить контент. Эту группу элементов часто называют контейнерами (в Android API она называется Layouts).

Контейнеры имеют широкое и разнообразное применение. Это разнообразие порождает головную боль выбора — рациональный набор контейнеров. Давайте рассмотрим частный случай этой задачи.

Эксперимент EGO Creative Innovations

Наиболее популярными элементами управления, которые выступают в качестве контейнеров для Android OS, являются LinearLayout и RelativeLayout. Кроме широкого распространения у этих контролов достаточно большая степень взаимозаменяемости, т. е. возможно достаточно безболезненно один контейнер заменить другим. Как известно, основным отличием данных контейнеров является подход к расположению элементов внутри:

• LinearLayout — позиционирование основано на порядке расположения составных компонентов внутри;
• RelativeLayout — необходимо явно указывать относительное расположение элемента.

Для обоснования рационального выбора реализации сравниваемых контейнеров предлагаем использовать следующие критерии:

• время инициализации графической части;
• занимаемое количество виртуальной памяти;
• удобство использования;

Все, кто занимался разработкой пользовательского интерфейса для Android-платформы, согласятся, что использование LinearLayout в большинстве случаев является более удобным в силу простоты расположения элементов внутри по сравнению с RelativeLayout. Но так как удобство использования — это достаточно субъективный критерий и определяется эмпирически, в данной статье этот критерий не будет ключевым в обосновании выбора.

Несмотря на заявленное преимущество использования LinearLayout, на практике достаточно часто возникают случаи, когда необходимо использовать большее количество контейнеров LinearLayout, чем RelativeLayout, для реализации одного и того же интерфейса. И этот факт нередко играет ключевую роль в выборе реализации интерфейса. Ниже представлено сравнение производительности использования предложенных лейаутов с учетом большего количества LinearLayout для реализации пользовательского интерфейса, аналогичного RelativeLayout.

Для возможности сравнения производительности LinearLayout и RelativeLayout по заданным критериям было создано тестовое приложение. Для примера было создано два одинаковых внешне элементарных пользовательских интерфейса, которые различаются реализацией интерфейса с использованием LinearLayout и RelativeLayout соответственно.

Интерфейс первого фрагмента содержит 20 рядов по 20 элементов View, которые расположены в LinearLayout, при этом каждый ряд отдельно размещен в собственном LinearLayout, что привело к размещению 20 «лишних» контейнеров. В общем, в первом фрагменте 22 контейнера и 400 элементов контента.

<ScrollView xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="wrap_content"> <LinearLayout android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent"> <LinearLayout android:orientation="horizontal" android:layout_width="match_parent" android:layout_height="wrap_content"> <View android:layout_width="10dp" android:layout_height="10dp" android:layout_margin="2dp" android:background="@android:color/holo_red_light"/> … </LinearLayout> … </LinearLayout> </ScrollView>

Интерфейс второго фрагмента аналогично содержит 20 рядов по 20 элементов View, которые расположены в RelativeLayout. И, в отличии от LinearLayout, в данной реализации все View расположились в одном контейнере. Таким образом, во втором фрагменте — два контейнера и 400 элементов контента, что на 20 контейнеров меньше, чем в первом фрагменте.

<ScrollView xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent"> <RelativeLayout android:layout_width="match_parent" android:layout_height="match_parent"> <View android:id="@+id/column1row1" android:layout_width="10dp" android:layout_height="10dp" android:layout_margin="2dp" android:background="@android:color/holo_red_light" android:layout_alignParentLeft="true" /> … </RelativeLayout> </ScrollView>

Данные фрагменты имеют один и тот же класс, но разные ссылки на файл лейаута. В теле перегруженного метода OnCreateView фрагмента помещена логика для определения потраченного времени на инициализацию и используемую приложением виртуальную память.

public override View OnCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { var timeStart = DateTime.UtcNow; var view = inflater.Inflate(_resource, container, false); ElapsedMemory = GC.GetTotalMemory(true) / 1024; ElapsedTime = (DateTime.UtcNow - timeStart).Milliseconds; ViewCreated?.Invoke(this); return view; }

В приложении отображается количество переходов на каждый фрагмент, а также среднее значение потраченного времени на инициализацию и среднее значение занимаемой приложением памяти.

Переключение между фрагментами осуществляется с помощью драйвера. Основные элементы приложения показаны на рис. 1-2.

Результаты эксперимента

Ниже представлены результаты, полученные на реальных девайсах.

Мобильное устройство № 1

• Версия Android SDK — Android Marshmallow (6.0)
• Разрешение дисплея — 1280×720
• Диагональ экрана — 5 дюймов
• Процессор — MediaTek MT6735 4 ядра
• RAM — 2 Гб

Мобильное устройство № 2

• Версия Android SDK — Android Nougat (7.0)
• Разрешение дисплея — 1280×800
• Диагональ экрана — 8 дюймов
• Процессор — MediaTek MT8163 4 ядра
• RAM — 2 Гб

Мобильное устройство № 3

• Версия Android SDK — Android Oreo (8.1)
• Разрешение дисплея — 1920×1080
• Диагональ экрана — 5,5 дюйма
• Процессор — Qualcomm Snapdragon 625 8 ядер
• RAM — 4 Гб

Выводы

Как видно из приведенных выше результатов, на всех устройствах время инициализации вью фрагмента с LinearLayout меньше, чем на аналогичном фрагменте с RelativeLayout. Такая же ситуация с занимаемой приложением памятью — фрагмент с LinearLayout занимает меньше оперативной памяти, чем с RelativeLayout.

Несмотря на казавшуюся очевидность преимущества использования RelativeLayout в качестве контейнера, результат оказался противоположным по критериям производительности из-за меньшего количества контейнеров.

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

Также стоит отметить, что для простых пользовательских интерфейсов можно пренебречь разницей в производительности и руководствоваться исключительно удобством использования.

Об авторах: Влад Загубинога — разработчик, Янина Ноэль — бренд-стратег, компания EGO Creative Innovations.