О производительности Android-приложений

[forceLain]

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

Это не всегда так. К примеру, RelativeLayout'у приходится выполнять measure-процесс 2 раза и если он содержит детей со сложным measure-подсчетом, то он может оказаться медленнее, чем несколько других более «простых» ViewGroup.

[forceLain]

Кстати, та же история с множественным measure и у LinearLayout, если рисовать её детей с помощью параметра weight

[forceLain]

Спасибо за статью, я всё никак не мог понять, по какому принципу монитор мне окрашивал эти точки. Ну т.е. понятно, что красный цвет это плохо, но как он определял, что такое-то время measure/layout/draw это уже много было загадкой :)
От себя бы добавил:
1. Если нужно заполнить место каким то холдером/пустым местом, есть специальная вьюшка Space, которая участвует в процессах measure/layout, но ничего не рисует, тем самым не отнимает ресурсов.
2. Бывают случаи, когда нужно нарисовать сложный, но не очень изменяемый layout и в таких случаях есть смысл подумать: «а не написать ли мне свой ViewGroup с легким и быстром measure/layout/draw процессом»

[kaftanati]

Большое спасибо за наводку на: «Debug GPU Overdraw/Отладка превышения GPU». Надеюсь на продолжение.

[stalkerg]

Можно GUI и на NDK писать. Есть лёгкие варианты и есть монстрики типо Qt.

[stalkerg]

Ну есть смежные с играми области где это может быть нужно. Я скорее говорил о возможности, а не обязательности.

[anton9088]

Еще можно добавить остальные warning'и, которые кидает Lint в плане производительности

[ZiGR]

Спасибо. Лично для меня статья оказалась очень полезной.