关于compileSdk与minSdk的技术疑问：使用高版本SDK特性为何能在旧设备运行？

API 探路者

2026-4-8

嘿，这个问题问得特别戳中Android开发新手的痛点——我刚入坑的时候盯着这俩参数看了半天，满脑子都是“这俩到底差在哪？为啥高版本代码能在老机子上跑？”今天就给你掰扯明白：

先搞懂`compileSdk`和`minSdk`到底是干啥的

这俩参数的职责完全是两码事，搞清楚这个，你的疑问就解决了一大半：

compileSdk：编译时的“参考手册”
它只是告诉编译器：“我要基于API 35的标准来写代码哈”，作用是帮你检查代码里有没有用不存在的API（比如你写了个API 35才有的方法，编译器会立刻提醒你），但它不决定你的App在哪个设备上能跑，也不影响运行时的行为。你用compileSdk 35编译，只是拿到了最新的API定义，编译出的字节码还是能在低版本系统上跑的——只要你没瞎调用它没有的方法。
minSdk：App的“最低入场券”
这个才是决定你的App能安装到哪些设备上的关键。设置成24，就意味着只有Android 7.0及以上的设备能装你的App。但它只是限制安装权限，不限制你用高版本API——前提是你得做兼容处理。

那为啥你用了API 35的特性，老设备还不崩？核心靠这两个手段：

版本判断，按需调用
Android系统提供了Build.VERSION.SDK_INT这个常量，你可以用它判断当前设备的系统版本，只在高版本设备上调用新API，老设备就走替代逻辑。比如：
```
// API 35才有的新特性
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
    // 只在API 35+的设备上执行这段代码
    window.setDecorFitsSystemWindows(false)
} else {
    // 老设备用旧的实现或者降级逻辑
    adjustOldSystemWindow()
}
```
老设备运行时，会直接跳过if里的代码，根本不会去碰它没有的方法，自然就不会崩溃。
AndroidX/Jetpack 兼容库的“隐形适配”
很多新特性Google都通过AndroidX库做了封装，这些库会自动在不同版本的系统上用对应的实现。比如你用androidx.core.app.ActivityCompat里的方法，它在API 24的设备上会用兼容的逻辑模拟新特性，在API 35的设备上会直接调用系统原生方法。你用compileSdk 35编译这些库的代码，它会帮你处理好所有版本适配，不用你自己写一堆判断。

这里要纠正一个误区：如果你直接调用了高版本才有的API，又没做任何兼容处理，那老设备运行时一定会崩溃，比如抛出NoSuchMethodError或者ClassNotFoundException。能跑起来的前提，是你要么用了版本判断，要么用了兼容库做了适配。

举个反例：如果你直接写SomeApi35Only.class.getMethod("doSomething").invoke(null)，在API 24的设备上运行肯定会炸——因为这个类在老系统里根本不存在。

所以总结一下：compileSdk只是编译时的工具，minSdk是安装门槛，而向下兼容的关键是你在代码里做了“按需调用”或者用了兼容库，让老设备只执行它能理解的代码~

内容来源于stack exchange