jetpack之WorkManager的使用方法

最新推荐文章于 2024-04-16 19:29:01 发布
最新推荐文章于 2024-04-16 19:29:01 发布
阅读量574 收藏
点赞数
分类专栏： Android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/LitterLy/article/details/105454655
版权

目录

jetpackd的WorkManager可以用来处理后台任务
本篇介绍jetpack的WorkManager的基本使用方法

1.配置信息

 def work_version = "2.3.1"
 // (Java only)
implementation "androidx.work:work-runtime:$work_version"
 // Kotlin + coroutines
 implementation "androidx.work:work-runtime-ktx:$work_version"
 // optional - RxJava2 support
 implementation "androidx.work:work-rxjava2:$work_version"
 // optional - GCMNetworkManager support
 implementation "androidx.work:work-gcm:$work_version"
 // optional - Test helpers
 androidTestImplementation "androidx.work:work-testing:$work_version"

2.使用方式

2.1 定义Worker

class MyWork(var context: Context, var params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        Log.e(TAG_1234, "开始执行 任务1")
        val data = params.inputData.getString("key")
        data?.let {
            Log.e(TAG_1234, "获取到传入的值 ->> $it")
        }
        val outData = Data.Builder().putString("dataKey", "传递的值任务1").build()
        return Result.success(outData)
    }
}

这里定义了一个参数获取和参数传递的方法，并回调方法Result.success() 表示方法执行完成

2.2 创建WorkRequest

 private fun getOneTimeRequest():OneTimeWorkRequest{
	    val sendData = Data.Builder().putString("key", "1234").build()
        var oneTimeRequest = OneTimeWorkRequest.Builder(MyWork::class.java)
                .setInputData(sendData).build()
	   observerWorkRequest(oneTimeRequest, type)
	   return oneTimeRequest
}

private fun observerWorkRequest(request: WorkRequest, type: Int) {
        WorkManager.getInstance(this).getWorkInfoByIdLiveData(request.id)
                .observe(this, object : Observer<WorkInfo> {
                    override fun onChanged(t: WorkInfo?) {
                        val status = t?.state
                        Log.e(TAG_1234, "work status ->> $status  $type ")
                         status?.isFinished?.apply {
                            if (this) {
                                val key = t!!.outputData.getString("dataKey")
                                if (key != null) {
                                    Log.e(TAG_1234, "执行完成 $key")
                                }
                            }
                        }
                    }
                });
    }

这里定义了一个OneTimeWorkRequest，传入了自定义的字符串，并设置了任务执行的监听，在回调中获取完成的值; 打印出当前观测的状态和结束后拿到的值，这里的键和任务Worker那里的得保持一致

2.3 执行任务

  private fun testBackgroundWork1() {
        WorkManager.getInstance(this).enqueue(getOneTimeRequest())
    }

输出结果是

E/1234: 开始执行 任务1
E/1234: 获取到传入的值 ->> 1234
E/1234: work status ->> ENQUEUED  1 
E/1234: work status ->> SUCCEEDED  1 
E/1234: 执行完成 传递的值任务1

这样一个基础的用法就完成了

3.拓展

3.1 WorkRequest

目前WorkRequest只有两个实现类 OneTimeWorkRequest 和 PeriodicWorkRequest
OneTimeWorkRequest 是只执行一次的任务，执行完就销毁
PeriodicWorkRequest 是一个周期性任务，可以指定一个周期去执行任务，但这里的周期的最小值一般是15分钟，少于15分钟的都会按15分钟来处理
二者都是通过建造模式构建的，但定期任务会额外传入时间间隔

public static final class Builder extends WorkRequest.Builder<Builder, OneTimeWorkRequest> {
	 Builder(@NonNull Class<? extends ListenableWorker> workerClass){...}
}

public static final class Builder extends WorkRequest.Builder<Builder, PeriodicWorkRequest> {
	public Builder(
                @NonNull Class<? extends ListenableWorker> workerClass,
                long repeatInterval,
                @NonNull TimeUnit repeatIntervalTimeUnit) {
           		...
        }
}

因为二者都是继承自 WorkRequest.Builder，有些公用方法可以设置，具体有

public final @NonNull B setInputData(@NonNull Data inputData)

