一道面试题：介绍一下 Fragment 间的通讯方式?

时间  2021-08-13
标签 java android markdown 架构 app ide 函数 工具 post 栏目 快乐工作 繁體版
原文   原文链接

这是我参与更文挑战的第8天，活动详情查看： 更文挑战java

image.png

Fragment 间的通讯能够借助如下几种方式实现：android

  1. EventBus
  2. Activity（or Parent Fragment）
  3. ViewModel
  4. Result API

1. 基于 EventBus 通讯

EventBus 的优缺点都很突出。 优势是限制少可随意使用，缺点是限制太少使用太随意。markdown

由于 EventBus 会致使开发者在架构设计上“不思进取”，随着项目变复杂，结构愈来愈混乱，代码可读性变差，数据流的变化难以追踪。架构

因此，规模越大的项目 EvenBus 的负面效果越明显，所以不少大厂都禁止 EventBus 的使用。因此这道题千万不要把 EventBus 做为首选答案，比较得体的回答是：app

“ EventBus 具有通讯能力，可是缺点很突出，大量使用 EventBus 会形成项目难以维护、问题难以定位，因此我不建议在项目中使用 EventBus 进行通讯。 ”ide

2. 基于 Activity 或父 Fragment 通讯

为了迭代更加敏捷，Fragment 从 AOSP 迁移到了 AndroidX ，这致使同时存在着两种包名的 Fragment：android.app.Fragment 和 andoridx.fragment.app.Fragment。函数

虽然前者已经被废弃，但不少历史代码中尚存， 对于老的Fragment，常常依赖基于 Activity 的通讯方式，由于其余通讯方式大都依赖 AndroidX 。工具

class MainActivity : AppCompatActivity() {

    val listFragment: ListFragment by lazy {
        ListFragment()
    }

    val CreatorFragment: CreatorFragment by lazy {
        // 构建Fragment的时候设置 Callback，创建通讯
        CreatorFragment().apply { 
            setOnItemCreated { 
                listFragment.addItem(it)
            }
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        supportFragmentManager.beginTransaction().apply {
            add(R.id.fragmentContainer, listFragment)
            commit()
        }
    }
}
复制代码

如上，在 Activity 或父 Fragment 中建立子Fragment，同时为其设置 Callbackpost

此时，Fragment 的建立依赖手动配置，没法在 ConfigurationChangeed 的时候自动恢复重建，因此除了用来处理 android.app.Fragment 的历史遗留代码以外，不推荐使用。ui

3. 基于 ViewModel 通讯

ViewModel 是目前使用最普遍的通讯方式之一，在 Kotlin 中使用时，须要引入fragment-ktx

class ListViewModel : ViewModel() {
    private val originalList: LiveData<List<Item>>() = ...
    val itemList: LiveData<List<Item>> = ...

    fun addItem(item: Item) { 
      //更新 LiveData
    }

}

class ListFragment : Fragment() {
    // 借助ktx，使用activityViewModels()代理方式获取ViewModel
    private val viewModel: ListViewModel by activityViewModels()
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        viewModel.itemList.observe(viewLifecycleOwner, Observer { list ->
            // Update the list UI
        }
    }
}

class CreatorFragment : Fragment() {
    private val viewModel: ListViewModel by activityViewModels()
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        
        button.setOnClickListener {
          val item = ...
          viewModel.addItem(item)
        }
    }
}

复制代码

如上，经过订阅 ViewModel 的 LiveData，接受数据变通的通知。由于两个 Fragment 须要共享ViewModel，因此 ViewModel 必须在 Activity 的 Scope 中建立

关于 ViewModel 的实现原理，相关文章不少，本文不作赘述了。接下来重点看一下 Result API：

4. 基于 Resutl API 通讯

从Fragment 1.3.0-alpha04起，FragmentManager 新增了 FragmentResultOwner接口，顾名思义 FragmentManager 成为了 FragmentResult 的持有者，能够进行 Fragment 之间的通讯。

