android fragment

Fragment／Activity生命周期图

图片来源： https://github.com/xxv/android-lifecycle

Fragment状态变化常用方法

1. onHiddenChanged(boolean hidden)

Activity内部通过show和hide方法切换Fragment时，引发的状态变迁。

2. setUserVisibleHint(boolean isVisibleToUser)

ViewPager和Fragment一起使用时，ViewPager就是利用这个方法控制Fragment的显示与隐藏的，所以通过这个方法可以实现ViewPager中Fragment的懒加载模式。

3. isVisible()

如果该Fragment对象对用户可见，那么就返回true。这就意味着：1.已经被添加到Activity中；2.它的View对象已经被绑定到窗口中；3.没有被隐藏。

isVisible()方法需要注意和getUserVisibleHint()方法的区别。

isVisible() 方法可用于fragment的 onResume() 生命周期方法中，用于判断当app从其他界面进入（初次创建或者返回）fragment所attach的activity时，当前Fragment是否可见。配合使用 onHiddenChanged方法，常用于Fragment界面的刷新。

特别说明：存在这样一种情况，当从其他 Activity 通过setResult方法返回到 包含多个Fragment的Activity，并且在目标Activity的onActivityResult方法中指定显示处于隐藏状态的一个Fragment时，如果仅仅依据isVisible方法是无法区分所要显示的Fragment的onHiddenChanged和onResume方法，因为onActivityResult方法要优先于onResume方法，所以此时需要用到 isResumed() 方法来限制界面刷新的调用：

1. @Override
2. public void onResume() {
3. super.onResume();
4. if (isVisible()){
5. //界面刷新操作，如网络请求
6. }
7. }
9. @Override
10. public void onHiddenChanged(boolean hidden) {
11. super.onHiddenChanged(hidden);
12. if (isVisible() && isResumed()){
13. //界面刷新操作，如网络请求
14. }
15. }

4. setArguments(Bundle args)

Fragment使用常见问题

1. Fragment切换导致UI重叠问题

问题演示：

   

问题模拟重现：

1.首先打开，默认选中的是第一个tab，如上面的一张图片正常那样。
2.切换到tab2，并把tab1 hide掉；
3.再切回到tab1，并不会触发tab1对应fragment的任何生命周期；
4.然后home键进入后台，我在activity的onPause()中手动对IndexFragment赋空，模拟长时间后台，系统销毁了该引用：IndexFragment=null；
5.再次启动，其实tab1 的fragment实例在内存中还在，只是他的引用被销毁了。
6.再切到tab2，这里其实是先把tab1的hide，在show tab2，但是tab1 的fragment引用为空，所以无法hide，就出现了tab2叠在tab1上的花屏情况。
7.再切到tab1，tab1就会重复创建对象。

问题分析：

fragment的切换有两种方式：

1. replace方式

transaction.replace(R.id.content, IndexFragment);

使用replace方式不会出现上述问题，但是会重复创建对象，每次replace会把生命周期全部执行一遍，如果在这些生命周期函数 里拉取数据的话，就会不断重复的加载刷新数据。

2. add - hide - show方式

transaction.add(R.id.content, IndexFragment); transaction.hide(otherfragment); transaction.show(thisfragment);