setInputData 设置传给Worker的值，通过 Data.Builder().putString(key,value).build() 创建数据Data对象

public final @NonNull B addTag(@NonNull String tag)

addTag 给任务添加标签，可以添加多个，会放在一个set集合中，可以通过任务对象，或者在observer观测结果中获取

 public final @NonNull B setConstraints(@NonNull Constraints constraints)

setConstraints 设置约束条件，可以选择任务在满足什么样的条件下执行

public @NonNull B setInitialDelay(long duration, @NonNull TimeUnit timeUnit)

setInitialDelay 设置开始执行任务的延迟，当设置这个值时，那么该任务在加入到队列后延迟一定时间才开始执行任务

3.2 约束

我们可以指定应用在满足什么样的情况下可以执行任务，不满足情况则会等待相应条件满足再去执行
约束一般定义有以下几种

 private fun buildConstraint(): Constraints {
        return Constraints.Builder()
                .setRequiresCharging(true)                      //充电中
                .setRequiresDeviceIdle(false)                    //空闲
                .setRequiresBatteryNotLow(false)                //低电量
                .setRequiresStorageNotLow(false)                //低存储
                .setRequiredNetworkType(NetworkType.CONNECTED) //联网状态
           .build()
    }

setRequiresCharging
设置是否在充电状态下执行
setRequiresDeviceIdle
设置是否在空闲状态下执行，这个空闲指的是一段时间没有使用手机，而不是指手机里没开应用就是空闲
setRequiresBatteryNotLow
设置是否在电量低于阈值时执行，默认flase
setRequiresStorageNotLow
设置是否在存储低于阈值时执行，默认false
setRequiredNetworkType
设置执行任务的网络状态

NetworkType描述
CONNECTED需要网络连接
NOT_REQUIRED无需网络
UNMETERED非计费网络，比如wifi
NOT_ROAMING非漫游网络
METERED计费网络，比如4G

3.3 Worker

worker就是我们所创建的任务，只有一个doWork的实现方法，这里是线程池执行的

class MyWork2(var context: Context, var params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        return Result.success()
    }
}

Result有三种返回
success   成功
failure    失败
retry      重试
其中success和failure都是可以传递返回值Data的
当回传的结果是Result.retry()时，并不是马上就会重新重新尝试再次执行，而是会等一定时间再去尝试，比如我这里返回重试打印的日志是

2020-04-11 18:39:18.308 E/1234: 开始执行 任务1
2020-04-11 18:39:50.246 E/1234: 开始执行 任务1
2020-04-11 18:39:58.266 E/1234: 开始执行 任务1
2020-04-11 18:40:35.753 E/1234: 开始执行 任务1
2020-04-11 18:40:50.393 E/1234: 开始执行 任务1

而且重试时间也不是固定的，另外如果一直没重试成功过，下次进入应用还会进行重试

3.4 批次任务

3.4.1 串行
 private fun testBackgroundWork2() {
	 WorkManager.getInstance(this)
                .beginWith(getOneTimeRequest(1))
                .then(getOneTimeRequest(2))
                .then(getOneTimeRequest(3))
                .then(getOneTimeRequest(4))
                .then(getOneTimeRequest(5))
                .enqueue()
 }

或者

 val list = mutableListOf<OneTimeWorkRequest>()
        list.add(getOneTimeRequest(1))
        list.add(getOneTimeRequest(2))
        list.add(getOneTimeRequest(3))
        WorkManager.getInstance(this).beginWith(list)
                .then(getOneTimeRequest(4))
                .then(getOneTimeRequest(5))
                .enqueue()

都是可以的
比如我在上面的监听中加上任务的position信息，然后打印日志是

E/1234: 开始执行 任务1
E/1234: work status ->> ENQUEUED  1 
E/1234: work status ->> BLOCKED  2 
E/1234: work status ->> BLOCKED  3 
E/1234: 开始执行 任务2
E/1234: work status ->> BLOCKED  4 
E/1234: work status ->> BLOCKED  5 
E/1234: work status ->> SUCCEEDED  1 
E/1234: 开始执行 任务3
E/1234: work status ->> SUCCEEDED  2 
E/1234: work status ->> SUCCEEDED  3 
E/1234: work status ->> RUNNING  4 
E/1234: 开始执行 任务4
E/1234: work status ->> ENQUEUED  5 
E/1234: 开始执行 任务5
E/1234: work status ->> SUCCEEDED  4 
E/1234: work status ->> SUCCEEDED  5

