В этом уроке поговорим о том, почему для приложения очень важна производительность, и обсудим общую схему поиска и устранения проблем. Я опишу пару случаев из моей практики и расскажу, о чем будет этот курс.

 

Почему производительность важна

На Google IO 18 был доклад, в котором спикер приводил интересную статистику отзывов пользователей. 

Когда пользователь ставит приложению одну звезду в маркете, то в 42% случаев он указывает, что причина - нестабильность и баги. Т.е. это самая распространенная причина низкой оценки. А когда пользователь ставит 5 звезд, в 73% случаев он пишет, что у приложения отличные скорость, дизайн и юзабилити.

Это говорит о том, что пользователям очень важна быстрая и стабильная работа вашего приложения. Потребление батареи, отзывчивость, время запуска, размер APK, стабильность, плавный UI, использование памяти - если с этими характеристиками все в порядке, то ваши пользователи довольны. А если с производительностью есть проблемы, то это может сократить вашу аудиторию, и, как следствие, снизить монетизацию несмотря на весь полезный функционал.

Кроме плохих отзывов и оттока пользователей есть еще одна очень важная причина, чтобы уделять внимание производительности. Google собирает статистику стабильности и энергопотребления приложений. И эти данные используются в алгоритме поиска и рекомендаций. Т.е. чем оптимальнее ваше приложение, тем лучше оно будет ранжироваться в Google Play Market, и тем больше новых пользователей вы получите.

 

 

 

Порядок действий

Поиск и устранение проблем производительности - непростая задача. Вы должны понять, почему приложение работает медленно. А это значит, что вы должны знать какой инструмент каким образом использовать, чтобы понять причину. В этом курсе мы и будем этому учиться.

Обычно выделяют три шага в процессе работы над производительностью: сбор информации, анализ, действие

1) Сбор информации
Существует несколько различных инструментов для замера скорости, объема памяти или получения других данных о работе вашего приложения. Важно знать, какой из них и как использовать.

2) Анализ
Необходимо понимать все те данные, которые предоставляет вам инструмент. Это не всегда очевидно и поначалу может казаться непонятным набором данных или графиков.

3) Действие
После получения и анализа данных проблема была найдена и теперь ее надо устранить. Этот шаг может оказаться сложнее предыдущих двух. Ведь вам нужно оптимизировать существующий код. И это надо сделать не нарушив дедлайн, ничего не поломав и соблюдая текущие правила проекта.

Но иногда этот шаг бывает и самым простым. Можно целый день провести в поисках утечки памяти и выяснить, что где-то просто не отписался какой-нибудь listener. И добавление одной строчки кода решит проблему.


Шаги 1 и 2 могут выполняться несколько раз. Использовав один инструмент и проанализировав его данные, вы понимаете, что вам нужен другой инструмент.

 

 

 

Примеры

Приведу пару примеров из моего недавнего опыта.

 

Долгий старт приложения

Приложение внезапно стало гораздо дольше стартовать. Используя трейсинг, я нашел проблему. Мы не так давно сменили Gson на Jackson, и выяснилось, что на некоторых девайсах есть проблема в работе пары Retrofit + Jackson при первом к ним обращении после старта приложения. Трейсинг показал, что инициализация Jackson внутри Retrofit может занимать до 2 секунд! Пришлось выносить все это в отдельный поток.


OutOfMemory (OOM)

Крэшлитика показывала OOM крэш, который возникал при отображении картинки в ImageView. Чаще всего это воспроизводилось на старых версиях Android. Потому что обычно это старые и слабые девайсы с небольшим количеством памяти, и на них легко воспроизводятся такие проблемы.

Используя Memory Profiler, я просмотрел содержимое памяти при работе приложения и обнаружил, что одна из картинок занимает там неестественно много места. Причина была в том, что картинка, предназначенная для drawable-xxxhdpi лежала в папке drawable. Соответственно, система считала, что это mdpi картинка. И чтобы отобразить ее на xhdpi девайсе, система увеличивала ее в 2 раза. А для xxhdpi устройств - в 3 раза. Т.е. картинка сама по себе немаленькая, а система ее еще увеличивает. В итоге на некоторых устройствах она занимала в памяти до 30 мегабайт. Проблему усугубляла утечка памяти на экране с этой картинкой. В памяти висело несколько экземпляров этого огромного изображения, и пользователь получал OOM крэш.

Картинку поместили в правильную папку, утечку памяти устранили, и крэш перестал появляться.

 

 

 

Что включает в себя курс

В качестве краткого содержания курса вы можете посмотреть мой доклад на Codefest 2019


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


Memory profiler

Покажет вам все о памяти вашего приложения. Очень полезен для поиска утечек памяти и операций, которые мусорят в памяти.

 

  

CPU profiler

Покажет загрузку процессора в разрезе потоков, а также поможет найти наиболее медленно выполняющиеся методы в вашем коде.

 

 

 

Network profiler

Покажет все операции с сетью. Какой метод, в каком потоке, на какой адрес послал запрос и что именно загрузил.

 

 

Profile GPU Rendering

Покажет UI производительность вашего приложения. Достаточно ли оно быстро, чтобы прорисовывать положенные 60 кадров в секунду.

 

 

GPU overdraw

Покажет участки экрана, которые прорисовываются больше, чем один раз. Это может негативно сказаться на UI производительности.

 

 

Кроме этих инструментов будет ещё несколько других. А также я планирую затронуть такие темы, как: утечки памяти, оптимизация размера APK, скорость сборки Gradle, энергопотребление, Doze и т.п.  В итоге должно получиться не менее 15 уроков.

 

Курс Производительность

 


Присоединяйтесь к нам в Telegram:

- в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

- в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Compose, Kotlin, RxJava, Dagger, Тестирование, Performance 

- ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня




Комментарии   

# RE: Урок 1. ВведениеДаниил 19.11.2020 01:06
Разве система увеличивает картинки в зависимости от dpi? я думал, если соответствующего ресурса нет, например, в xxxhdpi, xxhdpi и тд, а есть только один ресурс в drawable, то он берется и отображается как есть, на всех dpi. И потом, что значит увеличить картинку в 3 раза? Не может же, допустим, картинка с разрешением 100x100 увеличится и стать 300 на 300, и при этом стать лучшего качества. Или я что-то не знаю?
# RE: Урок 1. ВведениеDmitry Vinogradov 24.11.2020 01:02
Под "увеличивала" я здесь имею ввиду - растягивала. Т.е. если картинка была, например, 100*100 px, то система ее растягивала до 200*200 px. При этом в памяти картинка начинала занимать больше места, т.к. хранилась там как Bitmap.
# RE: Урок 1. ВведениеДаниил 26.11.2020 20:41
Понял, спасибо!

Language

Автор сайта

Дмитрий Виноградов

Подробнее можно посмотреть или почитать.

Никакие другие люди не имеют к этому сайту никакого отношения и просто занимаются плагиатом.

Социальные сети

 

В канале я публикую ссылки на интересные и полезные статьи по Android

В чате можно обсудить вопросы и проблемы, возникающие при разработке



Группа ВКонтакте



Поддержка проекта

Яндекс
410011180491924

WebMoney
R248743991365
Z551306702056

Paypal