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

【问题标题】：Why does AOSP add new APIs to support libraries without adding them to SDK?为什么 AOSP 添加新的 API 来支持库而不将它们添加到 SDK？
【发布时间】：2015-05-25 17:01:35
【问题描述】：

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

示例：

FragmentTabHost API 只能通过android.support.v4.app.FragmentTabHost 使用。大多数时候都很好，但是如果你想同时使用片段嵌套和PreferenceFragment，你就死定了——嵌套需要你切换到android.support.v4.app.Fragment（用于支持4.2以下），但是没有在此支持库中实现 PreferenceFragment。因此，您要么实现自定义解决方法，要么使用已经实现它们的第三方库（请参阅this question）

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

示例：

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

后果：

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

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

问题：

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

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

【问题讨论】：

补充一点，RecyclerView 必须只能从支持库访问。我相信除了你已经列出的原因之外，如果谷歌可以将“额外的、非标准”的功能放在不同的库中，这可能是一种尽量保持 SDK 最小化的方法。
FragmentTabHost 不是从任何东西进化而来的。有两个单独的版本。 support-v4 处理支持片段，support-v13 处理原生片段。 ||| 使用支持片段更好，因为它们可以更快地得到修复。图书馆经常得到修复。为了修复任何原生的东西，谷歌必须推出一个新版本的 Android，而修复将是该新版本独有的。其他所有人都必须使用支持库。
@EugenPechanec，让我再次尝试解释一下自己。如果将原生Fragment 的FragmentTabHost 添加到主SDK 而不是support-v13，那么当然会发现一些错误（与任何新API 一样）。但是这些错误将在 1-3 个 SDK 版本中得到解决，并且从 Android 5.x（或 6.x 等）开始，此 API 将变得稳定。然后，从那时起几年后，任何希望使用此 API 的开发人员都可以在没有任何任何支持库的情况下执行此操作。问题是为什么不在某个时候向 SDK 添加新的 API？
Romain Guy 似乎证实了@MeetTitan 建议的保持 SDK 最小化的基本原理：cyrilmottier.com/2012/07/06/api-16-jelly-bean-review/…。也就是说，我认为将 ViewPager 限制在支持库中是一个错误。这个小部件太普遍了，无法标准化。它也是少数支持在移动 UI 上使用基于片段的设计的真正论据之一，如果片段在框架中，那么它也应该如此。同样，如果RecyclerView 确实被设计为最终有效替代ListView，那么它也应该在框架中。
@corsair992，感谢链接。虽然很老，但该线程提供了对该问题的更多见解。似乎许多开发人员都要求提供库，无论是谷歌的还是第三方的。他们希望现有的运行良好的库（如ActionBarSherlock）要么由谷歌“推广”，要么由谷歌维护。虽然他们的愿望是完全合法的，并且@RomainGuy 关于保持 SDK 小而不添加可能“过时”的组件的推理，但这仍然不能解释你将它们添加到 Support Libs ......为什么不拥有单独的库对于DrawerLayout 和ViewPager?

标签： android compatibility android-support-library

【解决方案1】：

FragmentTabHost API 只能通过 android.support.v4.app.FragmentTabHost 使用。

不正确。您提供的链接指向android.support.v13.app.FragmentTabHost（与android.support.v4.app.FragmentTabHost 不同）与native Fragments 一起使用，但使 API 13 以上引入的 API 自 API 13 起可用 .

简而言之：v7 支持库依赖于 SDK，因此我必须定义 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

现在，我告诉自己：FragmentTabHost 尚未添加到任何 SDK 版本中，这意味着即使在 4-5 年后，开发人员仍将继续使用 support-v4 lib 来提供此功能（因为即使此 API是今天添加的，您可能需要数年时间才能安全地假设所有目标设备都原生支持它），对吧？

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

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

Google 为什么要永久保留这些库？

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

即使现在您使用 appcompat-v7 中的 ActionBarActivity（最初旨在将操作栏向后移植到 API 7）和 minSdkVersion 14，因为您想要该材料设计向后移植。这也意味着你被支持片段卡住了，因为ActionBarActivity 正在使用它们。

如果将所有新 API 与兼容性库并行添加到 SDK 中，这样兼容性库可能会在某个时候老化并“退出”，这不是更好吗？

支持图书馆时代。您可能已经注意到 recyclerview-v7（和其他最近的 android 库）从 API 7 开始可用，而不是 API 4。而且您可能还注意到 RecyclerView 不在本机 SDK 中。当您可以推出支持库以供所有人使用时，为什么要将其添加到本机 SDK 以使其仅可用于最新平台？

【讨论】：

我认为您误解了这个问题。 ViewPager 呢？如果我只针对 API 22，如果我想要 ViewPagers，我需要 support-v4。
感谢您的回复。事实上，我没有注意到有 FragmentTabHost 用于原生片段（这让我想知道我以前的应用程序是如何使用 v4 版本的......），但这并没有回答这个问题 - 为什么将它添加到另一个支持库，而不是到主 SDK？事实上，支持库中 API 的这种演变让我更加困惑……
@EugenPechanec，我会尝试改写 - 我完全清楚为什么在支持库中引入这些 API。问题是为什么不将它们在某个时候添加到 SDK 中？您关于进行更改的论点几乎同样适用于 SDK 本身的每个功能，但 Google 不会将任何独立的功能集放入单独的库中，对吗？
那为什么不把Switch添加到一些支持库中呢？
@EugenPechanec，我明白你的意思。困扰我的是你没有解决的部分。例如：为什么 SDK 和支持库中都引入了 Fragments，但 Navigation Drawer 没有进入 SDK？两者都是谷歌推荐的设计模式......这个列表还在继续。我建议我们结束讨论并等待看看我们是否可以从其他社区成员那里获得另一种观点。无论如何，为您的见解和建议 +1。