開場

以下場景為杜撰：

產(chǎn)品經(jīng)理：“小羅，這個信息發(fā)送界面，如果用戶輸入了內(nèi)容，點擊返回鍵的時候，要先詢問用戶是否保存草稿箱哈”。

小羅：“收到，這問題簡單?！?/p>

說完小羅就準(zhǔn)備著手處理，然后卻發(fā)現(xiàn)信息編輯界面是一個Fragment，然而Fragment并沒有提供返回鍵點擊的直接處理；小羅雖菜，但是摸魚也摸了些年頭了，這問題難不倒小羅。

小羅心想，反正Activity提供了onBackPressed方法，再不濟(jì)的情況把這個操作分發(fā)到Fragment中去就好，可是對于處女座的小羅來說，在解決問題的基礎(chǔ)上，起碼代碼要寫的漂亮一點，寫的漂亮一點心里就舒服一點，心里舒服一點就...（此處內(nèi)容很長）。

小羅堅信“條條大路通羅馬”，我們不僅要到羅馬，還要風(fēng)風(fēng)光光的去，所以對于“Fragment如何監(jiān)聽返回鍵的點擊”，小羅決定下點功夫；

為什么關(guān)注的點是Fragment去監(jiān)聽返回鍵，而不是其他？其實在現(xiàn)在的開發(fā)過程中，F(xiàn)ragment的使用比重是非常大的，對于個人而言，幾乎整個工程的界面實現(xiàn)都是基于Fragment而非Activity。

一、最lowB的方式（不推薦）

這就是小羅心里的預(yù)備方案，在實在沒有辦法的時候會采用此方法，也就是前面提到的，我們可以在Activity執(zhí)行onBackPressed時，分發(fā)到Fragment中去；那我們用什么來分發(fā)呢？這個分發(fā)就好比是連接Activity和Fragment之間的一個紐帶，雙方均能夠訪問到這個對象就可以了，所以一個可以的選擇之一是使用ViewModel，當(dāng)然還可以有其他選擇，在此就不細(xì)聊了。

二、使用OnKeyListener（不推薦）

這種方式可能不常用，不容易想到這方面，所以這種方式也不推薦，簡單做個了解；

通過設(shè)置View的OnKeyListener來監(jiān)聽返回鍵的處理，此方法也沒什么大的弊端，只是要注意以下兩點：

1、如果把這個功能封裝在Fragment基類中的話，可能存在被覆蓋的問題；比如在基類中設(shè)置了OnKeyListener，而子類也需要設(shè)置OnKeyListener，此時設(shè)置的監(jiān)聽則會替換默認(rèn)設(shè)置的監(jiān)聽，從而導(dǎo)致意想不到的可能，不過此問題幾乎不太可能發(fā)生。

2、需要注意這種方式將會改變返回鍵處理的順序，也就是會先處理OnKeyListener的回調(diào)，再處理Activity的onBackPressed，所以要注意這個關(guān)系。

三、Jetpack提供的方式

其實對于返回鍵的分發(fā)，官方已經(jīng)做了支持，在Activity中提供了一個用于分發(fā)返回鍵事件的對象，通過調(diào)用Activity的getOnBackPressedDispatcher()方法得到這個對象，由于這個對象是在比較底層的androidx.activity.ComponentActivity中提供的（AppCompatActivity->FragmentAcitivty->androidx.activity.ComponentActivity）,所以在Fragment中可以直接拿到這個對象添加回調(diào);

官方資料入口

//官方使用示例 
public class FormEntryFragment extends Fragment {
 @Override
 public void onAttach(@NonNull Context context) {
  super.onAttach(context);
  //定義回調(diào)
  OnBackPressedCallback callback = new OnBackPressedCallback(
   true // default to enabled
  ) {
   @Override
   public void handleOnBackPressed() {
    showAreYouSureDialog();
   }
  };
  
  //獲取Activity的返回鍵分發(fā)器添加回調(diào)
  requireActivity().getOnBackPressedDispatcher().addCallback(
   this, // LifecycleOwner
   callback);
 }
}

簡單明了，這個事情好像到此為止了～～

但隨著深入了解，事情似乎沒有這么簡單，經(jīng)過源碼分析和資料收集，發(fā)現(xiàn)如果直接使用會存在以下弊端：

1、Fragment回調(diào)處理時，無法向上傳遞

2、回調(diào)是否可用需要主動標(biāo)記，而非運(yùn)行時確定

簡單說一下OnBackPressedDispatcher分發(fā)返回鍵的流程：

	//官方源碼
 @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();
  }
 }

當(dāng)分發(fā)返回鍵事件時，會倒序循環(huán)遍歷已經(jīng)注冊的回調(diào)，如果回調(diào)isEnabled設(shè)置為true，則執(zhí)行回調(diào)的方法，分發(fā)結(jié)束；

那前面提到的弊端是怎么產(chǎn)生的呢？假如一個Activity有兩個Fragment A和B，均注冊了返回鍵點擊事件（有童鞋會說了，這種場景不太可能存在，確實，這種場景是不多，但不代表沒有，做一些了解也不是壞事），并且兩個回調(diào)的isEnabled均設(shè)置為true，那么當(dāng)分發(fā)事件時，會將事件分發(fā)給B，但是B此時并不需要處理返回鍵事件，但是B又沒有辦法再繼續(xù)將事件傳遞給A了；

“你傻啊，你B不執(zhí)行返回鍵事件，就設(shè)置isEnable為false啊”

“是啊，B不執(zhí)行事件是該設(shè)置為false，可是我怎么知道什么時候去把它設(shè)置成false？難道動態(tài)綁定判斷條件的值進(jìn)行設(shè)置么？”

