了解WorkManager的WorkSpec表

Question

我一直在我的应用程序中使用workManager。我已经看到它使用称为workSpec的表之一创建数据库。我已将所有工人信息存储在其中。我想了解表的各列，例如什么状态，运行尝试次数，period_start_time等。

我还有其他问题：

• 我已经看到疯狂的增长并且没有删除旧的未使用项，如何减小数据库的大小。
• 在图中显示的同一工作程序中，它是使用periodicRequest进行调度的，该请求每1小时运行一次，但仅运行了一次，再也没有出现过。为什么？
• 还有另一名工人必须每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   我TaskPlannerImpl：onTaskTimerElapsed 900_SEC Line 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   我TaskPlannerImpl：onTaskTimerElapsed 900_SEC Line 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   我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第29724行：05-30 12：11：28.896 17609 17609   我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行36131：05-30 12：56：28.902 17609 17609   我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

Answer 1

Regarding the workSpec table format, this is obviously an implementation details that may change in the future. I would avoid to make any changes directly to it or to assume that some particular information is stored in a particular format.

What it's currently stored there can be seen from WorkSpec source. Some of these information are accessible through WorkManager's API. As an example, you can access the attempt count both inside your Worker (ListenableWorker#getRunAttemptCount()) and through WorkInfo (WorkManager v2.1.0-alpha01 added `WorkInfo#getRunAttemptCount()'.

But again, you should never do any changes directly to WorkManager's tables or rely on its particular format.

For your other questions:

Reduce WorkManager's DB size

When you create your WorkRequest, you can specify for how long you need to keep this workRequest in the DB using keepResultsForAtLeast(). Keep in mind that once the WorkRequest is pruned from the DB you cannot get any more information on it. Another, more drastic and dangerous, option is to use WorkManager#pruneWork(). In this case WorkManager prunes from the DB all the finished work. Again, after this operation it's not possible anymore to access the WorkRequest's WorkInfo.

PeriodicWorker non repeated

Would be useful to see how you create the WorkRequest and the Worker code, on which device/OS have you seen this behavior and which WorkManager version are you using.

Non precise interval for PeriodicWorker

WorkManager tries to respect the WorkRequest parameters compatibly with the Android OS battery optimization strategies (mainly Doze mode). This may result in the Worker being shifted in the nearest maintenance window.