Android targetSdkVersion了解一下

先抛出一个问题:
我们的应用开发的时候android最新版本是6.0,当一年过去之后,7.0发布了,那么我们的应用在7.0手机上是否还能运行?会奔溃吗?

根据我们的实际经验,觉得应该不会奔溃,可能有些功能会有问题,但是具体是那一块呢?又说不太好,这就涉及到了Android的向前兼容的问题了。

我们在创建App的时候经常会设置这几个参数

android {
  compileSdkVersion 23
  buildToolsVersion “23.0.1”

  defaultConfig {
    applicationId “com.example.ssy"
    minSdkVersion 16
    targetSdkVersion 23
    versionCode 1
    versionName “1.0”
  }
}

其中著名的就是compileSdkVersion,minSdkVersion,targetSdkVersion。平时这些参数都是自动设置的,我们只需设置minSdkVersion,最低SDK版本,然后compileSdkVersion和targetSdkVersion可能是一致的。这就是我们平时使用AS的时候不注意的问题,平时操作习惯了,但是真的不知道这几个参数是什么意思。

minSdkVersion

最好理解的就是minSdkVersion了,就是我们的app能够运行的最小版本,如果选择16,那么就是Android 4.1 以及以上的设备才能运行我们app,如果小于这个版本,那么抱歉运行不了,我们不支持。这是应用程序支持api的下限。这也是应用商店判断这个应用是否能运行在设备上的一个依据之一。

在开发中也会根据这个下限去判断,是否可以用某个api方法,如果是下限之下的那么就会有警告,避免调用一些在新的版本已经改变或者过时的方法。

当我们引用了第三方的库,如果某几个库的minSdkVersion分别是API5,API10,API16的方法,那么我们的minSdkVersion最少就是16。

对于minSdkVersion的选择,我们应该看各个api的占比,不过因为基数太大了(十几亿)所以就算是0.7%也是个天文数字,所以我们需要根据自己应用的受众,以及是否需要适配低版本的需要,一般说来我们适配4.1以上,即minSdkVersion=16,不过还要根据自己的实际情况,去选择相应的版本号。

compileSdkVersion

compileSdkVersion是我们告诉Gradle,我们是用哪一版本的Android Sdk去编译程序的,可以使用这个版本的API,比如我们使用的是7.0的版本,compileSdkVersion=24,那么我们对于拍照裁剪图片等功能的操作,就可以使用FileProvider了。

我们需要注意的是:我们改变compileSdkVersion的版本号,本质上改变不了我们程序的运行,虽然可能会报错误❌或者警告⚠️,但compileSdkVersion 只会在编译期间起作用,因为环境是compileSdkVersion这个版本的SDK,所以你可以用一些这个版本的API,但是只是IDE给你的便利性帮助而已,帮助你检测代码,避免使用一些弃用的API。就算你用个低版本的compileSdkVersion,你依然可以那么写,但是可能会报错,报警告,但是你强制打包,其实也是没有问题的。IDE只是个工具,他的环境也只是工具的环境,不代表你应用运行时的表现。

所以希望大家用最新的sdk版本作为开发环境,compileSdkVersion设置成最新的,这样我们可以使用到最新SDK的API方法和机制。

如果我们使用了比如V4,V7包,有没有发现必须和compileSdkVersion的版本相匹配,比如我们compileSdkVersion = 26,那么V4,v7的版本也要相应的是26.xx.xx,首位的26必须一致,后两位没有要求,就是说明编译所依赖的SDK和依赖包必须是统一版本,不然两个不兼容,编译会通不过。同时也是为了使用该版本的新特性。

targetSdkVersion

targetSdkVersion是这哥三里面最难以理解的一个了,不过也是最有趣的一个。

targetSdkVersion的含义对于我们来说就有点陌生而熟悉了。

  • 什么是目标设备SDK版本?
  • 是和minSdkVersion相对应的上限吗?
  • 如果我运行在比targetSdkVersion高的设备上,会出现什么?
  • 如果是比targetSdkVersion低的设备呢?

满满的疑问

首先targetSdkVersion是android向前兼容的主要方式,怎么说呢?官方是这样说的:

除非更新targetSdkVersion,否则不改变应用的行为。 这允许您在处理行为更改之前使用新的API(如您更新过的compileSdkVersion)

简单的说就是你的应用已经针对这个版本的手机,做了充分的兼容性处理和测试性处理,比如 if(Build.VERSION.SDK_INT >= 23) { … } ,这样针对不同的SDK版本做不同的处理,这就说明我们不能随便的改变targetSdkVersion得值,我们必须做好充足的兼容性处理和测试处理才行。

在 Android 4.4 (API 19)以后,AlarmManager 的 set() 和 setRepeat() 这两个 API 的行为发生了变化。在 Android 4.4 以前,这两个 API 设置的都是精确的时间,系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒,这两个 API 设置唤醒的时间,系统都对待成不精确的时间,系统只能保证在你设置的时间点之后某个时间唤醒。虽然api的名字没有改变,但是功能结果已经发生改变,我们设置targetSdkVersion为16,Android4.4之前,那么我们在Android4.4之后运行会出现什么呢?难道就不能用了吗?不准确了吗?
当然不是,系统通过targetSdkVersion来保证Android的向前兼容性,在Android4.4之后的设备上,系统会判断你的targetSdkVersion是否小于19,如果小于的话,那就按照19之前的api方法,如果大于等于19,那么就按照之后的api方法来走,保证了程序运行的一致性。也就是向前兼容性。

但是还有一个问题:

Android 6.0新增加了动态权限申请,我们的targetSdkVersion是5.0,如果我们运行在Android 6.0的设备上怎么办?
因为我们这个可以向前兼容,向后不行啊,如果你的代码里处理了Android 6.0的动态权限处理,那么可以的,如果没呢?你想啥呢大哥?更新应用处理呗~~

targetSdkVersion 的大部分更新变化都会记录在VERSION_CODES,所有的细节也会在每个版本的平台亮点写明。

targetSdkVersion保证的是api的一致性。
所以一般minSdkVersion <targetSdkVersion<= compileSdkVersion
不随意更改targetSdkVersion,更改targetSdkVersion必须做好兼容。

Gradle和SDK版本

所以设置正确的compileSdkVersion,minSdkVersion和targetSdkVersion很重要。正如GradleAndroid Studio的世界中的那样,这些值通过包含在我们模块的build.gradle文件中(也可通过Android Studio中的Project Structure选项获得)集成到工具系统中:

android { 
  compileSdkVersion 23
   buildToolsVersion“23.0.1” 

  defaultConfig { 
    applicationId“com.example.ssy” 
    minSdkVersion 7 
    targetSdkVersion 23
     versionCode 1 
    versionName“1.0” 
  } 
}

compileSdkVersion是一个编译时的事情(TMD这谁知道),是与我们的构建工具版本一起使用的Android设置之一。

minSdkVersion和targetSdkVersion不同于compileSdkVersion,因为它们包含在APK中。查看生成的AndroidManifest.xml

<uses-sdk android:targetSdkVersion =“23”android:minSdkVersion =“16”/>

理清楚这些后,下次更改这些参数的时候,就不会犯一些低级错误了。但是其中的更细节的东西,需要看android编译原理和运行原理了,任重而道远,这只是一个结果论。

大家可以点个关注,告诉我大家想要深入探究哪些问题,希望看到哪方面的文章,我可以免费给你写专题文章。。哈哈。。。
希望大家多多支持。。你的一个关注,是我坚持的最大动力。。

    原文作者:猪_队友
    原文地址: https://www.jianshu.com/p/358a3d42196e
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