1. public class TestFragmentTab extends FragmentActivity {
3. private static final String TAG = "TestFragmentTab";
5. private int tabIds[] = new int[]{
6. R.id.home_tab_main,
7. R.id.home_tab_search,
8. R.id.home_tab_category,
9. };
11. private FragmentTab1 mTab1;
12. private FragmentTab2 mTab2;
13. private FragmentTab3 mTab3;
15. @Override
16. public void onAttachFragment(Fragment fragment) {
17. // TODO Auto-generated method stub
18. super.onAttachFragment(fragment);
19. Log.d(TAG, "onAttachFragment");
20. }
22. @Override
23. protected void onDestroy() {
24. // TODO Auto-generated method stub
25. super.onDestroy();
26. Log.d(TAG, "onDestroy");
27. }
29. @Override
30. protected void onPause() {
31. // TODO Auto-generated method stub
32. super.onPause();
33. Log.d(TAG, "onPause");
34. }
36. @Override
37. protected void onResume() {
38. // TODO Auto-generated method stub
39. super.onResume();
40. Log.d(TAG, "onResume");
41. }
43. @Override
44. protected void onStart() {
45. // TODO Auto-generated method stub
46. super.onStart();
47. Log.d(TAG, "onStart");
48. }
50. @Override
51. protected void onStop() {
52. // TODO Auto-generated method stub
53. super.onStop();
54. Log.d(TAG, "onStop");
55. }
57. @Override
58. protected void onCreate(Bundle savedInstanceState) {
59. // TODO Auto-generated method stub
60. super.onCreate(savedInstanceState);
61. Log.d(TAG, "onCreate");
62. setContentView(R.layout.layout_test_fragment_tab);
64. RadioGroup tabButtonGroup = (RadioGroup) findViewById(R.id.bottom_bar);
65. tabButtonGroup.setOnCheckedChangeListener( new OnCheckedChangeListener() {
67. @Override
68. public void onCheckedChanged(RadioGroup group, int checkedId) {
69. // TODO Auto-generated method stub
70. for ( int i = 0; i < tabIds.length; i++) {
71. if (tabIds[i] == checkedId) {
72. setSelection(i);
73. break;
74. }
75. }
76. }
77. });
79. setSelection( 0);
80. }
82. private void setSelection(int position){
84. FragmentManager fm = getSupportFragmentManager();
85. FragmentTransaction ft = fm.beginTransaction();
86. hideAllFragments(ft);
88. switch (position) {
89. case 0:
90. if (mTab1 == null) {
91. mTab1 = new FragmentTab1();
92. ft.add(R.id.content, mTab1);
93. } else {
94. ft.show(mTab1);
95. }
96. break;
98. case 1:
99. if (mTab2 == null) {
100. mTab2 = new FragmentTab2();
101. ft.add(R.id.content, mTab2);
102. } else {
103. ft.show(mTab2);
104. }
105. break;
107. case 2:
108. if (mTab3 == null) {
109. mTab3 = new FragmentTab3();
110. ft.add(R.id.content, mTab3);
111. } else {
112. ft.show(mTab3);
113. }
114. break;
116. default:
117. break;
118. }
120. ft.commit();
121. }
123. private void hideAllFragments(FragmentTransaction ft){
124. if (mTab1 != null) {
125. ft.hide(mTab1);
126. }
128. if (mTab2 != null) {
129. ft.hide(mTab2);
130. }
132. if (mTab3 != null) {
133. ft.hide(mTab3);
134. }
135. }
137. }

使用第二种方式做Fragment的切换时，经常会出现上图所示Fragment重叠问题。直接back键退出应用再进入时，则没有出现该问题。当应用被强行关闭后（通过手机管家软件手动强关，或系统为节省内存自动关闭应用），再次进入应用时，每次都会出现这种花屏现象。

通过分析发现，正常back键退出应用时，Activity及所属的Fragment对象均会被销毁，因此再次进入时会在切换到Tab时创建对应的Fragment对象。
但是当强行关闭应用后，Activity虽然被回收，但Fragment对象仍然保持，再次进入应用时，系统会分别调用Fragment的onAttach方法将其附加到Activity上，后面会分别调用两个fragment的onCreateView方法，因此这两个Fragment对应的View层次结构都会加到Activity的View层次中。
虽然切换Fragment时会把所有fragment先隐藏再显示选中的对象，但由于此时Activity中Fragment对象的成员变量还未初始化，因此会再次实例化fragment对象，之后add、show及hide的都是在第二次创建的对象上操作的，而之前被保持的fragment对象的视图层次已经反映到Activity视图中并且不会被hide，因此发生了上述重叠现象。

解决办法有三种：

第一种：

在Activity的onAttachFragment方法中，有一个fragment参数，它就是onAttach方法对应的Fragment对象，
通过判断这个fragment对象，如果属于我们的FragmentTabX类并且该类还未被实例化过，则将Activity的成员变量mFragmentTabX指向该fragment对象，这样就可以在原来的fragment对象上操作add/show/hide，因此不会有重叠现象

1. @Override
2. public void onAttachFragment(Fragment fragment) {
3. // TODO Auto-generated method stub
4. super.onAttachFragment(fragment);
5. Log.d(TAG, "onAttachFragment");
7. if (mTab1 == null && fragment instanceof FragmentTab1) {
8. mTab1 = (FragmentTab1)fragment;
9. } else if (mTab2 == null && fragment instanceof FragmentTab2) {
10. mTab2 = (FragmentTab2)fragment;
11. } else if (mTab3 == null && fragment instanceof FragmentTab3) {
12. mTab3 = (FragmentTab3)fragment;
13. }
14. }

第二种：

调用三个参数的add函数，添加Tag参数用于标记：

transaction.add(R.id.content, IndexFragment,”Tab1″);

然后，在fragment初始化前，添加引用判断，找打对应的引用，如果依旧为空，再调用fragment构造函数进行初始化：