假设须要在 FragmentA 监听 FragmentB 返回的数据，首先在 FragmentA 设置监听

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // setFragmentResultListener 是 fragment-ktx 提供的扩展函数
    setFragmentResultListener("requestKey") { requestKey, bundle ->
        // 监听key为“requestKey”的结果， 并经过bundle获取
        val result = bundle.getString("bundleKey")
        // ...
    }
}

// setFragmentResultListener 是Fragment的扩展函数，内部调用 FragmentManger 的同名方法
public fun Fragment.setFragmentResultListener(
    requestKey: String,
    listener: ((requestKey: String, bundle: Bundle) -> Unit)
) {
    parentFragmentManager.setFragmentResultListener(requestKey, this, listener)
}

复制代码

当从 FragmentB 返回结果时：

button.setOnClickListener {
    val result = "result"
    setFragmentResult("requestKey", bundleOf("bundleKey" to result))
}

//setFragmentResult 也是 Fragment 的扩展函数，其内部调用 FragmentManger 的同名方法
public fun Fragment.setFragmentResult(requestKey: String, result: Bundle) {
    parentFragmentManager.setFragmentResult(requestKey, result)
}
复制代码

上面的代码能够用下图表示：

Result API的原理很是简单，FragmentA 经过 Key 向 FragmentManager 注册 ResultListener，FragmentB 返回 result 时， FM 经过 Key 将结果回调给FragmentA 。须要特别注意的是只有当 FragmentB 返回时，result才会被真正回传，若是 setFragmentResult 屡次，则只会保留最后一次结果。

生命周期可感知

经过梳理源码能够知道Result API是LifecycleAware的

源码基于 androidx.fragment:fragment:1.3.0

setFragmentResultListener 实现：

//FragmentManager.java
private final Map<String, LifecycleAwareResultListener> mResultListeners =
            Collections.synchronizedMap(new HashMap<String, LifecycleAwareResultListener>());


public final void setFragmentResultListener(@NonNull final String requestKey, @NonNull final LifecycleOwner lifecycleOwner, @NonNull final FragmentResultListener listener) {
        final Lifecycle lifecycle = lifecycleOwner.getLifecycle();
        LifecycleEventObserver observer = new LifecycleEventObserver() {
                if (event == Lifecycle.Event.ON_START) {
                    // once we are started, check for any stored results
                    Bundle storedResult = mResults.get(requestKey);
                    if (storedResult != null) {
                        // if there is a result, fire the callback
                        listener.onFragmentResult(requestKey, storedResult);
                        // and clear the result
                        clearFragmentResult(requestKey);
                    }
                }

                if (event == Lifecycle.Event.ON_DESTROY) {
                    lifecycle.removeObserver(this);
                    mResultListeners.remove(requestKey);
                }
        };
        lifecycle.addObserver(observer);
        LifecycleAwareResultListener storedListener = mResultListeners.put(requestKey,
                new LifecycleAwareResultListener(lifecycle, listener, observer));
        if (storedListener != null) {
            storedListener.removeObserver();
        }
    }
            
复制代码

  • listener.onFragmentResult 在 Lifecycle.Event.ON_START 的时候才调用，也就是说只有当 FragmentA 返回到前台时，才会收到结果，这与 LiveData 的逻辑的行为一致，都是 LifecycleAware 的

  • 当屡次调用 setFragmentResultListener 时， 会建立新的 LifecycleEventObserver 对象, 同时旧的 observer 会随着 storedListener.removeObserver() 从 lifecycle 中移除，不能再被回调。

也就是说，对于同一个 requestKey 来讲，只有最后一次设置的 listener 有效，这好像也是理所应当的，毕竟不叫 addFragmentResultListener 。

setFragmentResult 实现：

private final Map<String, Bundle> mResults =
            Collections.synchronizedMap(new HashMap<String, Bundle>());
            
 public final void setFragmentResult(@NonNull String requestKey, @NonNull Bundle result) {
        // Check if there is a listener waiting for a result with this key
        LifecycleAwareResultListener resultListener = mResultListeners.get(requestKey);
        // if there is and it is started, fire the callback
        if (resultListener != null && resultListener.isAtLeast(Lifecycle.State.STARTED)) {
            resultListener.onFragmentResult(requestKey, result);
        } else {
            // else, save the result for later
            mResults.put(requestKey, result);
        }
    }
