问Android支持库是如何工作的？

EN

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

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

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

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

另一个问题出现在这里：

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

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

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

与Android 2.3.x (姜饼)相比，Android 4.0.x (ICS)增加了很多功能。兼容性库的存在是为了弥合那些添加到ICS中的更改，这些更改是由-could支持的。“可能”是这里的关键短语，因为对ICS进行了大量的更改，这些更改永远不会与姜饼一起工作，当然，这些更改也不会获得兼容性库。

例如，您提出的片段实际上在ICS中的处理方式与在兼容库中的处理方式略有不同，因为ICS具有更多可以使用的特性。如果您查看Fragments类的ICS代码，您会发现它们与兼容库中的代码不同。这是一套完整的代码，使得ICS中的片段可以在像姜饼这样的旧版本中使用，而程序员没有注意到太大的区别。

这就是兼容性库的要点，也是为什么它们不能广泛用于修补姜饼以使用ICS中的所有功能的原因(它们就是不能)。兼容性库的要点是将新版本的android中可用的东西进行接口，如ICS，以ICS的方式转换为旧版本，如GB，以GB的方式。

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

这个想法是，你可以只下载你的操作系统的当前API版本支持的应用程序(就Google Play而言)，你可以选择包括支持库，以保持你的应用程序的外观和感觉支持旧的API，这些API还没有你选择在新的API上为那些用户提供的功能。这确实是一种外观和感觉的考虑，而不是其他任何东西。

希望这能把事情弄清楚:)

已经说过的都是真的。尽管有一些细节缺失。事实上，我有机会参加了上一届Google IO的一个会议，他们专门讨论了这一点。事实上，让我感到惊讶的是，支持库并没有托管所有可能的API版本的代码，而是对新功能的改编，他们认为这些新功能足够相关，可以在旧平台上使用。因此，它的工作方式通常如下：

• 假设我们需要使用全新的(可从API 16获得) ConnectivityManager来跟踪网络更改
• 我们包括支持库v4和我们使用的类
• 它的工作方式是系统将检查我们的API版本并将运行内置本机代码，以防我们在API 16中或在任何其他情况下运行支持库的代码。

所以它就像是某种路由网关。原因是，使用针对最新操作系统和最新系统改进(即硬件加速)优化的最新代码通常更有效率(和性能)。

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

归根结底，由于所有这些，建议使用compats库，这是一个好的实践，特别是如果你想让你的应用程序/代码可用于旧版本(这应该是理想的方式)。