Как в Android Studio тестировать участок кода на время прохождения?

Как в Android Studio тестировать определенный участок кода на время прохождения?
Всё что мне необходимо — это получить данные и показать.

Ответ

Лучше позже чем никогда. Вопрос довольно простой на первый взгляд, и решить его можно разными способами. После прочтения ряда статей, тестов с разных источников, в основном официальных, я решил эту проблему следующим путем:
Покрывал я участки кода JUnitPerf у него есть парочка оболочек на время прохождения, в случае отклонение, выводим что необходимо. И это, то что я искал.
Но вопрос был сформулирован по другому, для этого я эмулировал несколько ситуаций и сделал свой тест: вначале я использовал разные БД(было интересно), позже я упростил и использовал различные интерфейсы коллекций и записывал и удалял небольшое кол-во записей, а точней 100.000, как оказалось позже это очень удачное число, но не суть. Я уже знал, что в корне необходимо использовать два нативных метода системы, но мы вернемся немного назад, почему так измерять нельзя?:
DateFormat.getDateTimeInstance().format(new Date())
Я думаю многие знают или догадываются, но вкратце - много здесь ненужных действий начиная стилей даты, создание объекта, потом нам необходимо как-то измерять точку входа и выхода - autoboxing etc, всё это создаст огромную погрешность, и в итоге сильный разброс при замере одной и той же операции. Но если даже всё убрать и сделать так:
Date date = new Date();
Даже так плохо, мы тратим время на создание объекта класса, и его внутреннюю реализацию, смотрим внутрь и видим
public Date() { this(System.currentTimeMillis()); }
Нас это больше чем устраивает, чтоб не плодить экземпляры класса. Это и есть один из методов, второй рядышком давайте их запишем вместе, через вызов, чтоб было удобней читать:
System.currentTimeMillis(); System.nanoTime();
Возвращает long, второй более точный(подробный), в наносекундах. Читаем оф документацию и видим в nanoTime():
This timestamp should only be used to measure a duration by comparing it against another timestamp on the same device.
Есть нюансы, но суть в оф документации там всё очевидно: nanoTime и рядом currentTimeMillis
После этого можно окончить, но вернемся к тесту. Много информации о том, что погрешность может исчисляться 10-15мс в зависимости от ситуаций(напомню между двумя этими подходами), я хотел бы это опровергнуть, но.... я сделал огромное кол-во пусков теста с различными параметрами с разными устройствами, я учитывал множество факторов, значения записывал только после выделения памяти, учитывал номер записи у меня был алгоритм подсчета среднего значения и ещё оооочень большое кол-во нюансов, и самый сильный разброс был таков:
System.nanoTime(); //374-412мс System.currentTimeMillis(); //386-439мс
Это индивидуальный случай, и скорей всего ошибки в замерах, но это факт. Возможно если увеличить кол-во записей в N кол-во всё и свелось бы к min, но я написал, что это был самый сильный разброс. В среднем как раз и было 10-15мс, но иногда иногда как в примере выше был другой рез-т.
В итоге ответ:
long startTime = System.nanoTime(); // ... the code being measured ... long estimatedTime = System.nanoTime() - startTime;
Самый точный способ замера участка кода, на одном устр-ве из тех которые я нашел.