Вчера у меня возникла идея:

Кому-нибудь интересна серия статей, посвященная мониторингу производительности Android в эксплуатационной среде?

Не что-то типа "настраиваем Firebase Performance Monitoring" (что меня не особо воодушевляет), а скорее "как работает Android".

“Я написал код, который определяет, когда происходит первый onDraw в приложении, но он не работает на API 25. Мне понадобилось какое-то время, чтобы понять причину!”

На что я получил положительные отзывы и сразу решил начать писать. Эта серия статей будет посвящена мониторингу производительности и стабильности приложений Android в эксплуатации. Она озаглавлена Android Vitals поскольку она тесно связана с Android vitals от самих Google:

Android vitals является инициативой Google, нацеленной на повышение производительности и стабильности Android-устройств. Когда пользователь, разрешивший сбор данных, запускает ваше приложение, его Android-устройство регистрирует различные метрики, включая данные о стабильности приложения, времени его запуска, использовании батареи, времени рендеринга и отказах в разрешениях.

Если у вас есть вопросы или идеи для будущих статей, не стесняйтесь писать мне в Twitter!

Для разогрева начну с простого вопроса:

Сколько времени?

Чтобы отслеживать производительность, нам нужно измерять временные интервалы, то есть разницу между двумя моментами времени. JDK предоставляет нам 2 способа получить текущее время:

// Миллисекунды с “эпохи Unix” (00:00:00 UTC 1 января 1970 г.)
System.currentTimeMillis()
// Наносекунды с момента запуска виртуальной машины.
System.nanoTime()
Android предоставляет класс SystemClock, который добавляет еще несколько вариантов:
// (API 29) Таймер, который ведет отсчет с “эпохи Unix”.
// Синхронизируется с помощью провайдера местоположения устройства.
SystemClock.currentGnssTimeClock()
// Миллисекунды работы в текущем потоке.
SystemClock.currentThreadTimeMillis()
// Миллисекунды с момента загрузки, включая время, проведенное в спящем режиме.
SystemClock.elapsedRealtime()
// Наносекунды с момента загрузки, включая время, проведенное в спящем режиме.
SystemClock.elapsedRealtimeNanos()
// Миллисекунды с момента загрузки, не считая времени, проведенного в глубоком сне.
SystemClock.uptimeMillis()

Что из этого многообразия выбрать? Ответить на этот вопрос может помочь javadoc по SystemClock:

// (API 29) Clock that starts at Unix epoch.
// Synchronized using the device's location provider.
SystemClock.currentGnssTimeClock()
// Milliseconds running in the current thread.
SystemClock.currentThreadTimeMillis()
// Milliseconds since boot, including time spent in sleep.
SystemClock.elapsedRealtime()
// Nanoseconds since boot, including time spent in sleep.
SystemClock.elapsedRealtimeNanos()
// Milliseconds since boot, not counting time spent in deep sleep.
SystemClock.uptimeMillis()

• System#currentTimeMillis может быть установлен пользователем или телефонной сетью, поэтому время может непредсказуемо прыгать назад или вперед. При измерениях интервалов или прошедшего времени следует использовать другой таймер.

• SystemClock#uptimeMillis останавливается, когда система переходит в режим глубокого сна. Он является основой для измерений временных интервалов при использовании Thread#sleep(long), Object#wait(long) (это касается и System#nanoTime). Этот таймер подходит для измерения временных интервалов, когда интервал не захватывает спящий режим устройства.

• SystemClock#elapsedRealtime и SystemClock#elapsedRealtimeNanos захватывают и глубокий сон. Эти таймеры являются рекомендуемой универсальной основой для измерения временных интервалов.

Работа приложения не влияет на то, что происходит в глубоком сне, поэтому наши лучшие варианты - SystemClock.uptimeMillis() и System.nanoTime().

uptimeMillis() или nanoTime()?

