Каков уровень востребованности ресурсов для каждого layout?

#android #xml #layout

В процессе разработки столкнулся с вопросом: сколько ресурсов требует каждый layout?
(Linear, Relative, Tab, Constraint, Coordinator)

В сложных view-представлениях приложения оправдано ли использование исключительно
маловесных layout?
    

Ответы

Ответ 1

В общем случае, при одноуровневой верстке, в порядке возрастания потребления ресурса:

FrameLayout - LinearLayout  - RelativeLayout - ConstraintLayout 

Однако, при вложенности одного контейнера в другой, потребление ресурса существенно
увеличивается. Так как на практике встречается очень мало таких версток, где достаточно
одного простого контейнера (как Frame или Linear), то в большинстве случаев оптимальным
решением будет ConstraintLayout, как контейнер, изначально задуманный, как одноуровневый
и имеющий большое количество атрибутов для комфортной реализации практически любой
верстки, без вложенности одного контейнера в другой. В этом его преимущество перед
более простыми контейнерами, если же вложить в него другие - оно будет утрачено.

С другой стороны, если макет можно сверстать в одноуровневый FrameLayout (например,
контейнер для Fragment) или LinearLayout (например, айтем списка), то это будет гораздо
более оптимальное решение в плане потребления ресурсов.

TableLayout это двухуровневый LinearLayout (вертикальный, в который вложены горизонтальные)

RelativeLayout с одной стороны несколько легче ConstraintLayout, с другой стороны
существенно проигрывает ему в возможностях позиционирования виджетов и, наверное, в
настоящее время не сильно востребован.

такие вещи, как CoordinatorLayout, AppBarLayout не имеют альтернатив реализации и
потребление ими ресурсов оценивается только с позиции использовать или нет, хотя особого
аппетита к ресурсам за ними вроде не замечено.

Несколько тестов различных разметок: сравнение производительности разных контейнеров,
контейнер с вложенными контейнерами против ConstraintLayout

Так же для оценки производительности разметки вы можете использовать инструмент Hierarchy
Viewer. С версии студии 3 он объявлен устаревшим и в качестве замены предлагается Layout
Inspector, но он не показывает время на рендеринг разметки.
Теперь запустить Hierarchy Viewver можно из Android Device Monitor, который в свою
очередь можно запустить из папки

 .../android_sdk/tools/monitor.bat


PS: Сейчас google рекомендует оценивать производительность UI через Systrace, однако
результаты ее не так просты и наглядны, как у Hierarchy Viewr