minSdkVersion、API level 以及兼容包appcompat三者之间的关系

1、minSDK与API

minSDK: 该应用能够运行的最低版本的SDK是多少。

API level: 每个API有它被引入android SDK的时间，也就是对应的SDK版本,自此SDK版本以上才能使用该API


比如说某应用APK使用API： funA ，且funA被引入的版本为7，那么只有7以后的SDK才能使用该API。
然后这个APK运行的SDK平台一定要大于这个funA被引入的SDK版本7，minSDK也是我们的这个APK要能够运行的平台，所以minSDK一定要大于等于7。

综上： 在确定了最小SDK版本的情况下，如何选择使用API：要符合以下公式，即： API_Level <= minSDK （即要选择使用那些被引入的版本低于minSDK 的API）

那么问题来了，我们在高版本平台下build，我们不可能只用那些低版本的API吧，高版本才有的api和特性怎么办？

答案： 兼容包。

2、minSDK与兼容包

为了兼容低版本的SDK平台运行高版本平台编译出来的apk,需要使用兼容包，有了兼容包就可以在低版本平台运行该apk，并使用一些高版本才有的特性，
但是问题来了，该apk如何选择api？是使用高版本的api还是使用低版本的api，还是使用兼容包的api？ （对于API的概念和特性的概念感觉有点混乱了，这里只讲概念，就不区分了）


我的理解是： 一些低版本不支持或者低版本与高版本功能不一致的api或者特性组件，要使用兼容库的api，兼容库的api既可以运行在高版本平台也可以运行在低版本平台，
而对于一些低版本已经支持，到高版本功能仍然没有变化的api，那就使用这个通用的api。


比如默认生成的apk demo工程：


A: 当我们选择的minSDK和targetSDK是一致的时候，这个时候默认使用的组件是Activity，工程里面不包含兼容包。
B: 而当minSDK比较低的时候，那么意思就是说要兼容低版本SDK平台，这个时候
默认生成的工程中就会包含兼容包V7,而这个时候默认使用的组件就是ActionBarActivity，而不是Activity，这是为什么呢？


首先，Activity这个组件很早就有了，我查看api文档，在level 1就已经被引入，所以为什么不使用Activity呢？
答案是：我们这个默认生成的工程，要使用Activity的ActionBar特性，而这个特性在早期的SDK版本（比如说minSDK）中的Activity还不支持，
所以这个时候如果仍然使用Activity就不能达到和前一种工程一样的效果，不能够使用ActionBar特性，这个时候就需要发挥兼容包的作用了，
ActionBarActivity是兼容包v7或者v4中的组件，我猜想兼容包中利用低版本SDK的api重新实现了和高版本类似的功能，
然后起名字叫ActionBarActivity，而低版本的API显然也是能够在高版本平台上运行的，所以就达到了兼容的目的！