Android设备兼容处理（一）：版本兼容

前言

做Android开发不得不面对的问题，就是该死的设备兼容，从Android1.0到Android7.0，从480P的小屏幕到2K屏，从华为到三星，魅族。我总结了一下，兼容分为四个部分展开：

版本兼容
版本兼容补充：supprt-library
屏幕适配
厂商Rom定制疑难杂症

版本配置

Android版本会不断升级，api也会更新换代，但是放心，api不会无缘无故的删除，一般来说只会有三种情况：新增，废弃，修改。

新增：比如API 11加入的ActionBar，这个就跟minSdkVersion有关
废弃：比如textView的属性singleLine，这个就跟compileSdkVersion有关，如果设为最新版本，那么被废弃的方法就越多（当然不影响正常使用）
修改：就是API名称不变，但是执行效果变了，这个和targetSdkVersion有关
android:minSdkVersion

1.限制用户设备的最低版本号，比如项目中设置android:minSdkVersion 14对应Android4.0，那么这个app安装到低于Android4.0的设备会报错

2.这个属性对app啥影响呢，举个例子：比如checkSelfPermission（检查权限）这个方法是API 23加入的，OK，把compileSdkVersion =23，如果android:minSdkVersion<23，会报错但是不影响编译

image.png

项目成功编译，运行在Android6.0的手机，没问题。
运行在Android4.4的手机，打开直接崩溃，报错信息为：Method NotFound，找不到这个方法，这是Android6.0才加入的方法，运行在Android4.4的系统环境肯定找不到啦。

怎么办呢？ Android官方给出两种解决办法：
第一种，如果这个API对你很重要，费用不可，那么将android:minSdkVersion调到这个API需要的版本吧
第二种，这个API可以不用，或者你有替代办法，那么做sdk版本运行时检查

private void checkPermission(){
        if(Build.VERSION.SDK_INT>=23){
            checkSelfPermission("");
        }else {
             // do something
        }
    }

3.那么实际开发中怎么确定这个属性呢？最佳情况当然越小越好，因为这个数值越大能兼容的设备就越少！但也要看当前Android市场的版本分布，比如现在有90%以上的设备都在Andorid4.0以上，那么设为14，当然如果有新的API项目中非用不可，那这个值直接调整增大即可。

4.还有个问题，比如Android6.0新增了权限判断，我们的项目如果想加入权限判断，难道android:minSdkVersion 要调整为23吗，要是这样的话那没多少用户能装我们的app了！这时候就需要support-library了。

android:compileSdkVersion

这个确定了我们项目当前编译环境的SDK版本，用哪个版本我们当前写代码就是用哪个版本的API，因此Google官方推荐直接设置为最新。不过这个设置也和support－library版本有关，比如我们使用版本为23的Design支持库，那么只能设置为android 23 了！

image.png

需要强调的是修改 compileSdkVersion 不会改变运行时的行为。当你修改了 compileSdkVersion 的时候，可能会出现新的编译警告、编译错误，但新的 compileSdkVersion 不会被包含到 APK 中：它纯粹只是在编译的时候使用。（你真的应该修复这些警告，他们的出现一定是有原因的）

这个属性设置的越大被废弃的方法就越多，当然我们就能最早接触到新增的api。实际开发中compileSdkVersion一般设置为最成熟用户量最多的Android版本，比如现在的6.0或者5.0版本

targetSdkVersion

其实决定兼容性的就是这个属性，意思就是当前apk已经兼容到targetSdkVersion 版本了！举两个例子：

Android 6.0 （APi23）新增了权限控制，但是如果targetSdkVersion ＝ 21, 我们在代码中不需要权限检查，因为targetSdkVersion=21很明确的说了只兼容到Android5.0，app可以正常打开运行。

2 在举个例子： AlarmManager 的 set() 和 setRepeat() 这两个 API 的行为发生了变化。在 Android 4.4 以前，这两个 API 设置的都是精确的时间，系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒，这两个 API 设置唤醒的时间，系统都对待成不精确的时间，系统只能保证在你设置的时间点之后某个时间唤醒。

这个可以在AlarmManager的官网API注释看到，源码中也有根据targetSdkVersion作区分：

image.png

APP 在调用系统 AlarmManager 的 set() 或者 setRepeat() 的时候，系统首先会查一下调用的 targetSdkVersion 信息，如果小于 19，就还是按照老的行为，即精确设置唤醒时间，否者执行新的行为。像这样根据targetSdkVersion做判断的地方，在Android源码中随处可见。

总结

实际开发中一般把这个值设置为android:compileSdkVersion一样，这样看来我们开发的app兼容范围就是：minSdkVersion至targetSdkVersion，那么这三种配置理想情况应该是

minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)

Android设备兼容处理（一）：版本兼容

前言

版本配置

总结

你可能感兴趣的:(Android设备兼容处理（一）：版本兼容)