手把手教你搭建android模块化项目框架番外(一) launc

在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中，推荐的做法为三种：

1. 原子操作，即当代码执行后，无论用户怎么操作，都会执行到最后。我想，大多数情况已经能够满足我们的使用了，毕竟很多时候我们仅仅是使用该方法进行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
                }
            }
        }