38

据我所知，支持库正在使用，因为旧设备没有新的 API。例如，他们不知道 Fragment 是什么以及如何实现它。因此，这些行为是在支持库中定义的。

所以，我的主要问题是，支持库中的 Fragment 库与其在 API 11（Android v3.0，Honeycomb）中引入的孪生之间有什么区别。

我的第二个问题是，如果可以将每个新 API 放入支持库中，为什么我们有两种类型的库？我的意思是Android可以在支持库而不是支持库和Android版本X.xx库下发布所有API。

4

6 回答 6

43

据我了解，支持库可以作为内置 API 的替代品，但它们不应该是，因为它们直接影响应用程序的大小。

例如，一个支持库是 2MB，并且要使用它的功能，它需要所有类、资源等（2MB），所以现在classes.dex（应用程序中使用的所有类的 Dalvik 可执行文件）也包括该支持库类，资源也一样。所以，如果没有支持库我的应用程序大小是 1MB，那么现在有了支持库，大小是额外的 2MB，这意味着总共 3MB。

现在，假设这个支持库功能非常普遍，以至于在单个设备上，如果我有 10 个应用程序，那么至少有 9 个正在使用同一个支持库，所以我的设备上的 9*2 = 18MB 被同一个支持库使用，这在每个应用程序中都会重复，这很糟糕，因为现在 18MB 可能不会那么多，但是如果您有更多应用程序使用该支持库，则所需的空间可能会增加。

因此，最好的选择是在您的操作系统中为任意数量的应用程序提供 2MB 支持库，而不是为每个应用程序提供它。因此，当您确实希望应用程序中的一些高效功能支持旧版本时，应该使用支持库。

这里又出现了一个问题：

为什么不将此支持库作为自己的更新添加到操作系统中，以便每个没有大小问题的应用程序都可以访问该功能？

答案是可能有很多错误。假设某些用户没有安装该更新（支持库）......

也有可能作为更新，它可能无法像预期的那样高效，或者在与操作系统集成时可能会导致问题，因为我们已经看到每个操作系统（windows、Linux、mac）都带有新版本，而不仅仅是为所有新功能提供终身更新。

于 2012-08-15T15:48:49.577 回答
13

与 Android 2.3.x (Gingerbread) 相比，Android 4.0.x (ICS) 有很多附加功能。兼容性库用于桥接一些添加到 ICS 的更改，这些更改可能会被 Gingerbread 支持。“可能”是这里的关键短语，因为对 ICS 进行了大量更改，这些更改永远不会与 Gingerbread 一起使用，当然，这些更改不会获得兼容性库。

例如，您提出的片段实际上在 ICS 中与在兼容性库中略有不同，因为 ICS 具有更多可以使用的功能。如果您查看 Fragments 类的 ICS 代码，它们与兼容性库中的代码不同。它是第二组代码，用于使“类似于”ICS 中的片段在像姜饼这样的旧版本中使用，而程序员不会注意到太大的区别。

这就是兼容性库的重点，也是它们不被广泛用于修补 Gingerbread 以使用 ICS 中的所有功能的原因（它们就是不能）。兼容性库的重点是将新版本的android（例如ICS）中可用的东西接口，将ICS方式完成到GB等旧版本中，完成GB方式。

至于为什么他们不只是保持支持库增长并保留相同的基本操作系统 - 答案是兼容性问题。如果用户只有 v4 并且 v12 已出，会发生什么？Android 现在使用操作系统的 Android API 版本作为应用程序兼容性的基础，开发人员可以选择包含支持库（增加应用程序的文件大小，但提供更新的功能）。每个使用支持库的应用程序都独立地包含它们（意味着 4 个应用程序 = 包含 4 倍）。

这个想法是，您只能下载操作系统当前 API 版本支持的应用程序（就 Google Play 而言），并且您可以选择包含支持库以保持您的应用程序的外观和感觉支持旧 API，即还没有您选择在较新的 API 上为这些用户提供的功能。这真的是一个外观和感觉比什么都重要的考虑。

希望这能说明问题 ：）

于 2012-08-17T15:28:45.550 回答
8

已经说过的话是真的。虽然缺少一些细节。事实上，我有机会参加了上次 Google IO 的一个会议，他们专门讨论了这个问题。让我惊讶的是，支持库并未托管所有可能的 API 版本的代码，而是对他们认为足够相关以使其可用于旧平台的新功能的改编。所以它的工作方式一般如下：

  • 假设我们需要使用全新的（可从 API 16 获得）ConnectivityManager 来跟踪网络变化
  • 我们包括支持库 v4 并且我们使用该类
  • 它之后的工作方式是系统将检查我们的 API 版本，并在我们使用 API 16 的情况下运行内置的本机代码，或者在任何其他情况下运行支持库的代码。

所以它就像某种路由网关。原因是使用为最后一个操作系统优化的最后一个代码和最后一个系统改进（即：硬件加速）通常更有效（和执行）。

尽管如此，还是有一些元素没有被翻译到 compat 库，因为它们在本机内置代码中。例如，片段并不打算像 API13 那样重写，因为它们是一个巨大的组件，需要在系统和功能较少的设备中的各种不同场景中运行。

最终，因为所有这些，建议使用被称为良好实践的 compats 库，特别是如果您打算使您的应用程序/代码可用于旧版本（这应该是理想的方式）

于 2012-08-14T21:26:32.810 回答
3

支持库实际上并不包含较新 API 中的所有内容。它确实支持部分 Fragment API，但还不支持 ActionBar。为此，您需要另一个库，例如 ActionBar Sherlock。

为什么有两个库？

因为部分问题是谷歌只向后移植了一些东西，但我的理解是，此外，由于核心操作系统框架的限制和缺少 Android 核心深处的 API，一些新功能无法向后移植用户界面框架。

于 2012-07-25T14:07:58.423 回答
1

Android 在最近的版本中提出了片段和操作栏的很酷的功能。

现在如果我们想使用这些功能并且还支持旧版本的android，那么我们将不得不编写非常混乱的版本依赖代码，这并不好。

为了让我们摆脱所有这些混乱，android 提出了支持库，它不提供对新功能的完全支持，但足以让开发人员编写所有设备都支持的简洁代码。

对第二个问题的回答非常简单，片段是 v3.0 的集成部分，如果您希望应用程序仅在 v3.0+ 上运行，那么您实际上不必包含外部库。

于 2012-08-14T20:59:09.917 回答
-3

支持库中的片段相当于 Honeycomb+ 的片段。

对于第二个任务，来自文档：

v13 是 v4 的超集，包括额外的支持类以使用 v13 API

即相同的功能，只是适应v13 API。

我正在使用修改后的 v4 支持库 - 带有地图。

于 2012-08-14T14:04:59.600 回答