android - 为什么 AOSP 添加新的 API 来支持库而不将它们添加到 SDK？

Question

我已经为 Android 开发了几个月，这个问题一次又一次地出现:添加全新功能 (API) 以支持库而不在标准 SDK 中提供它们的动机是什么？

示例:

FragmentTabHost API 只能通过 android.support.v4.app.FragmentTabHost 获得。大多数时候都可以，但是如果你想使用 fragment 嵌套和PreferenceFragment在一起，你死在水里 - 嵌套需要你切换到 android.support.v4.app.Fragment (用于支持低于 4.2)，但在这个支持库中没有 PreferenceFragment 的实现.因此，您要么实现自定义变通办法，要么使用已经实现它们的第三方库(参见 this question)

编辑:正如@eugen 在他的回答中指出的那样，我自己从支持 native fragment 的 support-v13 中引用了 FragmentTabHost。但是，此信息不会改变整个问题。事实上，如果我将这个 API 与 fragment 嵌套一起使用，我的应用程序将无法在今天大约 30% 的设备上运行(原生 fragment 从 4.2 开始支持嵌套)。

示例:

我今天遇到的另一个问题(并且浪费了太多时间)是 ActionBarDrawerToggle可通过 android.support.v7.app.ActionBarDrawerToggle 获得。我想使用这个功能，因此我将整个 com.android.support:appcompat-v7:21.0.+ 添加到项目的依赖项中。我猜这会做，但我错了——我的应用程序没有编译(缺少支持库引用的资源)。在网上尝试了一些技巧后，我找到了this question最终提供了解决方案。简而言之:v7 支持库依赖于 SDK，因此我必须定义 compileSdkVersion 21.

后果:

现在，我告诉自己:FragmentTabHost 尚未添加到任何 SDK 版本中，这意味着即使在 4-5 年后，开发人员仍将继续使用 support-v4 lib 来提供此功能(因为即使此 API是今天添加的，您可能需要数年时间才能安全地假设所有目标设备都 native 支持它)，对吧？相同的论点适用于 android.support.v4.widget.DrawerLayout 和仅存在于支持库中的其他 API。

如果开发人员一定要使用支持库多年，这也意味着他们一定会在这些问题已经解决很久之后遇到上述不一致/依赖问题，对吧？

问题:

Google 为什么要永久保留这些库？如果所有新的 API 都与兼容性库并行添加到 SDK 中，这样兼容性库可能会老化并在某个时候“退役”，这不是更好吗？

编辑:在@eugen 的回答之后，我现在更加困惑 - 一些 API “进化”与更新的支持库，但没有进入主 SDK(如 FragmentTabHost，它从 support-v4 演变为支持-v7)。不将它们添加到 SDK 的原因是什么？

Answer 1

FragmentTabHost API is available only through android.support.v4.app.FragmentTabHost.

不正确。您提供的链接指向 android.support.v13.app.FragmentTabHost (与 android.support.v4.app.FragmentTabHost 不同)适用于 native fragment ，但使 API 13 以上引入的 API 从 API 13 开始可用。

In short: v7 support library has dependency on SDK, therefore I had to define compileSdkVersion 21.

当然21版本的库需要21版本的工具和21版本的SDK。 始终使用相应版本的构建工具，编译 SDK 和支持库!

从今天开始，建议使用以下值:

compileSdkVersion 22
buildToolsVersion '22.0.1'

targetSdkVersion 22

compile 'com.android.support:support-v4:22.0.0'
compile 'com.android.support:appcompat-v7:22.0.0' // includes support-v4
compile 'com.android.support:support-v13:22.0.0' // includes support-v4

Now, I tell myself: FragmentTabHost haven't been added to any SDK version yet, which implies that even 4-5 years from now developers will continue to use support-v4 lib for providing this functionality (because even if this API is added today, it will take years before you could safely assume that all target devices support it natively), right?

这意味着如果您使用 support-v13 库来实现它，您无需担心。它将在 API 13 中运行。

阅读上面的 support-v4 和 support-v13 之间的区别。

Why would Google want to keep these libraries forever?

因为您很可能希望支持旧平台。这意味着您需要一个支持库。

即使现在你使用 appcompat-v7 中的 ActionBarActivity(最初打算将操作栏向后移植到 API 7)和 minSdkVersion 14 因为你想要那个 Material 设计的后端。这也意味着你被支持 fragment 卡住了，因为 ActionBarActivity 正在使用它们。

Won't it be better for everybody if all the new APIs were added to SDK in parallel to compatibility libs, such that compatibility libraries could age and "resign" at some point?

支持图书馆时代。您可能已经注意到 recyclerview-v7(以及其他最近的 android 库)自 API 7 而非 API 4 以来可用。而且您可能还注意到 RecyclerView 不在原生 SDK。当您可以推出支持库以供所有人使用时，为什么要将其添加到 native SDK 以使其仅可用于最新平台？