据我所知，正在使用支持库是因为旧设备没有新的 API。例如，他们不知道 Fragment 是什么以及如何实现它。因此，这些行为是在支持库中定义的。
所以，我的主要问题是，支持库中的 Fragment 库与其在 API 11（Android v3.0，Honeycomb）中引入的双胞胎之间有什么区别。
我的第二个问题是，如果可以将每个新 API 放入支持库中，为什么我们有两种类型的库？我的意思是Android可以在支持库而不是支持库和Android版本X.xx库下发布所有API。
【问题讨论】：
标签： android android-support-library
据我了解，支持库可以替代内置 API，但它们不应该如此，因为它们直接影响应用程序的大小。
例如，一个支持库有 2MB，要使用它的功能，它需要所有类、资源等（2MB），所以现在classes.dex（应用程序中使用的所有类的 Dalvik 可执行文件）的我的应用程序还包括支持库类，资源也是如此。所以，如果没有支持库我的应用程序大小是 1MB，那么现在有了支持库，大小是额外的 2MB，这意味着总共 3MB。
现在，假设这个支持库功能非常普遍，以至于在单个设备上，如果我有 10 个应用程序，那么至少有 9 个应用程序在使用同一个支持库，所以我的设备上的 9*2 = 18MB 正在被同一设备使用支持库，在每个应用程序中都会重复，这很糟糕，因为现在 18MB 可能不是那么多，但是如果您有更多应用程序使用该支持库，则所需的空间可能会增加。
因此，最好的选择是在您的操作系统中为任意数量的应用程序提供 2MB 的支持库，而不是为每个应用程序提供它。因此，当您确实希望应用程序中的一些高效功能支持旧版本时，应该使用支持库。
这里出现另一个问题：
为什么不将此支持库作为自己的更新添加到操作系统中，以便每个没有大小问题的应用程序都可以访问该功能？
答案是可能有很多错误。假设某些用户没有安装该更新（支持库）...
也有可能作为更新，它可能不会像预期的那样高效，或者在与操作系统集成时可能会导致问题，因为我们已经看到每个操作系统（windows、Linux、mac）都附带新版本，而不仅仅是为所有新功能提供终身更新。
【讨论】：
与 Android 2.3.x (Gingerbread) 相比，Android 4.0.x (ICS) 有很多附加功能。兼容性库用于桥接一些添加到 ICS 的更改，这些更改可能会被 Gingerbread 支持。 “可能”是这里的关键词，因为对 ICS 所做的大量更改永远无法与 Gingerbread 一起使用，而且这些更改当然不会获得兼容性库。
例如，您提出的片段实际上在 ICS 中与在兼容性库中的处理方式略有不同，因为 ICS 具有更多可以使用的功能。如果您查看 Fragments 类的 ICS 代码，它们与兼容性库中的代码不同。它是第二组代码，可以让 ICS 中的片段“类似”在 Gingerbread 等旧版本中使用，而程序员不会注意到太多差异。
这就是兼容性库的意义所在，也是它们不用于广泛修补 Gingerbread 以使用 ICS 中的所有功能的原因（它们就是不能）。兼容性库的重点是将新版本的 android 中可用的东西（如 ICS）接口，将 ICS 方式连接到旧版本（如 GB）中，完成 GB 方式。
至于为什么他们不只是保持支持库不断增长并保留相同的基本操作系统 - 答案是兼容性问题。如果用户只有 v4 并且 v12 已出，会发生什么？ Android 目前使用操作系统的 Android API 版本作为应用程序兼容性的基础，开发人员可以选项包含支持库（增加应用程序的文件大小，但他们更新的功能）。每个使用支持库的应用程序都独立地包含它们（意味着 4 个应用程序 = 包含 4 倍）。
我们的想法是，您只能下载当前操作系统 API 版本支持的应用程序（就 Google Play 而言），并且您可以选择包含支持库以保持您的应用程序的外观和感觉支持旧版本API，尚不具有您选择在较新的 API 上可供这些用户使用的功能。这真的是一个外观和感觉比什么都重要的考虑。
希望能解决问题:)
【讨论】：
已经说过的话是真的。虽然缺少一些细节。 事实上，我有机会参加了上一次 Google IO 的一个会议，他们专门讨论了这个问题。 让我惊讶的是，支持库并没有托管所有可能的 API 版本的代码，而是对他们认为足够相关以使它们可用于旧平台的新功能的改编。所以它的工作方式一般是这样的：
所以它就像某种路由网关。原因是使用为最后一个操作系统优化的最后一个代码和最后一个系统改进（即：硬件加速）通常更有效（和执行）。
尽管如此，还是有一些元素没有被翻译到兼容库中，因为它们在本机内置代码中。例如，片段并不打算像 API13 那样重写，因为它们是一个巨大的组件，需要在系统和功能较少的设备中的各种不同场景中运行。
最终，因为这一切，建议使用 compats 库，这是一种很好的做法，特别是如果您打算让您的应用程序/代码可用于旧版本（这应该是理想的方式）
【讨论】：
支持库实际上并不包含新 API 中的所有内容。它确实支持部分 Fragment API，但还不支持 ActionBar。为此，您需要另一个库，例如 ActionBar Sherlock。
为什么有两个库？
因为部分问题是谷歌只向后移植了一些东西，但我的理解是，此外，由于核心操作系统框架的限制和核心深处缺少 API，一些新功能无法向后移植Android UI 框架。
【讨论】：
Android 在最近的版本中提出了片段和操作栏的酷炫功能。
现在，如果我们想使用这些功能并且还支持旧版本的 android，那么我们将不得不编写非常混乱的版本依赖代码，这是不好的。
为了让我们摆脱所有这些混乱，android 提出了支持库，它不提供对新功能的完全支持，但足以让开发人员编写所有设备都支持的简洁代码。
第二个问题的答案很简单，片段是 v3.0 的集成部分，如果您希望应用程序仅在 v3.0+ 上运行，那么您实际上不必包含外部库。
【讨论】：
支持库中的片段相当于 Honeycomb+ 的片段。
第二个任务，来自文档：
v13 是 v4 的超集，包括额外的支持类使用 v13 APIs
即相同的功能，只是适应v13 API。
我正在使用修改后的 v4 支持库 - 带有地图。
【讨论】：