Android 应用程序活动设计

为什么

AppCompatActivity

的

getFragmentManager（）

不返回片段管理器的支持版本？相反，您必须将您的活动设置为

AppCompatActivity

，并专门调用

getSupportFragmentManager（）

。其他十几种方法也是如此。你必须神奇地知道哪些方法可以自己调用，哪些方法必须重新命名为“支持”版本，这让我很烦。当您仍然支持较低版本的Android时，是否有任何用例需要调用“正常”版本而不是“支持”版本？如果

AppCompatActivity

的功能与

Activity

的较新API版本没有区别，那么对我来说就更有意义了-毕竟，这就是它应该做的，不是吗？提供与

活动

的更高API版本相同的功能

是否有某种设计原则或隐藏的Java限制阻止他们这样做

为什么AppCompatActivity的getFragmentManager（）不返回片段管理器的支持版本

因为它不能

API级别11+上的

活动

将

getFragmentManager（）

定义为返回一个

android.app.FragmentManager

。

AppCompatActivity

可以覆盖它的唯一方法是，被覆盖的方法还返回一个

android.app.FragmentManager

。那是不可能的

AppCompatActivity

设计用于返回到API级别7，在该级别中没有要返回的

android.app.FragmentManager

。因此，我们有

getSupportFragmentManager（）

，返回一个

android.support.v4.app.FragmentManager

---

请注意，

AppCompactActivity

实际上是从

FragmentActivity

中获取其片段的，该片段设计用于回到API级别4，比API级别11和本机片段实现早两年。

例如，为什么不让支持库定义自己版本的

android.app.FragmentManager

？（我预测的原因可能是“那么支持版本将与以后API中的本机版本冲突”或“安全原因”。但我不确定。）@Erhannis：“例如，为什么不让支持库定义自己版本的android.app.FragmentManager？”——因为使用该库的应用程序在API级别11+上崩溃，与android.app.FragmentManager的实现冲突。如果在类装入器和反射方面没有一些棘手的方法，我会感到惊讶，但我还是不说了。我遇到的另一个解决方案是让他们拥有子类化的Activity，而不是向其中添加方法，因此AppCompativeActivity和Activity11或其他两者都使用自己版本的FragmentManager实现getFragmentManager（）。不过，我不能说我喜欢这种方法；令人讨厌的凌乱。好吧，我屈服；谢谢不过，我还是不太喜欢所有的“支持”方法；它也不整洁。