Как стать автором
Обновить

Комментарии 10

Плоская разметка — идеально.

Это не всегда так. К примеру, RelativeLayout'у приходится выполнять measure-процесс 2 раза и если он содержит детей со сложным measure-подсчетом, то он может оказаться медленнее, чем несколько других более «простых» ViewGroup.
Кстати, та же история с множественным measure и у LinearLayout, если рисовать её детей с помощью параметра weight
Спасибо за статью, я всё никак не мог понять, по какому принципу монитор мне окрашивал эти точки. Ну т.е. понятно, что красный цвет это плохо, но как он определял, что такое-то время measure/layout/draw это уже много было загадкой :)
От себя бы добавил:
1. Если нужно заполнить место каким то холдером/пустым местом, есть специальная вьюшка Space, которая участвует в процессах measure/layout, но ничего не рисует, тем самым не отнимает ресурсов.
2. Бывают случаи, когда нужно нарисовать сложный, но не очень изменяемый layout и в таких случаях есть смысл подумать: «а не написать ли мне свой ViewGroup с легким и быстром measure/layout/draw процессом»
Большое спасибо за наводку на: «Debug GPU Overdraw/Отладка превышения GPU». Надеюсь на продолжение.
Не понимаю я утверждения, что ndk быстрее. Для чего быстрее? Для обсчета какой-нибудь трудоемкой задачи да, а для всего явно нет. Не забывайте что jni call медленный
Можно GUI и на NDK писать. Есть лёгкие варианты и есть монстрики типо Qt.
Конечно можно. Напрямую делая колы через opengl. Только вот зачем? Для обычного приложения потратить годы на разработку, по пути наделав кучу багов. Для игр это только нужно.
Ну есть смежные с играми области где это может быть нужно. Я скорее говорил о возможности, а не обязательности.
Еще можно добавить остальные warning'и, которые кидает Lint в плане производительности
Спасибо. Лично для меня статья оказалась очень полезной.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.