亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

Android中Fragment管理及重疊問題的解決方法

 更新時間:2016年11月24日 09:54:51   投稿:daisy  
最近做項目碰到了Fragment重疊的問題,后來通過種種方法得以解決了,所以想著總結(jié)下這個問題的解決方法,以及Android中Fragment的管理,方便自己也給有需要的朋友們提供以幫助,感興趣的朋友們下面通過這篇文章一起來學習學習吧。

一、Fragment介紹

fragment在3.0被引入以后,項目使用fragment越來越多,特別是主界面是底部tab頁點擊切換更換內(nèi)容,當然啦, Fragment 在項目中存在著廣泛的時候,例如通常在首頁的設(shè)計中,通常底部的每一個 navigation 都對應(yīng)這一個對應(yīng)的 Fragment ,使用 Fragment 減輕了對應(yīng) Activity 的職責,讓 Fragmen t充當了部分的Activity的職責。而且使用 Fragment 的時候,提高了代碼和布局的封裝和復(fù)用,這個優(yōu)勢也是特別的明顯。

Fragment 擁有自己的生命周期管理,但是它是依賴對應(yīng)的Activity的。

嗯,生命周期的介紹不是本篇的重點,貼個圖加深一下印象。

二、Fragment的棧管理及其生命周期

addToShow

FragmentTransaction transaction = manager.beginTransaction();
 String tag = to.getClass().getSimpleName();
 transaction.add(from.getContainerId(), to, tag)
   .addToBackStack(tag)
   .hide(from)
   .show(to)
   .commit();

如果使用 add() hide() 來控制跳轉(zhuǎn)的話,對應(yīng)的生命周期是這樣的:

E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume: Fragment09
 E/____TAG____: onClick: 2131558527
 E/TAG: onAttach: Fragment10
 E/TAG: onCreate: Fragment10
 E/TAG: onHiddenChanged: Fragment09不可見了!
 E/TAG: onCreateView: Fragment10
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment10

如果此時從第二個 Fragment 再次返回到第一個 Fragment :

E/TAG: onHiddenChanged: Fragment10不可見了!
 E/TAG: onHiddenChanged: Fragment09可見了?。?
 E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment10
 E/TAG: onDestroyView: Fragment10
 E/TAG: onDestroy: Fragment10
 E/TAG: onDetach: Fragment10

可以對應(yīng)上面的圖片,當返回的時候是直接銷毀的當前的 Fragment 的,然后第一個 Fragment 只是從不可見的狀態(tài)變?yōu)榱丝梢姷臓顟B(tài),并沒有走相關(guān)的生命周期,所以 hide() 的方法不會觸發(fā) onPause() 等生命周期回調(diào)方法。

那么如果我們鎖屏了或者切換任務(wù)之后再切換回來的話:

E/TAG: onPause: Fragment09
 E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment09
 E/TAG: onStop: Fragment10
 E/TAG: onStart: Fragment09
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment09
 E/TAG: onResume:不可見的 Fragment09
 E/TAG: onResume: Fragment10
 E/TAG: onResume:可見的 Fragment10

這里可以看到,所有的 Fragment 都回去隨著 Activity 去回調(diào)相關(guān)方法,不管它是否可見。

replaceTo

FragmentTransaction transaction = manager.beginTransaction();
 String tag = to.getClass().getSimpleName();
 transaction.replace(from.getContainerId(), to, tag)
   .addToBackStack(tag)
   .commit();

replace() 的方法其實就是相當于 remove() 移除之前添加到這個容器中的所有 Fragment 然后再 add() 添加當前的。那么既然會調(diào)用 remove() 方法,所以生命周期就是這樣的啦:

E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume: Fragment09
 E/TAG: onResume:可見的 Fragment09
 E/____TAG____: onClick: 2131558527
 E/TAG: onAttach: Fragment10
 E/TAG: onCreate: Fragment10
 E/TAG: onPause: Fragment09
 E/TAG: onStop: Fragment09
 E/TAG: onDestroyView: Fragment09
 E/TAG: onCreateView: Fragment10
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment10
 E/TAG: onResume:可見的 Fragment10

對比上面的log來看的話,當 remove() 調(diào)用之后, Fragment 會執(zhí)行 onPause() , onStop()onDestroyView() 會一次被調(diào)用,但是 onDestroy() , onDetach() 是不會被調(diào)用的,這就是說它的視圖會被摧毀了,那么重新回來的時候,就得重新創(chuàng)建:

