在Kotlin中探索 Activity Results API 极简的解决方案

Activity Results API

Activity Result API提供了用于注册结果、启动结果以及在系统分派结果后对其进行处理的组件。—Google官方文档

https://developer.android.google.cn/training/basics/intents/result?hl=zh-cn

一句话解释:官方Jetpack组件用于代替startActivityForResult()/onActivityResult()。

看完文档会发现,能代替startActivityForResult(),但也并没有好用到哪去。

其实startActivityForResult()的调用并不麻烦,复杂页面的使用,做一下简单的封装即可。核心痛点在onActivityResult()的结果回调必须在Activity/Fragment中,导致我们在处理一些复杂的跳转逻辑时,总是要反复"横跳"。

Activity Result API的出现貌似可以解决这一痛点,页面返回结果直接通过回调就可以获得,还可以自定义跳转协议,进一步封装简化。

本来是那么的美好,然而在activity-ktx:1.2.0-beta02版本之后,变得让人望而却步。

https://developer.android.google.cn/jetpack/androidx/releases/activity?hl=zh-cn#1.2.0-beta02

行为变更
现在,尝试使用 Lifecycle 已达到 STARTED 的 LifecycleOwner 调用 register() 时,ActivityResultRegistry 会抛出 IllegalStateException。(b/165435866)

熟悉Activity Results API的都知道,页面返回结果的回调函数是在registerForActivityResult()方法里面的,这就导致了两个问题:

1. 跟startActivityForResult()/onActivityResult()一样的痛点:调launch跳转页面获取返回结果后还是要回到Activity/Fragment中处理。

2. 生命周期STARTED前注册,意味着我们必须提前注册而无法在点击使用时注册,只能在BaseActvity中封装。

但是遵循了高聚合低耦合的思想,封装在BaseActvity中的方案我们是万万拒绝的。

接下来我们就来探讨如何在不封装BaseActvity的情况下只调用一个带回调的函数实现startActivityForResult()/onActivityResult()。

解决思路

非Activity Results API方案

其实早在Activity Results API问世前,我们项目中就有使用一个空视图GhostFragment作为中转回调的方案来实现。

大概的思路如下:

Activty/Fragment——>add GhostFragment——>onAttach中startActivityForResult——>GhostFragment onActivityResult接收结果——>callback回调给Activty/Fragment

代码实现

GhostFragment.kt

https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/app/src/main/java/com/demon/ara/ghost/GhostFragment.kt

class GhostFragment : Fragment() {

    private var requestCode = -1
    private var intent: Intent? = null
    private var callback: ((result: Intent?) -> Unit)? = null

    fun init(requestCode: Int, intent: Intent, callback: ((result: Intent?) -> Unit)) {
        this.requestCode = requestCode
        this.intent = intent
        this.callback = callback
    }

    private var activityStarted = false

    override fun onAttach(activity: Activity) {
        super.onAttach(activity)
        if (!activityStarted) {
            activityStarted = true
            intent?.let { startActivityForResult(it, requestCode) }
        }
    }

    override fun onAttach(context: Context) {
        super.onAttach(context)
        if (!activityStarted) {
            activityStarted = true
            intent?.let { startActivityForResult(it, requestCode) }
        }
    }

    override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
        super.onActivityResult(requestCode, resultCode, data)
        if (resultCode == Activity.RESULT_OK && requestCode == this.requestCode) {
            callback?.let { it1 -> it1(data) }
        }
    }

    override fun onDetach() {
        super.onDetach()
        intent = null
        callback = null
    }
}

Ghost.kt

https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/app/src/main/java/com/demon/ara/ghost/Ghost.kt
object Ghost {
    var requestCode = 0
        set(value) {
            field = if (value >= Integer.MAX_VALUE) 1 else value
        }

    inline fun launchActivityForResult(
        starter: FragmentActivity?,
        intent: Intent,
        crossinline callback: ((result: Intent?) -> Unit)
    ) {
        starter ?: return
        val fm = starter.supportFragmentManager
        val fragment = GhostFragment()
        fragment.init(++requestCode, intent) { result ->
            callback(result)
            fm.beginTransaction().remove(fragment).commitAllowingStateLoss()
        }
        fm.beginTransaction().add(fragment, GhostFragment::class.java.simpleName)
            .commitAllowingStateLoss()
    }

}

看到这里有同学就会质疑了,每次都添加一个Fragment就为了回调简化代码,这不浪费内存么?值得么?

第一次看到这个代码我也是迟疑的,直到我看了Glide的源码。