System.nanoTime() более точен, чем uptimeMillis(), но полезно это только для микробенчмарков. При отслеживании производительности в эксплуатации нам достаточно разрешения в миллисекундах.

Давайте сравним их влияние на производительность. Я клонировал репозиторий Android Benchmark Samples и добавил следующий тест:

@LargeTest
@RunWith(AndroidJUnit4::class)
class TimingBenchmark {
    @get:Rule
    val benchmarkRule = BenchmarkRule()

    @Test
    fun nanoTime() {
        benchmarkRule.measureRepeated {
            System.nanoTime()
        }
    }

    @Test
    fun uptimeMillis() {
        benchmarkRule.measureRepeated {
            SystemClock.uptimeMillis()
        }
    }
}

Результаты на Pixel 3 под Android 10:

• System.nanoTime() среднее время: 208 нс

• SystemClock.uptimeMillis() среднее время: 116 нс

SystemClock.uptimeMillis() почти в два раза быстрее! Хотя эта разница не должна иметь сколько-нибудь значимого влияния на приложение, можем ли мы понять, почему он намного быстрее?

Реализация uptimeMillis()

SystemClock.uptimeMillis() реализована как нативный метод, аннотированный @CriticalNative. CriticalNative обеспечивает более быстрые JNI-преобразования для методов, не содержащих объектов.

public final class SystemClock {
    @CriticalNative
    native public static long uptimeMillis();
}

(источник)

Нативная реализация находится в SystemClock.cpp:

int64_t uptimeMillis()
{
    int64_t when = systemTime(SYSTEM_TIME_MONOTONIC);
    return (int64_t) nanoseconds_to_milliseconds(when);
}

(источник)

systemTime() определен в Timers.cpp:

nsecs_t systemTime(int clock) {
    static constexpr clockid_t clocks[] = {
        CLOCK_REALTIME,
        CLOCK_MONOTONIC,
        CLOCK_PROCESS_CPUTIME_ID,
        CLOCK_THREAD_CPUTIME_ID,
        CLOCK_BOOTTIME
    };
    timespec t = {};
    clock_gettime(clocks[clock], &t);
    return nsecs_t(t.tv_sec)*1000000000LL + t.tv_nsec;
}

(источник)

Реализация nanoTime()

System.nanoTime() также реализован как нативный метод, аннотированный @CriticalNative.

public final class System {
    @CriticalNative
    public static native long nanoTime();
}

(источник)

Нативная реализация находится в System.c:

static jlong System_nanoTime() {
  struct timespec now;
  clock_gettime(CLOCK_MONOTONIC, &now);
  return now.tv_sec * 1000000000LL + now.tv_nsec;
}

(источник)

Две эти реализации на самом деле очень похожи, они обе вызывают clock_gettime().

Оказывается, @CriticalNative только недавно была добавлена в System.nanoTime(), что объясняет, почему он был медленнее!

Заключение

При отслеживании производительности во время работы приложения:

• Разрешения в миллисекундах достаточно для большинства случаев.

• Для измерения временных интервалов используйте SystemClock.uptimeMillis() или System.nanoTime(). Последний работает медленнее на старых версиях Android, но сейчас это не имеет особого значения.

• Я предпочитаю SystemClock.uptimeMillis(), так как мне проще использовать миллисекунды.

• 100 мс — это предел, при котором люди перестают чувствовать, что они напрямую манипулируют объектами в пользовательском интерфейсе (т.е. имеют «интуитивный» опыт), и вместо этого начинают чувствовать, что они приказывают компьютеру выполнить действие за них, а затем ждут ответа. (источник)

• Легко запомнить, что 100 мс — это 1/10 секунды. У меня нет той же легкой напоминалки для наносекунд, я должен помнить, что 1 мс = 1 000 000 нс, а затем производить вычисления.

• SystemClock отсутствует в JDK, поэтому, если вы стремитесь писать переносимый код, вам лучше использовать System.nanoTime().

Материал подготовлен в рамках курса «Android Developer. Professional». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.