E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment10
 E/TAG: onDestroyView: Fragment10
 E/TAG: onDestroy: Fragment10
 E/TAG: onDetach: Fragment10
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume:可見的 Fragment09

同樣的,鎖屏了或者切換任務(wù)之后再切換回來的話:

E/TAG: onStart: Fragment10
 E/TAG: onResume:可見的 Fragment10
 E/TAG: onPause: Fragment10
 E/MainActivity: onSaveInstanceState: 保存當前TAG
 E/TAG: onStop: Fragment10
 E/TAG: onStart: Fragment10
 E/TAG: onResume:可見的 Fragment10

可以看到,當使用了 replace() 之后,這些情況之下只會有top的 Fragment 來響應(yīng)對應(yīng)的生命周期。在上面的 add() 中,兩個 Fragment 都走了相關(guān)的生命周期的。

那么問題來了:什么時候使用 replace() 什么時候使用 add() hide() 的呢?!其實對比來看,主要就是效率的問題和相關(guān)生命周期問題。

效率問題:

如果使用 replace() 就意味著每次的需要走 onCreateView() 再次去重新填充布局。如果在 onCreateView() 方法中還包含了初始化數(shù)據(jù)的話,也意味著相關(guān)的也要重新執(zhí)行一次。

數(shù)據(jù)、頁面刷新問題:

如果你使用 replace() 從 AFragment 跳轉(zhuǎn)到 BFragment , BFragment 中更新了相關(guān)數(shù)據(jù)會影響到 AFragment 的相關(guān) View 展示的話,這里也會有問題,就算你使用 EventBus 什么的通知了, AFragment 的確可以改變,但是當你切回到 AFragment ,它會走 onCreateView() 重新創(chuàng)建相關(guān)布局,除非你保存到了全局,初始化的時候再次設(shè)置,那么之前發(fā)送的數(shù)據(jù)就會丟失了。

生命周期匹配問題:

生命周期的方法都是匹配成對出現(xiàn)的,上面說到的 replace() 方法中,A替換的時候走了以下三個生命周期回調(diào)方法:

E/TAG: onPause: Fragment09
 E/TAG: onStop: Fragment09
 E/TAG: onDestroyView: Fragment09

當回退到它的時候,對應(yīng)的三個生命周期回調(diào)就被調(diào)用了:

E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume:可見的 Fragment09

但是使用 add() hide() 的時候就會比較尷尬,你會發(fā)現(xiàn)它的 onPause()onResume() 方法完全不匹配了。只要 add() 了,即使你調(diào)用 hide() ,不會影響它的生命周期回調(diào),也不會有 onPause() 等回調(diào)。這也就出現(xiàn)了當我們鎖屏或者切換任務(wù)回來的話,所有add進來的 Fragment 都會執(zhí)行一遍相關(guān)生命周期回調(diào)方法:

E/TAG: onPause: Fragment09
 E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment09
 E/TAG: onStop: Fragment10
 E/TAG: onStart: Fragment09
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment09
 E/TAG: onResume:不可見的 Fragment09
 E/TAG: onResume: Fragment10
 E/TAG: onResume:可見的 Fragment10

所以,如果你做統(tǒng)計相關(guān)的,這里可能就有點兒小問題了。當然,它顯示與否并不是完全不可知的。

在 Fragment 中可以通過 isHide() 的方法,或者 onHiddenChanged(boolean hiden) 的方法來獲取當前是否是 hide 狀態(tài)。

所以總結(jié)起來就是使用 add()hide() 的方式,需要注意 onResume() 等回調(diào)方法的不匹配情況和獲取數(shù)據(jù)的時機,應(yīng)該在可見的時候( isHidden() 返回 false 的時候)才去請求相關(guān)數(shù)據(jù)。

使用 replace() 的話就是要注意頻繁的布局填充還有就是 Fragment 與 Fragment 之間的數(shù)據(jù)傳遞情況。

狀態(tài)保存

Fragment重疊異常情況

肯定碰到過Fragment重疊顯示的問題吧???

 

 

這個主要就是 Activity 幫我們在作相關(guān)的恢復(fù)狀態(tài)的時候出現(xiàn)的問題。在設(shè)置中將不保留后臺進程打開,方便產(chǎn)生對應(yīng)的情況:

