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问世前,我们项目中就有使用一个空视图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我们想要去解决的两个问题:
• 回调最好能在launch中处理。
• 在Activity/Fragment中自动注册。
这里借鉴了优雅地封装 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)
}
谈到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中的实现方法基本一致。
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"
}
我们简单测试一下以下四种方式直接执行100次时的性能。
测试代码可见:BenchmarkActivity.kt
https://github.com/iDeMonnnnnn/DeMon-ARA/blob/main/app/src/main/java/com/demon/ara/BenchmarkActivity.kt
测试机型:小米5
内存方面:测试过程中使用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