Понять таблицу WorkSpec WorkManager - PullRequest
Новая
       16

Понять таблицу WorkSpec WorkManager

0 голосов
/ 31 мая 2019

Я использую workManager в своем приложении. Я видел, что он создает базу данных с одной из таблиц с именем workSpec. У меня вся рабочая информация хранится в ней. Я хотел бы понять о столбцах таблицы, таких как состояние, количество попыток выполнения, period_start_time и т. Д.

ПРИМЕЧАНИЕ:

  • Версия WorkManager: 1.0.1
  • устройство всегда подключено к источнику заряда, следовательно, нет никаких шансов идти в дрему.

enter image description here

Другие вопросы у меня есть:

  • Как я могу уменьшить размер базы данных, поскольку я вижу, что она растет как сумасшедшая, а старые неиспользуемые элементы не удаляются.
  • На том же рабочем месте, показанном на изображении, он был запланирован с periodRequest, который должен запускаться каждые 1 час, но он запускался только один раз и больше не появлялся Почему?

код для периодических запросов 

 public WorkRequest createWorkRequest(int interval, String tagName) {
    if (tagName.endsWith(Task.TAG_SUFFIX)) {
        return new PeriodicWorkRequest.Builder(CommonWorker.class, interval, TimeUnit.SECONDS)
                .addTag(tagName)
                .build();
    }

    return new OneTimeWorkRequest.Builder(CommonWorker.class)
            .setInitialDelay(interval, TimeUnit.SECONDS)
            .addTag(tagName)
            .build();
}

и 

 private void triggerSchedulerFor(int interval, String tagName) {
    WorkRequest workRequest = zdsWorkRequest.createWorkRequest(interval, tagName);
    Operation operation;
    if (tagName.endsWith(Task.TAG_SUFFIX)) {
        operation = workManager.enqueueUniquePeriodicWork(tagName,
                ExistingPeriodicWorkPolicy.REPLACE,
                (PeriodicWorkRequest) workRequest);

    } else {
        operation = workManager.enqueueUniqueWork(tagName, ExistingWorkPolicy.REPLACE,
                (OneTimeWorkRequest) workRequest);

    }
    Log.i(TAG, "State for Tag = " + tagName + "  is = " + operation.getState().getValue());
}
  • Был другой работник, который должен периодически запускаться каждые 15 минут, но я видел шаблон, который запускается ровно каждые 15 минут, но через каждые 1 час 15 минутный работник запускается с задержкой в ​​11 минут, т.е. ниже - трассировка журнала

Строка 2614: 05-30 09: 41: 28.876 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Line 6359: 05-30 09: 56: 28.907 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 9081: 05-30 10: 11: 52.355 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 12991: 05-30 10: 26: 28,901 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Line 17115: 05-30 10: 50: 03.389 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 18727: 05-30 10: 56: 28.881 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 20945: 05-30 11: 11: 28,907 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Line 23068: 05-30 11: 26: 28.909 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 26932: 05-30 11: 52: 40.685 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 27598: 05-30 11: 56: 28.903 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Line 29724: 05-30 12: 11: 28.896 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 31790: 05-30 12: 26: 28.902 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 34414: 05-30 12: 46: 14.844 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Line 36131: 05-30 12: 56: 28.902 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 38692: 05-30 13: 11: 28.881 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC Строка 41469: 05-30 13: 26: 28,902 17609 17609 I TaskPlannerImpl: onTaskTimerElapsed 900_SEC

1 Ответ

0 голосов
/ 31 мая 2019

Что касается формата таблицы workSpec, это, очевидно, детали реализации, которые могут измениться в будущем.Я бы не стал вносить какие-либо изменения непосредственно в него или предполагать, что некоторая конкретная информация хранится в определенном формате.

То, что в настоящее время хранится там, можно увидеть из WorkSpec источника .Часть этой информации доступна через API WorkManager.Например, вы можете получить доступ к количеству попыток как внутри вашего Worker (ListenableWorker#getRunAttemptCount()), так и через WorkInfo (добавлен WorkManager v2.1.0-alpha01 `WorkInfo # getRunAttemptCount () '.

Но опять же, вы никогда не должны вносить какие-либо изменения непосредственно в таблицы WorkManager или полагаться на его конкретный формат.

По другим вопросам:

Уменьшите размер БД WorkManager

Когда вы создаете свой WorkRequest, вы можете указать, как долго вам нужно хранить этот workRequest в БД, используя keepResultsForAtLeast(). Имейте в виду, что после того, как WorkRequest будет удален из БД, выне может получить больше информации о нем. Другой, более радикальный и опасный вариант - использовать WorkManager#pruneWork(). В этом случае WorkManager удаляет из БД всю законченную работу. Опять же, после этой операции это невозможнобольше для доступа к WorkRequest WorkInfo.

PeriodicWorker без повторов

Было бы полезно увидеть, как вы создаете WorkRequest и код Worker, oНа каком устройстве / ОС вы видели такое поведение, и какую версию WorkManager вы используете.

Неточный интервал для PeriodicWorker

WorkManager пытается соблюдать параметры WorkRequest, совместимые со стратегиями оптимизации батареи ОС Android(в основном режим доза).Это может привести к смещению работника в ближайшем окне обслуживания .

...