轉(zhuǎn)頭一想“咦，好像確實可以動態(tài)修改回調(diào)的isEnabled值呢，將回調(diào)的值跟一個LiveData綁定不就可以了么！”
理是這個理，但是我不愿意做額外的工作，我不愿這么干，誰知道動態(tài)判斷條件到底有多復(fù)雜呢，難道我不可以在返回鍵點擊的時候去判斷么？

四、靈機(jī)一動，官方升級版（推薦方式）

官方的方式不是存在上面兩個弊端么，解決這兩個問題不就好了；所以結(jié)合官方OnBackPressedDispatcher和OnKeyListener兩者的優(yōu)點，創(chuàng)建了andme.arch.activity.AMBackPressedDispatcher，在保留官方原有的功能的同時，更改事件分發(fā)流程，并將返回鍵持有者一并傳入，用于解決一些更復(fù)雜一點的需求；

 @MainThread
 fun onBackPressed(): Boolean {
  if (!hasRegisteredCallbacks())
   return false

  val iterator = mOnBackPressedCallbacks.descendingIterator()
  while (iterator.hasNext()) {
   val callback = iterator.next()
   //判斷回調(diào)是否需要消耗事件在決定是否繼續(xù)傳遞
   if (callback.handleOnBackPressed(owner)) {
    return true
   }
  }
  return false
 }

五、官方使用技巧版

這種方法其實是我在發(fā)布文章之后，群友提供的一種思路，說實話，非常有技巧，剛開始看到的時候眼前一亮；其核心原理是默認(rèn)注冊的回調(diào)是可用的，在回調(diào)執(zhí)行中，先判斷自己是否需要執(zhí)行回調(diào)，如果不需要執(zhí)行回調(diào)，則將自己的isEnabled設(shè)置為false，然后再調(diào)用OnBackPressedDispatcher重新分發(fā)返回鍵事件（由于此時已將自己設(shè)置為false，此時便不會響應(yīng)回調(diào)），調(diào)用方法之后再將isEnabled設(shè)置為true，巧用了遞歸，該方式不錯的；

最開始群友提供的代碼有一丟丟瑕疵，以下為修正之后的代碼，在Fragment中定義這兩個方法，在需要綁定返回鍵監(jiān)聽的時候調(diào)用這個兩個方法之一即可（推薦調(diào)用與生命周期相關(guān)的方法）；

fun addOnBackPressed(onBackPressed: () -> Boolean): OnBackPressedCallback {
  val callback = object : OnBackPressedCallback(true) {
   override fun handleOnBackPressed() {
    if (!onBackPressed()) {
     isEnabled = false
     requireActivity().onBackPressedDispatcher.onBackPressed()
     isEnabled = true
    }
   }
  }
  requireActivity().onBackPressedDispatcher.addCallback(callback)
  return callback
 }

 fun addOnBackPressed(owner: LifecycleOwner, onBackPressed: () -> Boolean): OnBackPressedCallback {
  val callback = object : OnBackPressedCallback(true) {
   override fun handleOnBackPressed() {
    if (!onBackPressed()) {
     isEnabled = false
     requireActivity().onBackPressedDispatcher.onBackPressed()
     isEnabled = true
    }
   }
  }
  requireActivity().onBackPressedDispatcher.addCallback(owner,callback)
  return callback
 }

但是經(jīng)過慎重思考，最終我還是沒有用這種方法，雖然這種方法在幾乎百分之八九十的情況下是沒有問題的，但是我認(rèn)為可能還是有場景無法滿足；

舉個例子，一個Activity添加了一個Fragment，這個Fragment又順序添加了A和B兩個ChildFragment，那在B執(zhí)行返回處理的時候，是想回到A還是finish呢？或者是其他呢，也是就是說我們無法確定，在Fragment執(zhí)行返回鍵處理時，是否需要直接調(diào)用Activity.super.onBackPressed方法的可能。

我們永遠(yuǎn)無法預(yù)估用戶的場景到底有多復(fù)雜，需求有多變態(tài)，所以盡可能的考慮把。

總結(jié)

綜上所述，我目前還是會繼續(xù)使用第四種我寫的方案，第五種方案也推薦，畢竟在絕大部分場景中都是沒有問題的
那么我們考慮第四種方案到底是否可行？

1、功能性

滿足了功能需求，并且至少目前是沒有想到有任何可能出現(xiàn)問題的場景

2、侵入性

幾乎對用戶場景沒什么影響吧，只是對用戶提供了一個可見的處理返回鍵事件的方法而已

3、替換性

如果采用第四種方案，要更換成第五種方案，容易么？一兩句代碼的事情而已

或者更換成其他方案容易么？也是一兩句代碼的的事情而已

并且即便替換成其他方案，也不會對現(xiàn)有系統(tǒng)造成任何影響，因為對于Fragment監(jiān)聽返回鍵這個需求來講，這個需求的核心就是需要一個在Fragment中處理返回鍵事件的方法而已，其他東西對用戶來講都是無感的
所以總體覺得沒什么毛病；

如果你有更好的思路，歡迎溝通，不勝感激；

另外，上述功能其實并不僅僅支持在Fragment中處理返回鍵事件，理論上來說任何想要監(jiān)聽返回鍵處理的都可以通過Activity獲取AMBackPressedDispatcher對象添加回調(diào)即可。

Andme Github地址

到此這篇關(guān)于Android Fragment監(jiān)聽返回鍵的一種合理方式的文章就介紹到這了,更多相關(guān)Android Fragment監(jiān)聽返回鍵內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論