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()
方法里面的,这就导致了两个问题:
- 跟
startActivityForResult()/onActivityResult()
一样的痛点:调launch跳转页面获取返回结果后还是要回到Activity/Fragment
中处理。 - 生命周期
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
我们想要去解决的两个问题:
- 回调最好能在launch中处理。
- 在
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
。
废话不多说,我要在onActivityCreated
register,由于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
方式 | 1(ms) | 2(ms) | 3(ms) | 4(ms) | 5(ms) |
---|---|---|---|---|---|
startActivityForResult()/onActivityResult() | 6638 | 6638 | 6605 | 6597 | 6687 |
GhostFragment | 6589 | 6752 | 6555 | 6553 | 6572 |
Activity Results API | 6586 | 6786 | 6708 | 6666 | 6604 |
DeMon-ARA | 6974 | 6851 | 6901 | 6912 | 6839 |
内存方面:测试过程中使用AndroidStudio Profiler监测的内存波动基本一致。
源码
文章中的所以代码都可见:
DeMon-ARA
参考&致谢
优雅地封装 Activity Result API
ActivityMessenger
Glide