Страницы

Поиск по вопросам

пятница, 31 января 2020 г.

Как в 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()));

Комментариев нет:

Отправить комментарий