在androidx.lifecycle:lifecycle-common:2.6.1中，lifecycleScope.launchWhenResumed 标记了Deprecated
根据文档描述，推荐使用repeatOnLifecycle 进行替代，代码如下
lifecycleScope.launch {
repeatOnLifecycle(Lifecycle.State.RESUMED){
}
}
但是实际上我们知道，上述代码是每当lifecycleOwner状态变更到resume时会重复执行，这意味着官方文档有一定的误导性，两者执行并没有相同的结果。
我们先来分析为什么这个方法被弃用了,首先看弃用说明，大致描述是当代码执行到launchWhenResumed，并且此时用户将lifecycleOwner销毁或至于后台等操作后，代码将保存在暂停点(如delay)，直到恢复到相应的生命周期后继续执行，会有一定的资源浪费。
举例说明，请参考下方代码配套理解：如果代码执行到launchWhenResumed ，用户快速切走，此时代码将保存到暂停点，直到恢复生命周期，此时的保存暂停点行为目前官方认为是资源浪费。因为保存的时间有可能相当长，并不可控，例如首页加载接口准备弹出dialog，但是用户进了二级页面，这个时间不可控，有可能直到用户销毁了app也不能执行到此处。
例如如下代码：
当打印1111111后，将app切换到二级页面，然后XX秒以后切换回当前页面，此时会打印22222，实际代码为使用全局变量保存了代码片段。
lifecycleScope.launchWhenResumed {
delay(1000) //暂停点1
Log.v("ssssss", "1111111")
delay(5000) //暂停点2
Log.v("ssssss", "22222222")
}
而repeatOnLifecycle则不同，相同的代码片段如下：
当打印111111后，将app切换到二级页面，然后XX秒以后切换回当前页面，此时会打印继续打印111111，5秒后打印222222，实际代码为当脱离预期的生命周期后，代码片段被销毁，直到恢复生命周期，重新从头开始执行代码片段，这样就与launchWhenResumed 的全局保存暂停点的做法不同了，没有资源浪费。
lifecycleScope.launch {
repeatOnLifecycle(Lifecycle.State.RESUMED) {
delay(1000)
Log.v("sssss", "111111")
delay(5000)
Log.v("ssssss", "2222222")
}
}
如此例子相信大家已经能理解为何官方弃用了launchWhenResumed，因为他脱离了官方对于该方法的预期行为。
那么我们应该怎么做呢？
在官方issue中，推荐的做法为三种：
- 原子操作，即当代码执行后，无论用户怎么操作，都会执行到最后。我想，大多数情况已经能够满足我们的使用了，毕竟很多时候我们仅仅是使用该方法进行dialog处理。
lifecycleScope.launch {
withResumed {
Log.v("sssss", "111111")
Log.v("ssssss", "2222222")
}
}
2.当生命周期脱离预期时，取消代码，并在生命周期恢复后重新执行，即，代码执行到暂停点时(例如：delay)，生命周期脱离预期，执行被销毁，生命周期恢复后，代码从头开始运行，就像我上述说的代码片段一样，不过此情况可能并不常用。
lifecycleScope.launch {
var isComplete = false
repeatOnLifecycle(Lifecycle.State.RESUMED) {
if (!isComplete) {
// Do your work here. It will be canceled if the Lifecycle
// goes down while it is running
doYourOneTimeWork()
// Then mark the work as complete
isComplete = true
}
}
}
3.当生命周期脱离预期时，取消代码，并且生命周期恢复后也不再执行。
lifecycleScope.launch {
var isComplete = false
repeatOnLifecycle(Lifecycle.State.STARTED) {
if (!isComplete) {
try {
// Do your work here. It will be canceled if the Lifecycle
// goes down while it is running
doYourOneTimeWork()
} finally {
// By marking the work as complete in the finally block,
// we never restart the block just leaving it potentially
// half complete.
isComplete = true
}
}
}
}
所以基于官方的代码说明及预期，按照我们的常用方式，我们可以做如下封装。
//
//非原子方法
//-1 始终重试，
//1 默认尝试一次无论成功失败。
inline fun LifecycleOwner.launchWhenResumed(
retryTime: Int = 1,
crossinline block: suspend CoroutineScope.() -> Unit
) {
lifecycleScope.launch {
var retryCount = 0
repeatOnLifecycle(Lifecycle.State.RESUMED) {
try {
block()
this@launch.cancel()
} finally {
if (retryTime != -1) {
retryCount += 1
if (retryCount >= retryTime) {
this@launch.cancel()
}
}
}
}
}
}
//原子方法
inline fun LifecycleOwner.launchWhenResumedSync(crossinline block: () -> Unit) {
lifecycleScope.launch {
withResumed {
block()
}
}
}
如此两个方法，便能大致与之前达到一样的效果了。当然，非要达到之前的效果，那就只能自己收到保存暂停点了，不过那种做法官方并不推荐，不过这里也给出一个大概思路
//伪代码，仅提供思路。
lifecycleScope.launch {
var step1 = false
var step2 = false
repeatOnLifecycle(Lifecycle.State.RESUMED) {
if(!step1) {
step1()
step1 = true
}
if(!step2){
step2()
step2 = true
}
}
}
网友评论