编译SDK版本应低于目标SDK版本吗？

Question

在SO上的绝大多数建议是编译SDK通常应与目标SDK匹配。

• https://dev59.com/E2Af5IYBdhLWcg3wlDYD#27629181

同样，建议将[compileSdk]与您的目标SDK版本匹配。

• https://stackoverflow.com/a/28294447/360211

...CompileSDK（通常等于目标 SDk 版本）版本。

但是明确的 建议 是：

一般来说，您应该针对应用程序可以支持的平台最低版本进行编译。

我以前一直将编译 SDK 与目标 SDK 匹配，但自从阅读了这篇文章后，我意识到我和许多 Stack Overflow 上的答案都是错误的。

我的问题是，使它们匹配有什么危害，或者相反，使用尽可能低的编译 SDK 版本有什么优势？

- weston

Answer 1

在SO上的普遍建议是编译SDK通常应该与目标SDK匹配。但我认为除了新创建的项目，很少有生产Android应用程序会这样配置。

如果让它们匹配有什么害处呢？实际上，让它们匹配或不匹配没有特别的害处。这完全取决于你正在编写什么以及你想要什么行为。

例如，Android 6.0引入了一个新的运行时权限模型，你必须向用户请求危险权限的代码，从WRITE_EXTERNAL_STORAGE到READ_CONTACTS。但是，只有在targetSdkVersion为23或更高版本时才使用此功能。如果你现在无法处理这个代码更改，你可以将targetSdkVersion保持在较低的值，如22。

然而，同时，也许你想使用关键的Android支持库v23版本，比如appcompat-v7。一般来说，你希望你的compileSdkVersion与你正在使用的支持库的主要版本匹配，因为它们可能引用只在那个compileSdkVersion中可用的类、方法、常量等。

因此，在这种情况下，你明确不想让compileSdkVersion与targetSdkVersion匹配。

现在，我个人认为，现在几乎没有优势可以得到最低的compile sdk版本了。

早在2008-2011年，一个普遍（尽管有缺陷）的建议是将 compileSdkVersion 与 minSdkVersion （或者实际上，它们的Eclipse / Ant等价物，因为当时还不存在Android Studio）保持一致。这是因为我们缺乏工具自动告诉我们是否使用了在我们的 compileSdkVersion （比如11）中有效但到我们的 minSdkVersion （比如4）不可用的东西。将这两个值设为相等意味着如果你尝试使用比 minSdkVersion 新的东西，你会得到编译器错误。缺点是您被困于您的 minSdkVersion 的功能集，并且无法逐步增强您的应用程序以利用新设备上可用的更新功能。

现在，构建工具（特别是Lint）会警告您，如果您尝试使用在 compileSdkVersion 中有效但到 minSdkVersion 不可用的内容，因此您知道要放入适当的 Build.VERSION.SDK_INT 检查，以确保您仅在新设备上使用新功能并在旧设备上优雅地降级。

- CommonsWare

---

编译目标的有趣示例。那么你会说安卓文档中的建议可能已经过时了吗？如果你发现你的某个应用程序可以使用较低的SDK进行编译，你会降低编译SDK吗？ - weston

@weston：“那么你会说安卓文档中的建议可能已经过时了吗？”-- 可能是。我更愿意用“明智的人可以有不同的看法”来表达。 “如果你发现你的应用程序可以使用较低的sdk进行编译，你会降低compileSdk吗？”-- 不会。为什么要麻烦自己呢？这只会在以后决定采用更新的东西时增加更多的工作量，而没有明显的收益（至少对我来说是这样）。 - CommonsWare

我的做法一直是针对我关心的最新目标进行编译。因此，新功能已经准备好供我使用。就像你所说的，依赖于lint告诉我有关min以上功能的信息。这是我的逻辑，但是你的第一段话让我对此产生了怀疑，因为你说你希望很少有人像这样配置。为什么？ - weston

我并没有说每个人都像我一样做！但是我在SO上发了两个（还有更多）人推荐相同的方法。所以可以合理地认为这个建议被遵循了。虽然也有反例，但较少见。这使得你的答案和示例非常有用。 - weston

@CommonsWare：也许您对我最初的问题有一些想法，这是问题的起点：https://dev59.com/xo7ea4cB1Zd3GeqPDZp3 - 编译SDK是否可能会影响函数的返回类型，还是永远不可能发生这种情况？ - and_dev