IndexFragment＝FragmentManager.findFragmentByTag(“Tab1″);

第三种：

在进入onCreate函数时，先去判断savedInstanceState是否为null，如果不为null,则表示里面有保存这四个fragment。则不再重新去add这四个fragment，而是通过Tag从前保存的数据中直接去读取。

1. FragmentManager fManager;
2. @Override
3. public void onCreate(Bundle savedInstanceState) {
4. // TODO Auto-generated method stub
5. fManager = getFragmentManager();
6. if (savedInstanceState != null) {
7. allFrg = (AllOfficialAccountFragment) fManager.findFragmentByTag( "allFrg");
8. movieFrg = (MovieOfficialAccountFragment) fManager.findFragmentByTag( "movieFrg");
9. newsFrg = (NewsOfficialAccountFragment) fManager.findFragmentByTag( "newsFrg");
10. otherFrg = (OtherOfficialAccountFragment) fManager.findFragmentByTag( "otherFrg");
11. }
12. super.onCreate(savedInstanceState);
13. }

2.Fragment not attached to Activity异常

出现该问题，主要是因为在Fragment还没有被关联到Activity的时候或者被Attach的Activity已经destroy了的时候，调用了需要上下文Context的函数，常见的如fragment的getResource()方法。解决办法主要有：

一：将调用的代码移动到onStart（）方法中；

三：使用被Attach的Activity的相应方法，如getActivity().getResource...等；

二：在调用的代码前添加Fragment的isAdd（）方法进行判断，推荐使用这种方式！

3. Fragment中onActivityResult（）注意问题

通常，我们会在FragmentActivity中嵌套一层Fragment使用，甚至在Fragment中再次层层嵌套Fragment，此时，会出现第二层及更深层次的子Fragment对象无法接收到onActivityResult（）事件。

查看FragmentActivity源码：

1. @Override
2. protected void onActivityResult(int requestCode, int resultCode, Intent data) {
3. mFragments.noteStateNotSaved();
4. int index = requestCode>> 16;
5. if (index != 0) {
6. index--;
7. if (mFragments.mActive == null || index < 0 || index >= mFragments.mActive.size()) {
8. Log.w(TAG, "Activity result fragment index out of range: 0x"
9. + Integer.toHexString(requestCode));
10. return;
11. }
12. Fragment frag = mFragments.mActive.get(index);
13. if (frag == null) {
14. Log.w(TAG, "Activity result no fragment exists for index: 0x"
15. + Integer.toHexString(requestCode));
16. } else {
17. frag.onActivityResult(requestCode& 0xffff, resultCode, data);
18. }
19. return;
20. }
22. super.onActivityResult(requestCode, resultCode, data);
23. }

可以看出，FragmentActivity没有处理嵌套Fragment的情况，也就是说，只是回调到第一级的Fragment中，然后没有继续分发下去。

所以，我们需要在第一级的Fragment的onActivityResult（）中控制分发onActivityResult事件。

4. FragmentTransaction的commit问题

FragmentTransaction有commit（）和commitAllowingStateLoss（）两个提交方法，通过源码看他们的区别：

commit（）：

1. Schedules a commit of this transaction. The commit does not happen immediately; it will be scheduled as work on the main thread to be done the next time that thread is ready.
2. A transaction can only be committed with this method prior to its containing activity saving its state. If the commit is attempted after that point, an exception will be thrown. This is because the state after the commit can be lost if the activity needs to be restored from its state. See commitAllowingStateLoss() for situations where it may be okay to lose the commit.
4. Returns:
5. Returns the identifier of this transaction's back stack entry, if addToBackStack(String) had been called. Otherwise, returns a negative number.

commitAllowingStateLoss（）：

Like commit but allows the commit to be executed after an activity's state is saved. This is dangerous because the commit can be lost if the activity needs to later be restored from its state, so this should only be used for cases where it is okay for the UI state to change unexpectedly on the user.

顾名思义，可以看出，使用commit（）方法，如果在Activity保存状态后发生了commit行为，将抛出异常：

1. java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
2. at android.support.v4.app.FragmentManagerImpl.checkStateLoss(Unknown Source)
3. at android.support.v4.app.FragmentManagerImpl.enqueueAction(Unknown Source)
4. at android.support.v4.app.BackStackRecord.commitInternal(Unknown Source)
5. at android.support.v4.app.BackStackRecord.commit(Unknown Source)

而commitAllowingStateLoss（）方法允许这种调用，但是当Activity回复状态时，之前fragment的提交状态将丢失。所以，如果你允许这种丢失commit状态的话，可以使用commitAllowingStateLoss（）。