Fragment进阶-commit使用细节及源码分析

1. 每个事务(FragmentTranscation)只能被commit一次

承接Fragment进阶 - 基本用法中“Fragment动态加载”的事例,如果界面里有多个Fragment需要提交,而且我不想一次性全部提交,而是分几次提交...(事例代码如下)

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), null).commit();
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), null).commit();
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), null).commit();
    }
}

运行程序,没有问题程序正常,然后看下此时的视图结构:

add.png

我们add了3次,我们的Activty里有了3个Fragment的视图(这也是小编踩坑之后才成功的)。

在最初进行编写代码的时候,小编遇到一个坑,最初的代码是这样写的:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
        transaction.add(R.id.fl_main, new ContentFragment(), null).commit();
        transaction.add(R.id.fl_main, new ContentFragment(), null).commit();
        transaction.add(R.id.fl_main, new ContentFragment(), null).commit();
    }
}

我们把事务对象提取了出来(相信这是有洁癖的程序员的爱好),进行了多次提交,运行一下结果程序崩溃了(崩溃日志如下)...

 Caused by: java.lang.IllegalStateException: commit already called

日志告诉我们commit已经被调用了,看来每个事务对象只能commit一次...

但是之前的写法是没问题的,由此可以推测:每次调用getSupportFragmentManager().beginTransaction()获取的都是一个新的实例。

查看源码,证实了我们的推测...

fragment_transation.png

原来,我们开启的每一个事务都是一个回退栈记录(BackStackRecord是FragmentTransaction的一个具体实现类)

接下来,我们研究下BackStackRecord,看看commit异常是怎么抛出的。

commit_error.png

BackStackRecord的commit操作会调用一个commitInternal方法。

mCommitted记录了提交状态,我们的第1次提交mCommitted被置为true,第2次提交就抛异常了(整个源码中对mCommitted进行赋值的地方仅此1处(628行))。

结论:每个事务对象只能被commit一次。


2. Activity执行完onSaveInstanceState()方法后不能再执行commit()方法

小编想手动控制Fragment的添加显示,在Activity被销毁的时候将Fragment移除掉(代码如下)

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), "ContentFragment").commit();
    }

    @Override
    protected void onDestroy() {
        getSupportFragmentManager().beginTransaction().remove(getSupportFragmentManager().findFragmentByTag("ContentFragment")).commit();
        super.onDestroy();
    }
}

运行下程序,发现退出时程序崩溃了...我们得到如下崩溃日志:

Caused by: java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState

异常日志告诉我们:不能在onSaveInstanceState()方法被执行之后调用commit()方法。

那么我们就提到onSaveInstanceState()之前调用,代码如下:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), "ContentFragment").commit();
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        getSupportFragmentManager().beginTransaction().remove(getSupportFragmentManager().findFragmentByTag("ContentFragment")).commit();
        super.onSaveInstanceState(outState);
    }
}

运行下程序,发现退出程序不蹦了...但又有一个新问题,手机灭屏时也会调用onSaveInstanceState方法,在打开界面发现界面变成空白了...这种方法(手动移除Fragment)显然不行,这点需要注意。

3. commitAllowingStateLoss()方法

FragmentTranscation 给我们提供了另外一个方法 commitAllowingStateLoss(),从名字我们也能看出这个方法的作用:允许状态丢失的提交。

看下官方文档的解释,我们就能明白原因了:

FragmentTransaction API commitAllowingStateLoss() (需要翻墙)

commit.png

原来,在Activity的状态被保存之后的提交操作是没有被Activity所记录的,恢复时也就没办法恢复这些提交操作,所以官方文档称这个方法是一个危险的操作。如果这些提交操作不是很重要,丢不丢失无所谓的话你就可以使用commitAllowingStateLoss()这个方法了。

我们调整下代码,用commitAllowingStateLoss()代替commit()方法(如下):

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), "ContentFragment").commit();
    }

    @Override
    protected void onDestroy() {
        getSupportFragmentManager().beginTransaction().remove(getSupportFragmentManager().findFragmentByTag("ContentFragment")).commitAllowingStateLoss();
        super.onDestroy();
    }
}

运行下代码,现在看起来没问题了...但我们知道如果出现了Activity异常销毁重启的情况,我们的移除操作在恢复时就丢失了,我们的Fragment将会出现重复叠加的问题。

之前小编在Fragment进阶 - FragmentTransaction详解最开始的时候阐述过这个问题,给出过最佳的解决办法,就不再重复说明了。

最后,我们从源码上看下commit()commitAllowingStateLoss()有什么区别。

下面为BackStackRecord(FragmentTransaction的具体实现类)的部分源码。

final class BackStackRecord extends FragmentTransaction implements
        FragmentManager.BackStackEntry, Runnable {

        ......

        public int commit() {
            return commitInternal(false);
        }

        public int commitAllowingStateLoss() {
            return commitInternal(true);
        }
    
        int commitInternal(boolean allowStateLoss) {
            ......
            mManager.enqueueAction(this, allowStateLoss);
            ......
        }
        ......    
}

我们看到commit()commitAllowingStateLoss()都调用了commitInternal(boolean allowStateLoss)这个方法只不过传入参数不同而已(commit()传入的false,commitAllowingStateLoss()传入的true),接下来会调用FragmentManagerImpl(FragmentManager的具体实现类)的enqueueAction方法。

final class FragmentManagerImpl extends FragmentManager implements LayoutInflaterFactory {
    ......
    public void enqueueAction(Runnable action, boolean allowStateLoss) {
        if (!allowStateLoss) {
            checkStateLoss();
        }
        ......
    }
    .....

}

