先扯两句
之前那么些天没有写博客，这总算赶上一个假期，打算把阶段性修改的部分都总结一下发出来，这应该是最后一篇了，其中当然也有不完整的地方，那就是之前写的博客会再写一下BaseFragment封装的部分，BaseFragment系列与BaseActivity系列基本功能都是一致的，整体差别不大，所以这里也就不多做说明了，大家可以直接取我的github查源码，有什么需要也可以在博客中留言沟通，这里就不多加赘述了。
好了，闲言少叙，老规矩还是先上我的Git，然后开始正文吧。 MyBaseApplication (https://github.com/BanShouWeng/MyBaseApplication)
正文
首先，关于BaseFragmentActivity从BaseActivity中拆解出来是早就已经定好的部分，这部分主要封装的都是一些Activity调用Fragment的方法，当然，这部分没有包含ViewPager的使用，只是单纯的添加Fragment而已，关于ViewPager的部分后续会做考虑，有需要的大家只能先自行封装一下了，比较浅显的运用，我之前编写的一个小demo中有所涉猎，大家也可以去看一下，或许能有所帮助。
下面真的开始进入正文了。
添加
private FragmentTransaction transaction;
/**
* 添加Fragment
*
* @param containerViewId 对应布局的id
* @param fragments 所要添加的Fragment，可以添加多个
*/
public void addFragment(int containerViewId, Fragment... fragments) {
if (null == transaction) {
transaction = getSupportFragmentManager().beginTransaction();
}
if (fragments != null) {
for (int i = 0; i < fragments.length; i++) {
transaction.add(containerViewId, fragments[i]);
if (i != fragments.length - 1) {
transaction.hide(fragments[i]);
}
}
transaction.commit();
} else {
Logger.e(getName(), "没有Fragment");
}
}
这个部分主要针对的是APP主页的添加，一次批量添加所有的Fragment，参数比较简单，其一是Fragment所要替换的占位布局的id，其二是所要加载的Fragment，其余的就是判空之类的处理，并不复杂。
展示与隐藏
/**
* 显示Fragment
*
* @param fragment 所要显示的Fragment
*/
public void showFragment(Fragment fragment) {
if (null == transaction) {
transaction = getSupportFragmentManager().beginTransaction();
}
if (fragment != null) {
transaction.show(fragment).commit();
} else {
Logger.e(getName(), "ragment不存在");
}
}
/**
* 隐藏Fragment
*
* @param fragments 所要隐藏的Fragment，可以添加多个
*/
public void hideFragment(Fragment... fragments) {
if (null == transaction) {
transaction = getSupportFragmentManager().beginTransaction();
}
if (fragments != null) {
for (Fragment fragment : fragments) {
transaction.hide(fragment);
}
transaction.commit();
} else {
Logger.e(getName(), "没有Fragment");
}
}
添加后，我们需要将展示其中的某一个Fragment，而其他的则需要隐藏起来，其实当我们调用了某一个的显示后，对应Fragment自定会被置于组上层，呈现在用户眼前。不过开发中，我们或许会需要判断当前Fragment是否处于显示状态，或者隐藏状态，所以最好还是调用一下这两个方法，方便操作以及手机适配。
显隐状态监听方法：
@Override
public void onHiddenChanged(boolean hidden) {
super.onHiddenChanged(hidden);
if(hidden){
//TODO now visible to user
} else {
//TODO now invisible to user
}
}
移除
/**
* 移除Fragment
*
* @param fragments 所要移除的Fragment，可以添加多个
*/
public void removeFragment(Fragment... fragments) {
if (null == transaction) {
transaction = getSupportFragmentManager().beginTransaction();
}
if (fragments != null) {
for (Fragment fragment : fragments) {
transaction.hide(fragment);
}
transaction.commit();
} else {
Logger.e(getName(), "没有Fragment");
}
}
有添加自然会有删除，不过这个方法从开发到现在，记忆中是没有使用过，不过存在即合理，还是一并封装了，总比需要用的时候没有要强很多啊。
替换
/**
* 替换Fragment
*
* @param containerViewId 对应布局的id
* @param fragment 用于替代原有Fragment的心Fragment
*/
public void replaceFragment(int containerViewId, Fragment fragment) {
if (null == transaction) {
transaction = getSupportFragmentManager().beginTransaction();
}
if (fragment != null) {
transaction.replace(containerViewId, fragment).commit();
} else {
Logger.e(getName(), "ragment不存在");
}
}
上面说的方法主要都是批量处理的，也就是在同一个占位控件处，添加了多层Fragment，用代码控制其隐藏或者显示的状态来操作，好处是可以更流畅的切换Fragment而不需要每次切换都重新加载，以及数据获取。但是得到便利的同时，付出的代价就是资源的耗费。浅显点理解就是同一时间只显示一个Fragment，其余Fragment的持有都是资源的浪费。同样，还有一个问题就是当APP长时间后台运行时，较多的Fragment很容易被GC回收，再次打开APP时导致APP的崩溃。
而使用replace则不会有上述被回收的问题，以及资源的浪费。可同样，它付出的代价就是APP Fragment切换时的流畅体验，之前看过一篇APP测试报告，要求首页不同页面间随机快速切换20次、无卡顿、无崩溃。这个时候如果使用replace，那绝对会是一个悲剧。
至于具体如何选择，还是那句话，看业务需求吧，这已经不是能随便看心情的事了。
划重点
不要吐槽这个标题，我也不想啊，实在是池子的脱口秀看多了。
其实上述这些真的没有什么可写的，只是代码的堆积，最多就是根据我浅显的工作经验区分一下应用场景以及差异，所以险些一激动直接不写这篇博客了，毕竟有源码大家也都能看出个所以然来。
不过懒汉最该做的事就是老老实实的闲着，哪怕发呆也好啊。我这种闲不住的懒汉就悲催了，非要去看什么《阿里巴巴Android开发手册》，结果就发现了之前封装中的问题（前面发的是已经修改过的），这下好了，还得写一篇博客，没办法好好偷懒了！先看看阿里巴巴的大牛是怎么说的。
Activity 可 能 因 为 各 种 原 因 被 销 毁 ， Android 支 持 页 面 被 销 毁 前 通 过
Activity#onSaveInstanceState() 保 存 自 己 的 状 态 。 但 如 果
FragmentTransaction.commit()发生在 Activity 状态保存之后，就会导致 Activity 重
建、恢复状态时无法还原页面状态，从而可能出错。为了避免给用户造成不好的体
验，系统会抛出 IllegalStateExceptionStateLoss 异常。推荐的做法是在 Activity 的
onPostResume() 或 onResumeFragments() （ 对 FragmentActivity ） 里 执 行
FragmentTransaction.commit()，如有必要也可在 onCreate()里执行。不要随意改用
FragmentTransaction.commitAllowingStateLoss()或者直接使用 try-catch 避免
crash，这不是问题的根本解决之道，当且仅当你确认 Activity 重建、恢复状态时，
本次 commit 丢失不会造成影响时才可这么做。
翻译一下，就是当使用commit的时候，可能会因为Fragment被回收，而导致“Caused by: java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState
”异常，而网上查到的大多数讲解都是将commit替换成commitAllowingStateLoss方法，可实际上这是治标不治本的玩法，并没有从根本上解决问题，所以还不如让APP崩溃，重新运行的好。
当发现以我现在的实力实在说不明白这两者之间的区别怎么办呢？当然是求助大神了Android commit和commitAllowingStateLoss区别及应用场景（别问我为什么这次没有给作者链接，这就是人间的gitPage的链接，如果不是不会玩，我都想搭一个了），这篇博客中有比较详细的说明，所谓公说公有理婆说婆有理，而这篇博客中的说法还算是比较中肯的了，具体使用哪种方式，各位自行决断吧。