复制代码

setFragmentResult 很是简单， 若是当前是 listener 处于前台，则当即回调 setFragmentResult(), 不然，存入 mResults, 等待 listener 切换到前台时再回调。

一个 listener 为何有前台/后台的概念呢，这就是以前看到的 LifecycleAwareResultListener 了， 生命周期可感知是由于其内部持有一个 Lifecycle， 而这个 Lifecycle 其实就是设置 listener 的那个 Fragment

private static class LifecycleAwareResultListener implements FragmentResultListener {
        private final Lifecycle mLifecycle;
        private final FragmentResultListener mListener;
        private final LifecycleEventObserver mObserver;

        LifecycleAwareResultListener(@NonNull Lifecycle lifecycle,
                @NonNull FragmentResultListener listener,
                @NonNull LifecycleEventObserver observer) {
            mLifecycle = lifecycle;
            mListener = listener;
            mObserver = observer;
        }

        public boolean isAtLeast(Lifecycle.State state) {
            return mLifecycle.getCurrentState().isAtLeast(state);
        }

        @Override
        public void onFragmentResult(@NonNull String requestKey, @NonNull Bundle result) {
            mListener.onFragmentResult(requestKey, result);
        }

        public void removeObserver() {
            mLifecycle.removeObserver(mObserver);
        }
    }
复制代码

可恢复重建

mResult 中的数据是会随着 Fragment 的重建能够恢复的，因此 FragmentA 永远不会丢失 FragmentB 返回的结果。固然，一旦 Result 被消费，就会从 mResult 中清除

mResults 的保存

//FragmentManager.java
void restoreSaveState(@Nullable Parcelable state) {
    //...
    ArrayList<String> savedResultKeys = fms.mResultKeys;
        if (savedResultKeys != null) {
            for (int i = 0; i < savedResultKeys.size(); i++) {
                mResults.put(savedResultKeys.get(i), fms.mResults.get(i));
            }
        }
}
复制代码

mResults 的恢复

Parcelable saveAllState() {
    // FragmentManagerState implements Parcelable
    FragmentManagerState fms = new FragmentManagerState();
    //...
    fms.mResultKeys.addAll(mResults.keySet());
    fms.mResults.addAll(mResults.values());
    //...
    return fms;
}
复制代码

如何选择？Result API 与 ViewModel

ResultAPI 与 ViewModel + LiveData 有必定类似性，都是生命周期可感知的，均可以在恢复重建时保存数据，那这两种通讯方式该如何选择呢？

对此，官方给的建议以下：

The Fragment library provides two options for communication: a shared ViewModel and the Fragment Result API. The recommended option depends on the use case. To share persistent data with any custom APIs, you should use a ViewModel. For a one-time result with data that can be placed in a Bundle, you should use the Fragment Result API.

  • ResultAPI 主要适用于那些一次性的通讯场景（FragmentB返回结果后结束本身）。若是使用 ViewModel，须要上提到的 Fragment 共同的父级 Scope，而 Scope 的放大不利于数据的管理。

  • 非一次性的通讯场景，因为 FragmentA 和 FragmentB 在通讯过程当中共存，推荐经过共享 ViewModel 的方式，再借助 LiveData 等进行响应式通讯。

5. 跨Activity的通讯

最后看一下，跨越不一样 Activity 的 Fragmnet 间的通讯

跨 Activity 的通讯主要有两种方式：

  • startActivityResult
  • Activity Result API

startActivityResult

Result API出现以前，须要经过 startActivityResult 完成通讯，这也是 android.app.Fragment 惟一可选的方式。

通讯过程以下：

  1. FragmentA 调用 startActivityForResult() 方法以后，跳转到 ActivityB 中，ActivityB 把数据经过 setArguments() 设置给 FragmentB

  2. FragmentB 调用 getActivity().setResult() 设置返回数据，FragmentA 在 onActivityResult() 中拿到数据

