作者：Elye
对于Android开发者来说，深入理解Fragment的原理是重要的。但是，Fragment是一个复杂的组件，大部分人使用它都会犯一些错误。
在Fragment上出现的bug有时候非常难debug，因为Fragment有非常复杂的生命周期，不是总能复现场景。
不过，一些问题能够在代码编写阶段简单地避免。下面是7个问题：
1. 在创建Fragment时，没有检查savedStateInstance
一般我们使用如下代码，在Activity（或者Fragment）的onCreate中显示Fragment界面
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
supportFragmentManager.beginTransaction()
.replace(R.id.container, NewFragment())
.commit()
}
为什么上面的代码不好
上面的代码有一个问题。当你的activity是被系统杀死并恢复时，一个重复的新Fragment将被创建，即恢复的Fragment和新创建的。
正确的方式
我们应该使用savedInstanceState == null来判断。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
if (savedInstanceState == null) {
supportFragmentManager.beginTransaction()
.replace(R.id.container, NewFragment())
.commit()
}
}
如果之前的Fragment被恢复，它将避免创建和执行新的Fragment。如果你想避免恢复Fragment，Manually override Fragments Auto Restoration有一些技巧（虽然不建议用于专业应用程序）。
2. 在onCreateView创建Fragment拥有的对象
有时候，我们需要保证数据对象在Fragment的生命周期中存在。我们认为我们可以在onCreateView中创建它，因为这个方法只在Fragment创建时或者从系统杀死状态恢复时执行一次。
private var presenter: MyPresenter? = null
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?): View? {
presenter = MyPresenter()
return inflater.inflate(R.layout.frag_layout, container, false)
}
为什么上面代码不好
但，上面的说法是有问题的。当Fragment是被另一个Fragment使用replace替换时，这Fragment没有被杀死。同时数据对象仍然在Fragment里面。当Fragment是被恢复（例如另一个Fragment被pop out），这onCreateView将再执行一次。因此数据对象（这里是presenter）将被再次创建。所有你的数据将被重置。
上图中的onCreateView可以在同一个Fragment实例中被反复调用。
不算好的方法
我们可以在创建之前加一个非null判断。
private var presenter: MyPresenter? = null
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?): View? {
if (presenter != null) presenter = MyPresenter()
return inflater.inflate(R.layout.frag_layout, container, false)
}
这个虽然能解决上面的问题，但不算一个好的方法。
更好的方式
我们应该在onCreate中创建Fragment拥有的数据对象。
private var presenter: MyPresenter? = null
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
presenter = MyPresenter()
}
通过这种方式，数据对象将只在每次创建Fragment时被创建一次。当我们弹出顶层Fragment并重新显示Fragment视图时（即调用onCreateView），它将不会被重新创建。
3. 在 onCreateView 中执行状态恢复
我知道在onCreateView中提供了savedInstanceState。因此我们认为我们可以在这里存储数据。
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?): View? {
if (savedInstanceState != null) {
// Restore your stuff here
}
// ... some codes creating view ...
}
为什么这个不好
上面的方式可能造成一个奇怪的问题，你存储在一些Fragment（非顶部可见Fragment）的数据会丢失。出现场景有：
● 你在堆中有超过一个Fragment（使用replace代替add）
● 你把你的应用放到后台并恢复两次或多次
● 你的Fragment被destroy（例如被系统杀死）并恢复
更多关于这个问题的细节可以看Bug that will only surface when you background your App twice
更好的方式
就像上面的示例2一样，我们应该在onCreate方法中执行状态恢复。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
if (savedInstanceState != null) {
// Restore your stuff here
}
}
这种方式可以确保你的Fragment状态总是被恢复，无论你的视图是否被创建（即使是堆栈中不可见的Fragment，也将恢复其数据）。
4. 在Activity中保存了Fragment的引用
有时候因为一些原因，我们想要在Activity（或者父Fragment）中获取Fragment的对象。通过下面的方式，我们可以很简单地获取Fragment的引用。
private var myFragment: MyFragment? = null
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
if (savedInstanceState == null) {
myFragment = NewFragment()
supportFragmentManager.beginTransaction()
.replace(R.id.container, myFragment)
.commit()
}
}
private fun anotherFunction() {
myFragemnt?.doSomething()
}
为什么上述方式不对
Fragment有自己的生命周期。它被系统杀死并恢复。这个意味着引用的原始的Fragment不再存在（虽然myFragemnt不会为null，但是我们执行doSomething时可能由于Fragment被杀死而出错）。
如果我们在Activity中保持Fragment的引用，我们需要确保能不断更新对正确Fragment的引用，如果丢失了，会很棘手。
更好的方式
通过Tag获取你的Fragment
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
if (savedInstanceState == null) {
supportFragmentManager.beginTransaction()
.replace(R.id.container, NewFragment(), FragmentTag)
.commit()
}
}
private fun anotherFunction() {
(supportFragmentManager.findFragmentByTag(FragmentTag) as?
NewFragment)?.doSomething()
}
当你需要访问它时，你总是能通过Fragment Transaction找到它。尽管这是一种可行的方式，我们还是应该尽量减少Fragment和 Activity（或父Fragment）之间的这种交流。
5. 在Fragment的onSavedStateInstance方法中访问View
有时我们想要在Fragment被系统杀死时保存一些view的信息。
override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
binding?.myView?.let {
// doSomething with the data, maybe to save it?
}
}
为什么上面的方法不对
考虑这个场景
● 如果Fragment没有被杀死，而是被另一个Fragment给replace了，这个Fragment的onViewDestroy()方法将被调用 （一般情况下，我们在这里设置binding = null）
● 由于Fragment仍然存在，onSaveInstanceState不会被调用。但是Fragment的view已经不存在了
● 然后，这个时候Fragment被系统杀死，onSaveInstanceState被调用。但是，由于binding是null，该代码不会被执行。
正确的方法
无论你想从view中访问什么，都应该在onSavedStateInstance之前完成，并存储在其他地方。最好是所有这些都在presenter或View Model中完成。
6. 更喜欢使用add而不是replace
我们有replace和add去操作Fragment。有时我们只是想知道我们应该使用哪一个方法。可能我们应该使用add，因为它听上去更合乎逻辑。
supportFragmentManager.beginTransaction()
.add(R.id.container, myFragment)
.commit()
使用add的好处是，确保底部Fragment的view不会被销毁，并且当顶部的Fragment弹出时不需要重新创建view。在下面一些应用场景中，add是有用的。
● 当下一个Fragment是add到一个Fragment的顶部时，它们两个都是可见的，并且互相叠加。如果你在顶部Fragment上有一个半透明的view，你可以看到底部的Fragment
● 当你添加的Fragment是花费长时间加载的时（例如加载Webview），你想要避免其他Fragment弹出时重新加载它。这时你就使用add代替replace。
为什么上面的方式不好
上面提到的两种场景并不常见。因此add应该被限制使用，因为它有如下缺点。
● 使用add将保持底部的Fragment可见，它花费了更多不必要的内存。
● 添加了一个以上可见的Fragment，当它们被一起恢复时，有时可能会导致状态恢复问题。The Crazy Android Fragment Bug I’ve Investigated是2个Fragment一起加载并使用的情况，它会导致复杂和混乱的问题。
首选方式
使用replace代替add，即使是第一个Fragment提交时。因为对于第一个Fragment，replace和add没有不同，不如直接使用replace，使之成为默认的普遍做法。
7. 使用simpleName作为Fragment的Tag
有时我们想对 Fragment进行标记，以便以后检索。我们可以使用当前class的simpleName来标记它，因为它是方便的。
supportFragmentManager.beginTransaction()
.replace(
R.id.container,
fragment,
fragment.javaClass.simpleName)
.commit()
为什么这个不好
在Android中，我们使用Proguard或DexGuard来混淆类的名称。而在这个过程中，混淆后的简单名称可能会与其他类的名称发生冲突，如The danger of using getSimpleName() as TAG for Fragment所述。它可能很少见，但一旦发生，它可能会让你惊慌失措。
首选方式
考虑使用一个常数或规范名称作为tag。这将更好地确保它是唯一的。
supportFragmentManager.beginTransaction()
.replace(
R.id.container,
fragment,
fragment.javaClass.canonicalName)
.commit()