然后我把任务2的返回改成Result.failure()，打印结果是

E/1234: 开始执行 任务1
E/1234: work status ->> BLOCKED  2 
E/1234: work status ->> BLOCKED  3 
E/1234: work status ->> BLOCKED  4 
E/1234: work status ->> BLOCKED  5 
E/1234: 开始执行 任务2
E/1234: work status ->> SUCCEEDED  1 
E/1234: work status ->> RUNNING  2 
E/1234: work status ->> FAILED  3 
E/1234: work status ->> FAILED  4 
E/1234: work status ->> FAILED  5 
E/1234: work status ->> FAILED  2

可见第二个任务执行出错后，后面的任务将全部不会执行，而且也全部会通知失败，所以才有并行

3.4.2 并行
  val worker1 = WorkManager.getInstance(this).beginWith(getOneTimeRequest(1)).then(getOneTimeRequest(2)).then(getOneTimeRequest(3))
        val worker2 = WorkManager.getInstance(this).beginWith(getOneTimeRequest(4)).then(getOneTimeRequest(5))
        val list = mutableListOf<WorkContinuation>()
        list.add(worker1)
        list.add(worker2)
        WorkContinuation.combine(list).enqueue()

这里定义了两个串行任务，然后把这两个任务并发处理

E/1234: 开始执行 任务1
E/1234: work status ->> ENQUEUED  1 
E/1234: 开始执行 任务4
E/1234: work status ->> BLOCKED  2 
E/1234: work status ->> BLOCKED  3 
E/1234: 开始执行 任务2
E/1234: work status ->> SUCCEEDED  4 
E/1234: 开始执行 任务5
E/1234: work status ->> ENQUEUED  5 
E/1234: 开始执行 任务3
E/1234: work status ->> SUCCEEDED  1 
E/1234: 开始执行 任务1
E/1234: work status ->> SUCCEEDED  2 
E/1234: work status ->> SUCCEEDED  3 
E/1234: work status ->> SUCCEEDED  5

可以看出任务1 ，2 ， 3 和 4， 5之间的串并行关系，然后继续吧任务2改成返回false

E/1234: application onCreate 
E/1234: 开始执行 任务1
E/1234: work status ->> ENQUEUED  1 
E/1234: 开始执行 任务4
E/1234: work status ->> BLOCKED  2 
E/1234: work status ->> BLOCKED  3 
E/1234: 开始执行 任务2
E/1234: work status ->> SUCCEEDED  4 
E/1234: 开始执行 任务5
E/1234: work status ->> ENQUEUED  5 
E/1234: work status ->> SUCCEEDED  1 
E/1234: work status ->> FAILED  2 
E/1234: work status ->> FAILED  3 
E/1234: work status ->> SUCCEEDED  5

可见两并行任务互不干扰，串行的现象和上面的一致

3.4.3 唯一任务

根据指定的唯一key名称，保证只有同一个key对应的任务正常执行，但这并不是说一定只有一个

 private fun testBackgroundWork6() {
        val request1 = getOneTimeRequest(1)
        val request2 = getOneTimeRequest(2)
        val uniqueName = "1234";
        WorkManager.getInstance(this).enqueueUniqueWork(uniqueName, ExistingWorkPolicy.KEEP, request1);
        WorkManager.getInstance(this).enqueueUniqueWork(uniqueName, ExistingWorkPolicy.REPLACE, request2)
    }

这个的输出结果是

E/1234: work status ->> ENQUEUED  2 
E/1234: 开始执行 任务2
E/1234: work status ->> SUCCEEDED  2

可见任务1没有执行，直接被任务2替换掉

这里有一个ExistingWorkPolicy参数，主要有三个值
REPLACE   替换掉之前的任务并执行
KEEP      保留之前的任务，后续的任务将不执行
APPEND    加在之前任务后面，类似串行执行

