Комплексное представление на основе RelativeLayout - проблема производительности

Question

Возникла проблема с производительностью, когда используется много вложенных RelativeLayouts.

Например, если у нас есть некоторый RelativeLayout в качестве корня пользовательского интерфейса, и каждый контейнер (кнопка, метка, textview, imageview) являетсяRelativeLayout + компонент на базе Android (например, aButton = RelativeLayout + ImageView + TextView), затем в сложном виде из 4 кнопок, 3 изображений и 6 меток мы получаем ~ 15 вложенных RelativeLayouts.

RelativeLayout имееточень сложный метод onMeasure, который вычисляет размер каждого дочернего элемента для определения размера макета.Расчет размера сложного представления из 15-20 вложенных RelativeLayouts стоит ~ 5 секунд, это слишком много.onMeasure является самым дорогим из всех вызовов, даже рисование заканчивается намного быстрее, чем измерение.<= UPD =>
Чтобы предотвратить появление предложений по использованию собственных представлений Android для создания чего-то сложного:
Требуется возможность добавлять все ко всему.Вот почему каждый контейнер должен быть не просто View, но ViewGroup.И функции RelativeLayout, такие как гравитация и выравнивание, также могут помочь, поэтому используется множество RelativeLayout. <= / UPD =>

Были ли у кого-нибудь эти проблемы с производительностью?
Следует ли заменить RelativeLayout некоторымиДругая проблема с компоновкой решает проблему?
Или удаление всех этих вложенных макетов - единственный способ справиться с проблемой?
Кто-нибудь знает, сколько макетов может быть вложено без появления проблем с производительностью?

Answer 1

Это определенно зависит от вашего тестирующего устройства.Но вы должны проверить hierarchyviewer (в каталоге tools) на наличие ненужных гнезд для их удаления.

Также ваш aButton звучит как сток ImageButton.Таким образом, вы можете заменить хотя бы это стандартным решением.

Если вы разместили какой-либо код, было бы проще определить, есть ли еще элементы, которые можно заменить на стандартные решения.

Answer 2

Насколько я понимаю, весь смысл относительного планирования заключается в том, что вам не нужно вкладывать их в n-ю степень.Почему бы просто не использовать несколько RelativeLayout вместо 1 на компонент?

Answer 3

После нескольких испытаний пришел к выводу, что наличие более 12 вложенных макетов оказывает большое влияние на производительность.
В среднем 10-11 вложенных макетов должны работать нормально.
Например, 12 вложенных макетов с 12 дочерними элементами на каждом дисплее за 6 секунд на устройстве и 9 на эмуляторе.