Наличие глубоких иерархий представлений может привести к замедлению, которое вы часто можете исправить, сгладив их с помощью пользовательских представлений, но если вы используете простые представления, вы можете иметь десятки на экране без ощутимого влияния на производительность, поэтому в целом я рекомендую игнорирование количества представлений, которые у вас есть при разработке, и затем уменьшение количества представлений, если это окажется проблемой производительности.
Сказав это, вы, кажется, настраиваете что-то с неограниченно большим количеством просмотров, что не хорошо. Не зная, сколько записей в заголовках массивов, я не могу точно сказать, что происходит, но я подозреваю, что хотя фактическая визуальная иерархия для каждого создаваемого вами backView - это нормально, создание backView для каждого элемента в массиве и использование индексов, чтобы передняя часть спрятала все остальные за ней, приводит к слишком большому количеству просмотров.
Итак, как это проверить:
Добавьте разрыв в конец цикла for. Сделайте выпадение цикла после одной итерации и посмотрите, улучшится ли производительность. Если это так, то огромные иерархии представлений - ваша проблема. Возможно, вам придется взломать подпрограмму, которая изменяет индексы, чтобы убедиться, что она никогда не переключится на недопустимый индекс для тестирования.
Если это так, у вас есть несколько вариантов. Вы могли бы реализовать пользовательский вид и сгладить каждый вид сзади в одном виде, но в зависимости от того, сколько у вас есть этого мата, будет недостаточно, и это больше работы, чем просто создать вид сзади так, как вы в настоящее время, но по требованию вместо во время загрузки:
1) Измените код в вашем цикле for на отдельный метод, который создает backView для определенного заголовка и присоединяет его к представлению в это время.
2) Где бы вы в настоящее время не изменяли индексы, чтобы сделать видимость сзади, вместо этого вызывайте новый метод, чтобы фактически построить и прикрепить вид сзади в это время