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

#java #android #тестирование

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

Всё что мне необходимо — это получить данные и показать.
    

Ответы

Ответ 1

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

Покрывал я участки кода 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;


Самый точный способ замера участка кода, на одном устр-ве из тех которые я нашел.


Ответ 2

Например можно сделать вывод в лог текущего времени в начале и в конце тестируемого
кода и посмотреть на разницу:

Log.d("Log", DateFormat.getDateTimeInstance().format(new Date()));