А что там описывать?
1.  LeakCanary для первичной оценки масштаба трагедии
2. Мониторинг выделения ресурсов
3. Анализ дампов
4. Исправление наиболее серьезных проблем с утечками памяти / оптимизация структур в случае если она не течет, а реально используется. Возможно, перевод изображений в RGB444 вместо RGBA8888, проверка соответствия размеров ассетов и т.д.
5. Определение источника расхода батареи, можно методом исключения - ЦПУ, геолокация, радиомодули
6. ...

ну, ответ шикарный как по мне....)

анализ дампов я вообще щас гуглю)))

На практике у меня это обычно выливается в пару минут просмотра графика памяти и три-четыре дампа в ключевых точках. Батарею обычно жрёт проц, который занят GC, так что ему сразу-же становится лучше.

Что точно нельзя делать, так это сразу рефакторить.

почему?

Исправишь к худшему

как исправлять тогда?)

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

типа сначало обнаружить проблему и лишь потом приступать?

Очевидно, да. А то отрефакторишь сплеш-экран, а там все костыли нужные.

Потом при открытии пушей краши начнутся :D

Имхо, сеньор должен уметь обосновать "неправильный" ответ.

Подскажите по настройке CI
На какие ветки его обычно настраивают?
Как настроить на dev и master разные конфигы Circle CI?

GC - garbage collection?
просто ищу дополнение к пояснению как решить жор батареи
типа на входе у меня есть какие то данные и мол почему может жрать батарею.

Да, сборка мусора

по идее если у меня остались какие то объекты в памяти
то с ними не может справится GC и соотвтетствентсвенно нагружается проц?
правильно ли так будет отвтетить?

пальцем в небо

ну я стараюсь сделать вывод из:
"Батарею обычно жрёт проц, который занят GC"

можно ли использовать google pay для яндекс кассы без использования sdk яндекса?