此时，有两点须要特别注意:

  1. 不要使用 getActivity().startActivityForResult() , 而是在Fragment中直接调用startActivityForResult()

  2. activity 须要重写 onActivityResult，其必须调用 super.onActivityResult(requestCode, resultCode, data)

以上两点若是违反，则 onActivityResult 只可以传递到 activity 的，没法传递到 Fragment

Result API

自1.3.0-alpha02起，Fragment 支持 registerForActivityResult() 的使用，经过 Activity 的 ResultAPI 实现跨 Activity 通讯。

FragmentA 设置回调：

class FragmentA : Fragment() {
    private val startActivityLauncher: ActivityResultLauncher<Intent> =
        registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
            if (it.resultCode == Activity.RESULT_OK) {
                //
            } else if (it.resultCode == Activity.RESULT_CANCELED) {
                //
            }
        }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        startActivityLauncher.launch(Intent(requireContext(), ActivityB::class.java))
    }
}
复制代码

FragmentB 返回结果

button.setOnClickListener {
    val result = "result"
    // Use the Kotlin extension in the fragment-ktx artifact
    setFragmentResult("requestKey", bundleOf("bundleKey" to result))
}
复制代码

了解 Activity Result API 的同窗对上述过程应该很熟悉。

简单看一下源码。

源码基于 androidx.fragment:fragment:1.3.0

咱们在 FragmentA 中经过建立一个 ActivityResultLauncher，而后调用 launch 启动目标 ActivityB

//Fragment # prepareCallInternal

return new ActivityResultLauncher<I>() {
            @Override
            public void launch(I input, @Nullable ActivityOptionsCompat options) {
                ActivityResultLauncher<I> delegate = ref.get();
                if (delegate == null) {
                    throw new IllegalStateException("Operation cannot be started before fragment "
                            + "is in created state");
                }
                delegate.launch(input, options);
            }

            //...
        };
        
复制代码

能够看到，内部调用了delegate.launch, 咱们追溯一下 delegate 的出处，即 ref 中设置的 value

//Fragment # prepareCallInternal

registerOnPreAttachListener(new OnPreAttachedListener() {
            @Override
            void onPreAttached() {
                //ref中注册了一个launcher，来自 registryProvider 提供的 ActivityResultRegistry
                final String key = generateActivityResultKey();
                ActivityResultRegistry registry = registryProvider.apply(null);
                ref.set(registry.register(key, Fragment.this, contract, callback));
            }
        });

    public final <I, O> ActivityResultLauncher<I> registerForActivityResult( @NonNull final ActivityResultContract<I, O> contract, @NonNull final ActivityResultCallback<O> callback) {
        return prepareCallInternal(contract, new Function<Void, ActivityResultRegistry>() {
            @Override
            public ActivityResultRegistry apply(Void input) {
                //registryProvider 提供的 ActivityResultRegistry 来自 Activity
                if (mHost instanceof ActivityResultRegistryOwner) {
                    return ((ActivityResultRegistryOwner) mHost).getActivityResultRegistry();
                }
                return requireActivity().getActivityResultRegistry();
            }
        }, callback);
    }
复制代码

上面能够看到 ref 中设置的 ActivityResultLauncher 来自 Activity 的 ActivityResultRegistry ，也就说 Fragment 的 launch，最终是由其 mHost 的 Activity 代理的。

后续也就是 Activity 的 Result API 的流程了，咱们知道 Activity Result API 本质上是基于 startActivityForResult 实现的，具体能够参考这篇文章，本文再也不赘述了

总结

本文总结了 Fragment 通讯的几种常见方式，着重分析了 Result API 实现原理。 fragment-1.3.0之后，对于一次性通讯推荐使用 Result API 替代旧有的 startActivityForResult；响应式通讯场景则推荐使用 ViewModel + LiveData (or StateFlow） ， 尽可能避免使用 EventBus 这类工具进行通讯。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程