一种新的在 fragment 中处理按键返回的方法

前言

当我们在fragment中处理返回键事件的时候，很多时候做法都是这样的：Activity中重写onBackPressed()，在此方法中获取当前的fragment对象，判断是否要处理返回事件，如果需要处理，就交由fragment再去具体响应返回事件，大致代码如下：

interface BackPressedListener {
    fun onBackPressed(): Boolean
}

class ExampleFragment : Fragment(), BackPressedListener {
    override fun onBackPressed(): Boolean {
        return if (handleBackPress) {
            // 具体处理事件
            true
        } else {
            false
        }
    }
}

class ExampleActivity : AppCompatActivity() {
    override fun onBackPressed() {
        val currentFragment = getCurrentFragment()

        if (!currentFragment.onBackPressed()) {
            super.onBackPressed()
        }
    }
}

这种写法确实能够解决问题，并且可能是我们目前正在使用的，唯一不足就是稍显繁琐，需要开发者自行实现接口，拦截事件，写一些样板代码。

新方案

也许是谷歌终于意识到上面的方案并没有十分优雅，终于在 androidx.activity: 1.1.0 中引入了OnBackPressedDispatcher类，以供开发者在fragment中相对简单的处理返回按键事件。具体使用方式：

class ExampleFragment : Fragment() {

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        requireActivity().onBackPressedDispatcher.addCallback(
            //这个LifecycleOwner可以不用也行
            //viewLifecycleOwner,
            object : OnBackPressedCallback(true) {
                override fun handleOnBackPressed() {
                    if (handleBackPress) {
                        // 具体执行返回事件
                    } else {
                        isEnabled = false
                        requireActivity().onBackPressed()
                    }
                }
            })
    }
}

上面的代码是不是看起来要简单一些了，至少目前看起来是的。这段代码主要利用Activity来获取一个OnBackPressedDispatcher对象，然后再往里面添加一个callback，负责去处理具体的返回事件逻辑。这样，我们只用在fragment中添加了代码了，而越少的代码就意味着更少的错误的可能😂。

问题

1. 为什么要在添加的callback中传入true，有什么具体作用吗？

首先先来看一下此方案的实现思路：首先在ComponentActivity中重写了onBackPressed()，并将逻辑委托给了OnBackPressedDispatcher，用于具体响应和分发事件。在OnBackPressedDispatcher中使用了一个双端队列mOnBackPressedCallbacks存储各个callback，当我们点击返回键时，就会开始遍历这个队列，找到处于激活状态（mEnable 为 true）的那个callback，将事件交由它处理，实际上思路和第一种方式是类似的，只不过官方帮我们将整个过程简化了。

 @MainThread
    public void onBackPressed() {
        Iterator<OnBackPressedCallback> iterator =
                mOnBackPressedCallbacks.descendingIterator();
        while (iterator.hasNext()) {
            OnBackPressedCallback callback = iterator.next();
            if (callback.isEnabled()) {
                callback.handleOnBackPressed();
                return;
            }
        }
        if (mFallbackOnBackPressed != null) {
            mFallbackOnBackPressed.run();
        }
    }

所以callback中传入的true参数就很好理解了，用于控制当前callback是否处于激活状态，aka 是否响应返回事件。

2. 既然调用了addCallback函数添加了callback，是否还需要开发者去调用remove呢？

可以从上面的代码中看到，在添加callback的时候同时也是传入了lifecycleOwner对象的，也就意味为这一套BackPressedDispatcher机制是对生命周期敏感的，会自行根据当前生命周期进行处理。查看源码，也印证了这一结论。

 private class LifecycleOnBackPressedCancellable implements LifecycleEventObserver,
            Cancellable {
              // ...省略代码

        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            if (event == Lifecycle.Event.ON_START) {
                mCurrentCancellable = addCancellableCallback(mOnBackPressedCallback);
            } else if (event == Lifecycle.Event.ON_STOP) {
                // Should always be non-null
                if (mCurrentCancellable != null) {
                    mCurrentCancellable.cancel();
                }
            } else if (event == Lifecycle.Event.ON_DESTROY) {
                cancel();
            }
        }
              // ... 省略代码
    }

3. 上面的代码中为什么需要手动将isEnable置为 false，并调用Activity的onBackPressed函数？

从ComponentActivity中的onBackPressed函数中可以看到，实际上在循环中找到isEnable为 true 的callback并将其处理返回之后，这一次返回点击就已经结束了，如果我们此时并不需要拦截返回事件，则需要重置isEnable状态，重新去寻找下一个处理事件的callback或者直接让Activity去处理。

结论

OnBackPressedDispatcher的出现，可以让开发者相对优雅的在fragment去处理按键返回事件，更加关注于自身业务逻辑的编写，减少样本代码，并且早已被加入了正式版本，可以在考虑在实际开发中大胆使用。