https://github.com/bumptech/glide

使用了Glide库的同学,开发中肯定有遇到如下报错:

You cannot start a load for a destroyed activity

放一个Glide源码的片段:

  @NonNull
  public RequestManager get(@NonNull FragmentActivity activity) {
    if (Util.isOnBackgroundThread()) {
      return get(activity.getApplicationContext());
    } else {
      assertNotDestroyed(activity);
      frameWaiter.registerSelf(activity);
      FragmentManager fm = activity.getSupportFragmentManager();
      return supportFragmentGet(activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
    }
  }

 @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
  private static void assertNotDestroyed(@NonNull Activity activity) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1 && activity.isDestroyed()) {
      throw new IllegalArgumentException("You cannot start a load for a destroyed activity");
    }
  } 

看到这里大家应该是明白了,这个方案在Glide中被大家“发扬光大”了而已。

Activity Results API方案

再来思考一下如何使用Activity Results API实现。

根据前文提到的,Activity Results API我们想要去解决的两个问题:

• 回调最好能在launch中处理。

• 在Activity/Fragment中自动注册。

1. 回调改造在launch中处理

这里借鉴了优雅地封装 Activity Result API的思路,非常巧妙。

https://blog.csdn.net/c10WTiybQ1Ye3/article/details/119430078

DeMonActivityResult.kt

https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/core/src/main/java/com/demon/core/DeMonActivityResult.kt
class DeMonActivityResult(caller: ActivityResultCaller, contract: ActivityResultContract) {

    /**
     * 直接点击返回键或者直接finish是否会触发回调
     * 用于处理一些特殊情况:如只要返回就刷新等
     * 注意此时回调返回的值或者{ActivityResult#getData()}应该为空,需要做好判空处理
     */
    private var isNeedBack = false

    private var launcher: ActivityResultLauncher? = caller.registerForActivityResult(contract) {
        if (isNeedBack) {
            callback?.onActivityResult(it)
        } else {
            if (it != null) {
                if (it is ActivityResult) {
                    if (it.resultCode == Activity.RESULT_OK) callback?.onActivityResult(it)
                } else {
                    callback?.onActivityResult(it)
                }
            }
        }
        callback = null
    }

    private var callback: ActivityResultCallback? = null


    @JvmOverloads
    fun launch(input: I, isNeedBack: Boolean = false, callback: ActivityResultCallback?) {
        this.callback = callback
        this.isNeedBack = isNeedBack
        launcher?.launch(input)
    }

2. 在Activity/Fragment中自动注册

谈到Activity生命周期监听,有个始终绕不开的接口类Application.ActivityLifecycleCallbacks。

废话不多说,我要在onActivityCreatedregister,由于Activity Result API是自动反注册的,所以我们不用关心unRegister。

然后就是register后,怎么拿到ActivityResultLauncher呢?(经过上一步的改造后,我们需要拿到的是DeMonActivityResult)

恕在下才识浅薄,只能想到用HashMap。

    //临时存储DeMonActivityResult
    val resultMap = mutableMapOf>()

大概的思路如下:

onActivityCreated——>时间戳生成唯一key——>key putExtra存Activty——>register得到Result——>将Result与key存HashMap

Activty——>getStringExtra得key——>HashMap得Result——>Result.launch启动——>launch回调得返回结果

Fragment的生命周期监听与Activty类似,可以通过注册并实现抽象类FragmentLifecycleCallbacks:

//注册监听Fragment生命周期
activity.supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentCallbacks, false)
//反注册取消监听Fragment生命周期
activity.supportFragmentManager.unregisterFragmentLifecycleCallbacks(it)

因此Fragment与Activity中的实现方法基本一致。

3. 实现代码

DeMonActivityCallbacks.kt

https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/core/src/main/java/com/demon/core/lifecycle/DeMonActivityCallbacks.kt

object DeMonActivityCallbacks : Application.ActivityLifecycleCallbacks {
    private val TAG = "DeMonActivityCallbacks"

    const val DEMON_ACTIVITY_KEY = "DeMon_Activity_Key"
    val DEMON_FRAGMENT_KEY = "DeMon_Fragment_Key"

    //临时存储FragmentCallbacks
    val callbackMap = mutableMapOf()

    //临时存储DeMonActivityResult
    val resultMap = mutableMapOf>()