我们看到,如果commitAllowingStateLoss()传的是true所以忽略掉了检查,commit()传的是false,所以进行了检查。

最后我们看下检查的方法checkStateLoss():

final class FragmentManagerImpl extends FragmentManager implements LayoutInflaterFactory {
    ......
    private void checkStateLoss() {
        if (mStateSaved) {
            throw new IllegalStateException(
                    "Can not perform this action after onSaveInstanceState");
        }
        ......
    }
    ......
}

看来我们之前的异常就是在这抛出的,也算是找到根源了。

4. commit()方法被调用时并不会立即执行

举个简单的例子:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), null).commit();
        Log.e("TAG", "MainActivity onCreated");
    }

    @Override
    public void onAttachFragment(Fragment fragment) {
        super.onAttachFragment(fragment);
        Log.e("TAG", "MainActivity onAttachFragmented");
    }
}

onAttachFragment(Fragment fragment)方法,会在添加进来的Fragment执行完onAttach方法后被回调。

我们得到如下的运行日志:

10-17 17:26:51.076 9035-9035/com.sina.example.fragmentdemo E/TAG: MainActivity onCreated
10-17 17:26:51.078 9035-9035/com.sina.example.fragmentdemo E/TAG: Fragment onAttach()
10-17 17:26:51.078 9035-9035/com.sina.example.fragmentdemo E/TAG: MainActivity onAttachFragmented

我们看到commit()被调用后Fragment的生命周期没有立即开始,而是放在了onCreate(Bundle savedInstanceState)执行完成之后的某个时间。

(具体开始执行的时间点:在源码中该任务是被放在一个mHost.getHandler().post(mExecCommit)方法的参数里,也就是Handler初始化完毕,开始发送消息的时候,我们提交的任务将会被真正执行)

如果不想等待Handler初始化完毕,想要立即执行commit的操作可以使用FragmentManager里提供的executePendingTransactions()方法,这个方法将会将你所有提交的操作一并执行,而且是立即执行。

我们更改代码,添加上这个方法(如下所示)。

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getSupportFragmentManager().beginTransaction().add(R.id.fl_main, new ContentFragment(), null).commit();
        getSupportFragmentManager().executePendingTransactions();
        Log.e("TAG", "MainActivity onCreated");
    }

    @Override
    public void onAttachFragment(Fragment fragment) {
        super.onAttachFragment(fragment);
        Log.e("TAG", "MainActivity onAttachFragmented");
    }
}

运行程序,打印下日志:

10-17 17:51:37.626 22400-22400/com.sina.example.fragmentdemo E/TAG: Fragment onAttach()
10-17 17:51:37.626 22400-22400/com.sina.example.fragmentdemo E/TAG: MainActivity onAttachFragmented
10-17 17:51:37.627 22400-22400/com.sina.example.fragmentdemo E/TAG: MainActivity onCreated

我们看到在"MainActivity onCreated"日志还未被打印之前,我们提交的Fragment的生命周期已经开始了。

5. commitNow()commitNowAllowingStateLoss()

在最新的API_24文档里FragmentTranslation里添加了两个方法:

  • commitNow()

  • commitNowAllowingStateLoss()

调用这两个方法类似于先执行commit()/commitAllowingStateLoss()然后执行executePendingTransactions()方法。但也有区别。

区别一:不支持添加到回退栈的操作(源码如下)

final class BackStackRecord extends FragmentTransaction implements
            FragmentManager.BackStackEntry, Runnable {
    ......

    @Override
    public void commitNow() {
        disallowAddToBackStack();
        mManager.execSingleAction(this, false);
    }

    @Override
    public void commitNowAllowingStateLoss() {
        disallowAddToBackStack();
        mManager.execSingleAction(this, true);
    }
    ......
}

如果还调用addToBackStack(String name)方法会报一个IllegalStateException异常,告诉你不能向回退栈中添加FragmentTransaction。

区别二:源码没有再使用Handler,而是直接执行(源码如下)

final class FragmentManagerImpl extends FragmentManager implements LayoutInflaterFactory {

    ......
    public void execSingleAction(Runnable action, boolean allowStateLoss) {

        ......
        action.run();
        ......

    }
    ......
}

BackStackRecord实现了Runnable接口重写了run方法,action.run()会直接执行BackStackRecord的run方法。

补充:

官方更推荐使用commitNow()commitNowAllowingStateLoss()来代替先执行commit()/commitAllowingStateLoss()然后执行executePendingTransactions()这种方式,因为后者会有不可预料的副作用。

总结:

  1. 如果你需要同步提交Fragment并且无需添加到回退栈中,则使用commitNow()。Support库中在 FragmentPagerAdapter中使用这个函数,来确保更新Adapter的时候页面被正确的添加和删除。一般来说,只要不添加到回退栈中,都可以使用这个函数来提交。

  2. 如果执行的提交不需要是同步的,或者需要将提交都添加到回退栈中,那么就使用commit()

  3. 如果你需要把多次提交的操作在同一个时间点一起执行,则使用 executePendingTransactions()

  4. 如果你需要在Activity执行完onSaveInstanceState()之后还要进行提交,而且不关心恢复时是否会丢失此次提交,那么可以使用commitAllowingStateLoss()commitNowAllowingStateLoss()

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,607评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,047评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,496评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,405评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,400评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,479评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,883评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,535评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,743评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,544评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,612评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,309评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,881评论 3 306
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,891评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,136评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,783评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,316评论 2 342

推荐阅读更多精彩内容