然后在第二個頁面時回到首頁,再次進入,我們先來看看一個異常的情況的log:

E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onAttach: Fragment10
 E/TAG: onCreate: Fragment10
 E/TAG: onCreateView: Fragment09
 E/TAG: onCreateView: Fragment10
 E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onStart: Fragment10
 E/TAG: onStart: Fragment09
 E/TAG: onResume:不可見的 Fragment09
 E/TAG: onResume:可見的 Fragment10
 E/TAG: onResume:可見的 Fragment09

尼瑪,發(fā)現(xiàn)問題沒?我們的 Fragment9 居然創(chuàng)建了兩次。一個和之前是一樣的,不可見的,另外一個居然是可見的,而且還在最上面。所以這個就造成了 Fragment 重疊的情況。

還有一種情況就是斷點發(fā)現(xiàn)某個 Fragment 初始化成功了,布局也有了,但是里面的View全是空的,這個情況我也遇到過。

為什么會出現(xiàn)這個問題?因為在這種異常情況下,會觸發(fā) Android 的臨時數(shù)據(jù)保存機制, Fragment 是它臨時保存的重點對象。所以之前的兩個 Fragment 相關(guān)狀態(tài)都被保存下來了!但在 Activity 的 onCreate() 中我是這樣寫的話:

fragmentsUtil.loadRoot(R.id.fragment_container, Fragment9.newInstance());

那么就是說不管是否有保存的狀態(tài)我都去再次創(chuàng)建加載一次 Fragment9 了,所以這個就導致了 Fragment9 創(chuàng)建了兩次(一次是系統(tǒng)恢復(fù)出來的,相關(guān)狀態(tài)也是正常的,一次就是我們在 onCreate() 中創(chuàng)建出來的)。那么要避免這個問題就要在 savedInstanceState 這個東西上想想辦法了。既然它已經(jīng)保存了相關(guān)的 Fragment 了,我們就不用去再次創(chuàng)建咯!

@Override
protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.activity_main);
 ButterKnife.bind(this);
 manager = getSupportFragmentManager();
 if (savedInstanceState == null) {
  Log.e(TAG, "onSaveInstanceState: 恢復(fù)相關(guān)狀態(tài)??!");
  fragmentsUtil.loadRoot(R.id.fragment_container, Fragment9.newInstance());
 }
}

所以說呢, savedInstanceState 還是不能忽略的。不過到這里就以為完了的話就太低估 Fragment 的坑了, 如果你的 support-library 是低于24的,那么即使判斷了 savedInstanceState 再去創(chuàng)建但是也有可能出現(xiàn)重疊的情況!

這里要說說 FragmentState 這個類,它是用來保存 Fragment 的相關(guān)狀態(tài)的。

發(fā)現(xiàn)情況沒??在之前的 FragmentState 中并沒有保存 mHidden 的狀態(tài)!

另外也搜索到了 相關(guān)Issue提交 ,但是在 Android 的 Revision-History 中并沒有看到提及的相關(guān)bug修復(fù)。所以具體什么時候正式加了 mHidden 的字段也就沒有考證出來了。

聊了這么多,最后說說解決方案唄,其實原理很簡單,既然它沒有自動保存,那么我們就在保存狀態(tài)的時候手動把 mHidden 狀態(tài)保存,在初始化的時候根據(jù)保存的 mHidden 狀態(tài)手動顯示或者隱藏。

@Override
public void onSaveInstanceState(Bundle outState) {
 //手動保存
 outState.putBoolean(ARG_IS_HIDDEN, isHidden());
 super.onSaveInstanceState(outState);
}
 //onCreate的時候調(diào)用
public void initFragments(Bundle savedInstanceState, BaseFragment fragment) {
 if (savedInstanceState == null) {
  return;
 }
 boolean isSupportHidden = savedInstanceState.getBoolean(ARG_IS_HIDDEN);

 FragmentTransaction ft = manager.beginTransaction();
 if (isSupportHidden) {
  ft.hide(fragment);
 } else {
  ft.show(fragment);
 }
 ft.commit();
}

最后封裝了一個簡單的工具類和 BaseFragment , 用于處理 Fragment 相關(guān)的事務(wù)的。

總結(jié)

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對各位Android開發(fā)者們能有所幫助,如果有疑問大家可以留言交流。

相關(guān)文章

最新評論