Android Activity Results API自动化注册&极简使用方案

Activity Results API

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

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

看完文档会发现，能代替startActivityForResult()，但也并没有好用到哪去。
其实startActivityForResult()的调用并不麻烦，复杂页面的使用，做一下简单的封装即可。核心痛点在onActivityResult()的结果回调必须在Activity/Fragment中，导致我们在处理一些复杂的跳转逻辑时，总是要反复"横跳"。
Activity Result API的出现貌似可以解决这一痛点，页面返回结果直接通过回调就可以获得，还可以自定义跳转协议，进一步封装简化。
本来是那么的美好，然而在activity-ktx: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作为中转回调的方案来实现。

大概的思路如下：

代码实现

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

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的源码。
使用了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我们想要去解决的两个问题：

1. 回调最好能在launch中处理。
2. 在Activity/Fragment中自动注册。

1. 回调改造在launch中处理

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

DeMonActivityResult.kt

class DeMonActivityResult<I, O>(caller: ActivityResultCaller, contract: ActivityResultContract<I, O>) {    /**     * 直接点击返回键或者直接finish是否会触发回调     * 用于处理一些特殊情况：如只要返回就刷新等     * 注意此时回调返回的值或者{ActivityResult#getData()}应该为空，需要做好判空处理     */    private var isNeedBack = false    private var launcher: ActivityResultLauncher<I>? = 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<O>? = null    @JvmOverloads    fun launch(input: I, isNeedBack: Boolean = false, callback: ActivityResultCallback<O>?) { 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<String, DeMonActivityResult<Intent, ActivityResult>>()

大概的思路如下：

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

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

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

3. 实现代码

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<String, DeMonFragmentCallbacks>()    //临时存储DeMonActivityResult    val resultMap = mutableMapOf<String, DeMonActivityResult<Intent, ActivityResult>>()    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

我们这里固定注册的是ActivityResultContracts.StartActivityForResult()，可能又会又同学觉得这样无法自定义跳转协定，太不灵活了。
其实不然，我们可以封装扩展Intent，比如大神陈小缘的ActivityMessenger
我们这个库也是按照这个思路对Intent进行了扩展，使用起来一样很方便，可以看本库的源码 。

接下来我们只需要在Application中：registerActivityLifecycleCallbacks(DeMonActivityCallbacks)即可。
值得注意的是registerActivityLifecycleCallbacks每次调用就是在回调集合中添加一个ActivityLifecycleCallbacks对象，集合中的每个ActivityLifecycleCallbacks都可以收到回调，因此可以注册多个。

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

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

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

    DeMonActivityResult<Intent, ActivityResult> 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<ActResultActivity>()) {      val str = it?.getStringExtra("tag") ?: ""      text.text = "跳转页面返回值：$str"  }

Benchmark

我们简单测试一下以下四种方式直接执行100次时的性能。
测试代码可见：BenchmarkActivity.kt
测试机型：小米5

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

源码

文章中的所以代码都可见：
DeMon-ARA

参考&致谢

优雅地封装 Activity Result API
ActivityMessenger
Glide