    override fun onActivityCreated(activity: Activity, p1: Bundle?) {
        if (activity is FragmentActivity) {
            val mapKey: String = activity.javaClass.simpleName + System.currentTimeMillis()
            Log.i(TAG, "onActivityCreated: mapKey=$mapKey")
            //注册
            val fragmentCallbacks = DeMonFragmentCallbacks()
            callbackMap[mapKey] = fragmentCallbacks
            activity.supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentCallbacks, false)
            val result = DeMonActivityResult(activity, ActivityResultContracts.StartActivityForResult())
            activity.intent.putExtra(DEMON_ACTIVITY_KEY, mapKey)
            resultMap[mapKey] = result
        }
    }

    override fun onActivityDestroyed(activity: Activity) {
        if (activity is FragmentActivity) {
            val mapKey = activity.intent.getStringExtra(DEMON_ACTIVITY_KEY)
            Log.i(TAG, "onActivityDestroyed: mapKey=$mapKey")
            if (!mapKey.isNullOrEmpty()) {
                callbackMap[mapKey]?.let { activity.supportFragmentManager.unregisterFragmentLifecycleCallbacks(it) }
                //移除
                callbackMap.remove(mapKey)
                resultMap.remove(mapKey)
            }
        }
    }

    override fun onActivityStarted(p0: Activity) {}
    override fun onActivitySaveInstanceState(p0: Activity, p1: Bundle) {}
    override fun onActivityResumed(p0: Activity) {}
    override fun onActivityPaused(p0: Activity) {}
    override fun onActivityStopped(p0: Activity) {}
}

篇幅原因Fragment生命周期监听和实现可见:DeMonFragmentCallbacks.kt

https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/core/src/main/java/com/demon/core/lifecycle/DeMonFragmentCallbacks.kt

我们这里固定注册的是ActivityResultContracts.StartActivityForResult(),可能又会又同学觉得这样无法自定义跳转协定,太不灵活了。

其实不然,我们可以封装扩展Intent,比如大神陈小缘的ActivityMessenger

https://github.com/Ifxcyr/ActivityMessenger

我们这个库也是按照这个思路对Intent进行了扩展,使用起来一样很方便,可以看本库的源码

https://github.com/iDeMonnnnnn/DeMon-ARA

接下来我们只需要在Application中:registerActivityLifecycleCallbacks(DeMonActivityCallbacks)即可。

值得注意的是registerActivityLifecycleCallbacks每次调用就是在回调集合中添加一个ActivityLifecycleCallbacks对象,集合中的每个ActivityLifecycleCallbacks都可以收到回调,因此可以注册多个。

简单处理一下获取DeMonActivityResult的逻辑:

@JvmStatic
fun getActivityResult(@NonNull activity: FragmentActivity): DeMonActivityResult? {
    activity.run {
        val mapKey = intent.getStringExtra(DeMonActivityCallbacks.DEMON_ACTIVITY_KEY)
        return if (!mapKey.isNullOrEmpty()) {
            DeMonActivityCallbacks.resultMap[mapKey]
        } else {
            null
        }
    }
}

接下来我们可以在Activty/Fragment按照如下Java代码中使用即可:

DeMonActivityResult result = DeMonAraHelper.getActivityResult(JavaActivity.this);
if (result != null) {
    result.launch(new Intent(this, TestJumpActivity.class), true,
            data -> {
                if (data.getData() != null) {
                    String str = data.getData().getStringExtra("tag");
                    binding.text.setText("跳转页面返回值:" + str);
                } else {
                    binding.text.setText("我是返回键返回的,没有返回值~");
                }
            });
}    

走到这里我们就实现了我们最初的目标:调用一个带回调的函数实现

startActivityForResult()/onActivityResult()。

而且如果是Kotlin中进一步扩展调用只会更简单,如:

forActivityResult(pairIntent()) {
    val str = it?.getStringExtra("tag") ?: ""
    text.text = "跳转页面返回值:$str"
}

Benchmark

我们简单测试一下以下四种方式直接执行100次时的性能。

测试代码可见:BenchmarkActivity.kt

https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/app/src/main/java/com/demon/ara/BenchmarkActivity.kt

测试机型:小米5

在Kotlin中探索 Activity Results API 极简的解决方案_第1张图片

内存方面:测试过程中使用AndroidStudio Profiler监测的内存波动基本一致。

源码

文章中的所以代码都可见:

DeMon-ARA

https://github.com/iDeMonnnnnn/DeMon-ARA

参考&致谢

优雅地封装 Activity Result API

https://blog.csdn.net/c10WTiybQ1Ye3/article/details/119430078

ActivityMessenger

https://github.com/Ifxcyr/ActivityMessenger

Glide

https://github.com/bumptech/glide

你可能感兴趣的:(Android,android)