当然这个也得看执行的时机，如果任务1执行耗时较长，然后期间任务2执行了，并指定策略是REPLACE，会怎么样
比如我把任务1的任务执行方法期间睡眠1000ms，然后任务2的插入时间稍微往后挪一点

private fun testBackgroundWork6() {
        val request1 = getOneTimeRequest(1)
        val request2 = getOneTimeRequest(2)
        val uniqueName = "1234";
        WorkManager.getInstance(this).enqueueUniqueWork(uniqueName, ExistingWorkPolicy.KEEP, request1);
        GlobalScope.launch(Dispatchers.IO) {
            delay(200)
            WorkManager.getInstance(this@WorkManagerActivity).enqueueUniqueWork(uniqueName, ExistingWorkPolicy.REPLACE, request2)
        }
    }

输出结果就变为了

E/1234: 开始执行 任务1
E/1234: work status ->> RUNNING  1 
E/1234: 开始执行 任务2
E/1234: work status ->> null  1 
E/1234: work status ->> RUNNING  2 
E/1234: work status ->> SUCCEEDED  2 
E/1234: 任务1 doWork方法结束

任务1方法会继续走完，也就是说并不会强制杀死任务1，但是不会通知成功的状态，而且状态通知也变成了null；之后只会回调任务2的成功通知

3.4.4 周期任务

 private fun getPeriodRequest(constraints: Constraints?, type: Int): PeriodicWorkRequest {
        val perioadRequest = PeriodicWorkRequest.Builder(getWorkByType(type), 10, TimeUnit.SECONDS)
                .build()
        observerWorkRequest(perioadRequest, type)
        return perioadRequest
    }
 private fun getWorkByType(type: Int): Class<out Worker> {
        when (type) {
            1 -> return MyWork::class.java
            2 -> return MyWork2::class.java
            3 -> return MyWork3::class.java
            4 -> return MyWork4::class.java
            5 -> return MyWork5::class.java
        }
        return MyWork::class.java
    }

private fun testPeriod() {
        WorkManager.getInstance(this).enqueue(getPeriodRequest(buildConstraint(), 1))
 }

打印日志为，大致为15分钟左右，但也可能会有偏差

2020-04-11 19:40:57.745 E/1234: work status ->> ENQUEUED  1 
2020-04-11 19:40:57.760 E/1234: 开始执行 任务1
2020-04-11 19:40:57.767 E/1234: work status ->> RUNNING  1 
2020-04-11 19:40:58.800 E/1234: 任务1 doWork方法结束
2020-04-11 19:40:58.884 E/1234: work status ->> ENQUEUED  1 
2020-04-11 19:56:37.181 E/1234: 开始执行 任务1
2020-04-11 19:56:38.185 E/1234: 任务1 doWork方法结束

周期任务执行比较特殊，一般会设置约束条件，让在满足的条件下执行，即便此次存活期间没有执行，下次重新启动后还是会检测执行；也就是说这些任务会配合Room写进数据库，任务执行会有数据库的校验，当然卸载了也就没了
此外测试期间，如果我主动从后台把应用杀死，那么周期任务也就不会执行了，会在下次进入应用后重新检测

