我正在参与掘金创作者训练营第6期，点击了解活动详情

startActivityForResult 可以说是我们常用的一种操作了，用于启动新页面并拿到这个页面返回的数据，是两个 Activity 交互的基本操作。

虽然可以通过接口，消息总线，单例池，ViewModel 等多种方法来间接的实现这样一个功能，但是 startActivityForResult 还是使用最方便的。

目前有哪些方式实现 startActivityForResult 的功能呢？

有新老两种方式，过时的方法是原生Activity/Fragment的 startActivityForResult 方法。另一种方法是 Activity Result API 通过 registerForActivityResult 来注册回调。

我们一起看看都是如何使用，使用起来方便吗？通常我们又都是如何封装的呢？

不管是Activity还是Fragment，我们都可以使用 startActivityForResult

可以看到虽然标记过时了，但是 startActivityForResult 这种方法是可以用的，我们一直这么用的，老项目中有很多页面都是这么定义的。也并没有什么问题。

不过既然谷歌推荐我们使用 Result Api 我们在以后使用 startActivityForResult 的时候还是推荐使用新的方式。

在之前我们使用 startActivityForResult 这种方式的时候，为了更加方便的私有，有一种很流行的方式 Ghost 。

它使用一种 GhostFragment 的空视图当做一次中转，这种思路在现在看来已经不稀奇了，很多框架如Glide,权限申请等都是用的这种方案。

它的大致实现流程为：

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

总体需要两个类就可以完成这个逻辑，一个是中转Fragment，一个是管理类：

如此我们就可以使用Kotlin的扩展方法来对它进行进一步的封装

使用起来就超级简单了：

其实看Ghost的原来就看得出，他本质上还是对 startActivityForResult 的调用与封装，还是过期的方法，那么如何使用新的方式，谷歌推荐我们怎么用？

Activity Result API ：

它是 Jetpack 的一个组件，这是官方用于替代 startActivityForResult() 和 onActivityResult() 的工具，我们以Activity 1.2.4版本为例：

implementation "androidx.activity:activity-ktx:1.2.4"

那么如何基础的使用它呢：

看起来实现很简单，但是有几点要注意，Launcher 的创建需要在onStart生命周期之前，并且回调是在 Launcher 中处理的。并且 这些 Launcher 并不是只能返回Activity的Result的，还有其他的启动方式：

可以看到这些方式其实对我们来说很多没必要，在真正的开发中只有 StartActivityForResult 这一种方式是我们的刚需。

为什么？毕竟现在谁还用这种方式申请权限，操作多媒体文件。相信大家也都是使用框架来处理了，所以我们这里只对 StartActivityForResult 这一种方式做处理。毕竟这才是我们使用场景最多的，也是我们比较需要的。

经过分析，对Result Api的封装，我们就剩下的两个重点问题：

下面我们就来实现吧。

我们需要做的是：

第一步我们把回调封装到launch方法中，并简化创建的对象方式

第二步我们尝试自动注册的功能

首先第一步，我们对 Launcher 对象做一个封装， 把 ActivityResultCallback 回调方法在 launch 方法中调用。

上门是对Result的基本封装，由于我们只想要 StartActivityForResult 这一种方式，所以我们定义一个特定的 GetSAFLauncher

注意这里调用的是 ActivityResultContracts.StartActivityForResult() 并且泛型的两个参数是 Intent 和 ActivityResult。

如果大家想获取文件，可以使用 GetContent() 泛型的参数就要变成 String 和 Uri 。由于我们通常不使用这种方式，所以这里不做演示。

封装第一步之后我们就能这么使用了。

//或者使用我们自定义的简洁方式

使用下来是不是简单了很多了，我们只需要创建一个对象就可以了，拿到这个对象调用launch即可实现 startActivityForResult 的功能呢！

可以看到相比原始的用法，虽然我们现在的用法就简单了很多，但是我们还是要在oncreate生命周期中创建 Launcher 对象，不然会报错：

LifecycleOwners must call register before they are STARTED.

那我们有哪些方法处理这个问题？

1）基类定义

我们都已经封装成对象使用了，我们把创建的逻辑定义到BaseActivity/BaseFragment不就行了吗？

这样不就行了吗？可以正常使用的。那有人可能说，你这个对象可能用不到，又不是每一个Activity都会用到 Launcher 对象，你这么无脑创建出来消耗内存。

有办法，按需加载！

2).懒加载

懒加载可以吧，我需要的时候就创建。

额，等等，这样的懒加载貌似是不行的，这在用的时候才初始化，一样会报错：

LifecycleOwners must call register before they are STARTED.

我们只能在页面创建的时候就要明确，这个页面是否需要这个 Launcher 对象，如果要就要在onCreate中创建对象，如果确定不要 Launcher 对象，那么就不必创建对象。

那我们就这么做：

我们使用一个flag判断不就行了吗？这个页面如果需要 Launcher 对象，重写方法返回true就行了。默认是不创建这个对象的。

3).Kotlin委托

我们可以使用Kotlin的委托方式，把初始化的代码和 Launcher 的对象获取用接口封装，然后提供对应的实现类，不就可以完成按需添加 Launcher 的效果了吗？

我们定义一个接口，由于逻辑都封装在了别处，这里就尽量不改动之前的代码，只是定义初始化和提供对象两种方法。

接着定义这个实现类

然后我们就可以使用了：

效果都是一样的：

这样通过委托的方式，我们就能自己管理初始化，自己随时获取到对象调用launch方法。

如果你当前的Activity不需要 startActivityForResult 这种功能，那么你不实现这个接口即可，如果想要 startActivityForResult 的功能，就实现接口委托实现，从而实现按需加载的逻辑。

我们再回顾一下 Result Api 需要封装的两个痛点与优化步骤：

同时我们还对一些步骤做了更多的可能性分析，对主动注册的方式我们有三种方式，（当然其实还有更多别的方式来实现，我只写了我认为比较简单方便的几种方式）。

到此对 Result Api的封装就此结束。

总的来说 Result Api 的封装其实也不难，使用起来也是很简单了。如果大家是Kotlin项目我推荐使用委托的方式，如果是Java语言开发的也可以用flag的方式实现按需加载的逻辑。

而不想使用 Result Api 那么使用原始的 startActivityForResult 也能实现，那么我推荐你使用 Ghost 框架，可以更加方便快速的实现返回的功能。

本文对于 Result Api 的封装也只是限于 startActivityForResult 这一个场景，不过我们这种方式是很方便扩展的，如果大家想使用Result Api的方式来操作权限，文件等，都可以在 BaseResultLauncher 基础上进行扩展。

本文全部代码均以开源，源码在此。大家可以点个Star关注一波。

好了，本期内容如有错漏的地方，希望同学们可以指出交流。

如果感觉本文对你有一点点点的启发，还望你能点赞支持一下,你的支持是我最大的动力。

Ok,这一期就此完结。