Android支持库如何工作？

Question

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

所以，我的主要问题是，支持库中的片段库与其在API 11（Android v3.0，Honeycomb）中引入的双胞胎之间的区别是什么。

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

Answer 1

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

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

现在，假设这个支持库功能如此常见，以至于在单个设备上，如果我有10个应用程序，那么至少有9个使用相同的支持库，因此我的设备上使用9 * 2 = 18MB支持库，在每个应用程序中重复，这是不好的，因为现在18MB可能不是那么多，但如果你有更多的应用程序使用该支持库，所需的空间可能会增加。

因此，最好的选择是在您的操作系统中为任意数量的应用程序提供2MB支持库，而不是为每个应用程序提供。因此，当您真正想要在应用程序中使用某些高效功能来支持旧版本时，可以使用支持库。

这里出现了另一个问题：

  

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

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

作为更新，它有可能无法正常工作，或者在与OS集成时可能会导致问题，因为我们已经看到每个操作系统（Windows，Linux，Mac）都带有新版本，而不仅仅是为所有新功能提供终身更新。

Answer 2

与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个应用程序= 4x包括在内）。

我们的想法是，您只能下载操作系统当前API版本支持的应用程序（就Google Play而言），您可以选择包含支持库，以保持旧版支持的应用程序的外观和感觉API，还没有您选择在较新的API上为这些用户提供的功能。这真的是一种外观和感觉，而不是其他任何东西。

希望能够解决问题：）

Answer 3

已经说过的是真的。虽然缺少一些细节。 事实上，我有机会参加他们专门讨论过的最后一次Google IO会议。 实际上令我惊讶的是，我知道支持库没有托管所有可用API版本的代码，而是它们对新功能的改编，他们认为这些功能足以使它们可用于旧平台。所以它的工作方式通常如下：

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

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

尽管如此，仍有一些元素未转换为compat库，因为它们位于本机内置代码中。例如，片段不打算重写，因为它们来自API13，因为它们是一个巨大的组件，需要在系统和功能较少的设备中的各种不同场景中运行。

最终，因为所有这些，建议使用compats库，这是一种很好的做法，特别是如果你打算让你的应用程序/代码可用于旧版本（这应该是理想的方式）

Answer 4

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

  

为什么有两个图书馆？

因为问题的一部分是谷歌只回来移植了一些东西，但我的理解是，另外，由于核心操作系统框架限制和缺少核心缺少API，一些新功能无法反向移植Android UI框架。

Answer 5

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

现在，如果我们想要使用这些功能并且还支持旧版本的android，那么我们将不得不编写高度凌乱的版本相关代码，这并不好。

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

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

Answer 6

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

要从文档中获得第二个任务：

  

v13是v4的超集，包含其他支持类以使用v13 API

即相同的功能，仅适用于v13 API。

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