迷途の知归
关注
专栏目录
JetPack之WorkManger
qq_41672484的博客
03-28 297
一、WorkManger简介 1.1 作用 看google官网介绍，WorkManger旨在用于可延迟运行（不要求立即执行）并且在应用推出或者设备重启时能够可靠运行。看到这里感觉到了WorkManger似乎就是为了进程保活而诞生的，其实不然。 1.2 应用场景 （1）埋点上传 （2）非即时性上传和下载 （3）等等 试想为什么Google在有service的前提下，还会推出一个WorkManger呢？ 1.3 优势 1、确保可以被执行，并且可以设置执行的限定条件(例如仅仅在有网络连接的时候才进行图片的上传)
Android Jetpack之WorkManager使用详解
怀旧的老张 的博客
08-17 1150
简介 使用 WorkManager API 可以轻松地调度即使在应用退出或设备重启时仍应运行的可延迟异步任务。 可用于确保重要的后台任务一定会执行，比如上传，下载，同步服务器等操作 B站官方视频：https://www.bilibili.com/video/av56276889 主要功能： 最高向后兼容到 API 14 Android 4.0 在运行 API 23 及以上级别的设备上使用 JobScheduler 在运行 API 14-22 的设备上结合使用 BroadcastReceive
Jetpack—WorkManager使用
sundahao的博客
09-29 248
Jetpack—WorkManager使用WorkManager简介相关类基本用法1、依赖2、执行任务高级用法链式任务输入合并唯一工作工作状态观察工作器的中间进度先前条件重试和避退策略 WorkManager简介 WorkManager是Jetpack提供的异步任务管理组件。使用WorkManager，您可以轻松调度那些即使在退出应用或重启设备时仍应运行的可延期异步任务。 WorkManager会根据当前设备API适时的调度不同的组件实现异步任务。（包括 FirebaseJobDispatcher、GcmN
JetPack之WorkManager使用
sunlifeall的博客
03-15 326
学习目标： JetPack之WorkManager使用标 学习内容： workManager旨在用于延迟运行并且再应用退出或设备重启必须能够可靠运行的任务。 引入配置 implementation 'androidx.work:work-runtime:2.3.4' 三大概念 Worker 我们要执行的具体任务。需要继承Worker,重写doWork方法，然后在里面写具体的逻辑。 WorkRequest 上面的Worker是定义了我们要在后台的任务，而这个类是对Worker的包装。 下面两个都是继承了
SpringBoot @Async注解的学习
AnalogElectronic的博客
10-22 245
异步方法调用是希望快速相应前台界面，而不至于应为后台操作太慢了卡死在哪里。 例如： package springboot.service; import org.springframework.stereotype.Service; @Service public class ServiceImpl implements IService{ @Override public void testAsync() { new Thread(()->{
Android Jetpack - 使用WorkManager处理简单的后台任务
2401_84122826的博客
04-08 656
上面这些公司都是时下最受欢迎的互联网大厂，他们的职级、薪资、福利也都讲的差不多了，相信大家都是有梦想和野心的人，心里多少应该都有些想法。也相信很多人也都在为即将到来的金九银十做准备，也有不少人的目标都是这些公司。我这边有不少朋友都在这些厂工作，其中也有很多人担任过面试官，上面的资料也差不多都是从朋友那边打探来的。除了上面的信息，我这边还有这些大厂近年来的面试真题及解析，以及一些朋友出于兴趣和热爱一起整理的Android时下热门知识点的学习资料。
Android Jetpack 的WorkManager的使用简介
weixin_42324979的博客
10-19 556
222
Jetpack之workmanager源码解析
记录生活中的点滴美好，活在当下！
11-29 1892
<provider android:name="androidx.startup.InitializationProvider" android:exported="false" android:authorities="com.herdin.android.work.androidx-startup"> <meta-data android:name="a..
Android架构组件JetPack之WorkManager完全解析（五），快速上手
m0_65146105的博客
12-22 333
@NonNull @Override public Worker.Result doWork() { Context applicationContext = getApplicationContext(); try { Bitmap picture = BitmapFactory.decodeResource( applicationContext.getResources(), R.drawable.test); return Worker.Result.SUCCESS; } catch (Throwa
Android开发学习笔记——Jetpack之WorkManager
qq_36425800的博客
11-29 663
Android开发学习笔记——Jetpack之WorkManagerWorkManager概述基本使用Worker的调度调度一次性任务和定期任务调度一次性任务调度周期性任务环境约束延时任务WorkRequest的标记和获取任务链后台任务的管理和监听监听后台任务的执行后台任务状态任务状态后台任务执行进度后台停止和取消任务数据的输入和输出 WorkManager 概述 WorkManager是Jetpack中提供用于处理后台任务的一个库，使我们可以轻松调度那些即使在退出应用或重启设备时仍应运行的可延期异步任务。
Android Jetpack（八）WorkManager
01-03
一、WorkManager 介绍         WorkManager 是 Jetpack 组件库的一个组件，负责管理后台任务。         WorkManager API 可以让你更加容易的管理一些后台任务，即使你的应用是退出或者设备重启的状态。         WorkManager 适用于任务的延迟执行，不需要立即执行，并且可以可靠的执行即使应用退出或者设备重启。例如： 向后端服务发送日志分析 定期与服务器同步应用程序数据         WorkManager 不适用于那些在应用进程消失的时候，可以安全被终止的后台任务。       WorkManager和传统 Service
Android WorkManager浅谈
01-05
一、原文翻译 WorkManager API 可以很容易的指定可延迟的异步任务。允许你创建任务，并把它交给WorkManager来立即运行或在适当的时间运行。WorkManager根据设备API的级别和应用程序状态等因素来选择适当的方式运行任务。如果WorkManager在应用程序运行时执行你的任务，它会在应用程序进程的新线程中执行。如果应用程序没有运行，WorkManager会根据设备API级别和包含的依赖项选择适当的方式安排后台任务，可能会使用JobScheduler、Firebase JobDispatcher或AlarmManager。你不需要编写设备逻辑来确定设备有哪些功能和选择适
Android8.0后时代的后台任务JetPack-WorkManager详解
chuanao8829的博客
08-07 983
本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布 WorkManager详解 一、回顾一下以前的做法 以前我们在处理后台任务时，一般都是使用Service(含IntentService）或者线程/线程池，而Service不受页面生命周期影响，可以常驻后台，所以很适合做一些定时...
Jetpack WorkManager 看这一篇就够了~
黄林晴
07-31 1736
按照官方描述，WorkManager是适合用于持久性工作的推荐解决方案。如果工作始终要通过应用重启和系统重新启动来调度，便是持久性的工作。由于大多数后台处理操作都是通过持久性工作完成的，因此WorkManager是适用于后台处理操作的主要推荐API。Result{Log.d("打印线程",Thread.currentThread().name)}}继承自Worker的类需要重写doWork方法，我们可以在这个方法中执行具体的任务，这里为了有演示结果打印出线程的名称。.........
Android Jetpack系列 之 WorkManager
成长的烧年
05-22 1569
大概   这应该是一篇比较悲伤的文章，因为WorkManager并没有达到它所描述的功能，所以作为天朝的程序员，此处静默哀悼一秒钟，具体文章下面详述。 虽然如此，我们还是要了解一下这个WorkManager是干什么的，具体怎么干，又有什么优点或者缺点。 关于WorkManager的官方文档可见：https://developer.android.com/topic/librar...
JetPack控件WorkManager（基于Mixin Messenger）
Android小码家
02-26 1145
文章目录前言：WorkManager坐标：AppDatabaseMiXin(迷信)Dapp 前言： 开始前我们先回答几个问题 1.Jetpack是什么/怎么用？ 2.android-sunflower-0.1.6是什么？ 问题一： Jetpack是什么？ *给出下图：*简单的概括为四大组件库，可以看到他提供的功能还是蛮实用的，没有多余的部分。 Jetpack怎么用？ 这个问题比较大一下说不清...
Jetpack之WorkManager(一)
C安君的博客
09-27 709
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录前言一、WorkManager简介1.1 WorkManager是什么？1.2 WorkManager什么时候使用1.3 为什么使用WorkManager1.4 WorkManager怎么制定工作计划的二、如何使用WorkManager2.1 准备工作2.2 定义后台任务为"work"2.3 定义如何执行具体的"work"2.4 运行你的"work"2.5 "work"是如何运行的2.6 使用链实现多任务有序执行2.7 关注Work
Android架构组件JetPack之WorkManager完全解析（五）(1)
最新发布
2401_84132685的博客
04-16 1038
对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长。而不成体系的学习效果低效漫长且无助。时间久了，付出巨大的时间成本和努力，没有看到应有的效果，会气馁是再正常不过的。所以学习一定要找到最适合自己的方式，有一个思路方法，不然不止浪费时间，更可能把未来发展都一起耽误了。如果你是卡在缺少学习资源的瓶颈上，那么刚刚好我能帮到你。《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
Jetpack:WorkManager任务调度与管理
Seven丶Echo的博客
09-20 1605
WorkManager
Android jetpack里 WorkManager如何在Activity里定义一个内部类的Worker
04-19
然后，您可以通过调用WorkManager.getInstance()来获取WorkManager实例，并使用PeriodicWorkRequest.Builder()创建一个重复执行的周期性工作请求。最后，您可以调用enqueueUniquePeriodicWork方法将该请求添加到...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值