Android支持库如何工作？

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

所以，我的主要问题是支持库中的Fragment库与API 11（Android v3.0，Honeycomb）中引入的twin的区别是什么？

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

Answer 1

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

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

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

因此，最好的select是在您的操作系统中为任何数量的应用程序提供2MB支持库，而不是为每个应用程序提供这个支持库。 所以，当你真的想在你的应用程序中使用一些高效的function来支持旧版本时，就需要使用支持库。

另一个问题出现在这里

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

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

我们已经看到每个操作系统（windows，Linux，mac）都带有新的版本，所以作为一个更新，它可能不会像预期的那样有效，或者可能在与OS集成时导致问题。而不是只为所有新function提供生命周期的更新。

Answer 2

Android 4.0.x（ICS）与Android 2.3.x（姜饼）相比有很多附加function。 兼容性库在那里可以弥补一些添加到ICS的变化，这些变化可以被Gingerbread支持。 “可能”是这里的关键词，因为对ICS做了很多改变，这些改变对于姜饼来说是永远不会有用的，当然，这些改变也不会得到一个兼容的库。

例如，你提到的片段实际上在ICS上比在兼容库中略有不同，因为ICS可以使用更多的function。 如果您查看Fragments类的ICS代码，则它们与兼容性库中的代码不同。 它的整个第二套代码，使像ICS碎片一样的东西像Gingerbread旧版本中使用，没有程序员注意到很大的差异。

这是兼容性库的一个重点，也是为什么它们不能广泛地使用Gingerbread来使用ICS中所有的function（他们不能）。 兼容性库的目的是为了在ICS等更新版本的Android中提供可用的接口，以GB方式完成ICS之类的旧版本的GB。

至于为什么他们不只是保持支持库的增长和离开相同的基本操作系统 – 答案是兼容性问题。 如果用户只有v4和v12出来，会发生什么？ Android现在使用操作系统的Android API版本作为应用程序兼容性的基础，开发人员可以select 包含支持库（增加其应用程序的文件大小，但赋予它们更新的function）。 每个使用支持库的应用程序都独立地包含它们（意味着包括4个应用程序= 4x）。

这个想法是，您只能下载当前API版本的操作系统支持的应用程序（就Google Play而言），您可以select包含支持库以保持旧API支持的应用程序的外观和风格，还没有select可用于新API的用户的function。 这真的是一个外观和感觉比什么都重要。

希望这能说明问题 ：）

Answer 3

已经说过了，这是真的。 虽然有一些细节丢失。 实际上，我有机会参加上一次Google IO的会议，他们专门讨论了这个问题。 实际上令我感到惊讶的是，支持库没有托pipe所有可用的API版本的代码，而是改进了他们认为足够相关的新function，以使它们可以在较老的平台上使用。 所以它的工作方式通常如下：

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

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

尽pipe如此，还是有一些元素没有被转换为compat库，因为它们在本地内置代码中。 例如，片段并不意味着要被重写，因为它们是一个庞大的组件，需要在系统和设备中以较less的function运行在各种不同的场景中。

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

Answer 4

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

为什么有两个图书馆？

因为问题的一部分是Google只回收了一些东西，但是我的理解是，另外，由于核心操作系统框架的限制以及Android核心中缺less的API，一些新function无法返回移植UI框架。

Answer 5

Android在最近的发行版中提供了很酷的碎片和操作栏function。

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

为了让我们摆脱这些困境，android想出了一个支持库，它不提供对新function的全面支持，但足以让开发人员编写所有设备上支持的整齐的代码。

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

Answer 6

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

第二个任务，从文档：

v13是v4的超集，并包含额外的支持类，可用于v13 API

即相同的function，只适应v13 API。

我使用修改的v4支持库 – 带有地图。