Оптимизация addView/removeAllChildren для кастомного компонента в Android?
Всем привет!
Я новичок в разработке под Android. Передо мной встала довольно простая задача, с которой справился, но пока как-то неполноценно, т.к. ощущение, что я либо не тем путем иду, либо надо банально оптимизировать что-то, т.к. лагает.
Суть задачи: есть элемент в списке (ListView), в нем есть кнопка. При нажатии на кнопку меняется состояние этого элемента и он показывает в некоторой части себя (элемента списка) другую View.
При смене состояния я дергаю removeAllChildren, а потом addView той View, которая у меня заранее была создана LayoutInflator'ом и закеширована.
Тоже самое происходит и когда Adapter пропихивает данные по вызову getView. И вот в этот самый момент когда нужно пересоздать детей и возникает лаг. Если он возникает по нажатии на кнопку — это еще ничего. Но при прокрутке он возникает постоянно, т.к. известно что View представляющие элементы списка в ListView переиспользуются.
Дорогой Хабр, подскажи, пожалуйста мне нубу, как правильно такие вещи делают толковые Android разработчики?
P.S. Я сначала полагал, что дело в том что в элементе списка сложная иерархия layout'ов. Я ее сплющил, заменив одним RelativeLayout и накидав в него компоненты. Но это не помогло, т.к. дело, я уверен, именно в removeAllChildren/addView
Надо на каждое состояние создать по отдельной View'хе и уже в самом Adapter'е в зависимости от данных инстанцировать нужную View, пропихивать обработчик изменения состояния туда. При изменении состояния обновлять элемент данных и дергать обновление ListView.
Дождитесь таки совета опытных разработчиков, а пока… а вы не пробовали предварительно создать и разместить нужные вьюхи на элементе списка и при возникновении определенных событий (тот же клик на кнопку) только управлять их видимостью (View.VISIBLE, View.INVISIBLE, View.GONE) и изменением состояния (может там какое-то заполнение или еще что-то)? Или это не подходит в вашем случае? По-моему, вот так создавать-удалять в рантайме не очень хорошо.
Это вариант, но тогда не удобно с интерфейсом работать в дизайнере UI в IDEA :) Поэтому я и отложил этот вариант. Дело в том, что там таких состояний 6 штук. И такую толстую xml layout'а не очень комфортно поддерживать.
Попробую последовать вашему совету. Просто сейчас у меня все очень декомпозированно и стройно получается, но тормозит.
А вьюхи-то заранее создаются все. Они просто добавляются и удаляются из иерархии. Я думал это быстро происходит. Видимо нет :(
Всё верно, это наилучший вариант. Не забывайте также про getItemViewType() — сможете заготовить несколько готовых XML с нужными layout-ами и в зависимости от ситуации использовать нужный XML. А добавлять/удалять вьюхи на лету из списка — последнее дело, никогда так не делайте.
Эх как я прогнал! Можно же просто их насоздавать и надобавлять заранее. Тогда нет проблемы и с тулом для создания UI, и нет проблемы с производительностью :) щас заимплеменчу! Спасибо огромное!
