彻底弄清support支持库，以及v4 v7重复依赖问题深究
本文作者
作者：08_carmelo
链接：
https://www.jianshu.com/p/f769ea6db2c1
本文由作者授权发布。
众所周知android提供了很多Support Library作为api的补充，常见的有supprt-v4，v7等，但我发现这些支持库的版本众多，涉及的内容也比较庞杂，本文带大家梳理一下常见的Support Library，然后文章后半部分对一个报错问题展开深究，那就是我们用开源库时经常碰到的v4重复依赖问题：DexException Multiple dex files define。
google为啥要弄这么多支持库，直接放到sdk里面不好么？ 参阅官方文档有下面3个原因：
1.向后兼容
如，我们开的App需要支持的minSdkVersion=9，targetSdkVersion=11，在程序里使用了android 3.0 (API level 11)提供的ActionBar类，使用compileSdkVersion=11成功编译出apk。在android 3.0的设备上完美运行，但是app在android 2.3的设备就会crash，报找不到ActionBar的错误。这很好理解，因为旧版本上没有新版本里新增的类。
为了避免使用了最新功能开发的app只能在最新系统的设备上运行的尴尬，官方把新版系统framework中新增加的接口提出来放到了Android Support Library（支持包）中，开发者在遇到上面的情况时，就可以使用支持包中具有同样功能的ActionBar类，这个支持包会打包进App里，这样使用了新版本系统上功能的App也可以向后兼容以前的老系统版本设备了。
使用支持包中的类除了让我们免于判断App运行的系统版本外，还可以使App在各个版本保持同样的用户体验。如在5.0以下系统使用material design。
2.提供不适合打包进framework的功能
Android官方对App开发提供了推荐设计，希望Android应用都有相对一致的交互设计来减少用户的使用成本，希望三方App类似系统应用从而完美融入到Android生态系统中。但是这都仅仅是推荐，不要求开发者一定要这样，如果有这种需求就可以使用官方支持包提供的这些功能，避免重复造轮子。如支持包中的DrawerLayout、Snackbar等类都是这种情况。
3.为了支持不同形态的设备
通过使用支持包来在不同形态设备上提供功能，如手机、电视、可穿戴设备等。
Android 支持库提供了诸多未内置于框架的功能。这些库提供向后兼容版本的新功能、框架中未包含的实用 UI 元素，以及应用可以利用的一系列实用程序。
比如Material Design是Android 5.0加入的新功能，但是很多设备依然装的是Android4.0系统，如果为了Material Design将minSdkVersion设置为 api21显然不合理的，那为了Android5.0以下的设备可以使用Material Design的效果，就应该使用support-library，包括之前的Fragment和现在的权限检查，都是这个原理！
目前为止Android Support Library包含的依赖包有：比较常用的是1，2，3
support－v4
v4名称是最开始支持api level4的库，官方在Support Library 24.2.0版本的时候移除了对Android 2.2(API Level 8)及以下版本的支持，所以从Android Support Library 24.2.0开始，V4包支持的最低版本是Android 2.3即API Level 9)，并且把v4库拆分成5个部分，可以在项目中按需要引用，但是必要性不是很大，一是因为这5个部分有依赖关系，二是compat库占了v4库的一半大小，v4库的依赖关系图：
比如下面这些都是v4包的内容：
Fragment:一个专为解决Android碎片化的类，通过它可以让同一个程序适配不同的屏幕。
NotificationCompat:支持更丰富的通知形式；
LocalBroadcastManager:适合于应用内的消息传递。
ViewPager:一个可以管理子view的viewgroup，用户可以在各个view之间自由切换，这个在很多应用中都有使用到；
上面说到v4是兼容level9之前的版本，那如果我们的compileSdkVersion>9是不是可以不用v4了？ 这个不一定的，比如ViewPager这个类只在V4包中才有，在sdk中没有。
如何使用v4
compile 'com.android.support:support-v4:21.0.3'
同步gradle之后，在ExternalLibrarys右键v4选择：library propertity查看依赖库的信息：
可以看到我们依赖的v4包就在sdk的extras目录：
这个是我们在androidStudio的SDK Manager中下载的，如果没有下载gradle同步后会让你去下载。
support-v7
V7和V4一样，同样包含多个依赖包，但和V4不同的是，V7下的多个子包并不是后面拆分开来的，而是最初发布时就以各个独立库的形式发布的。
它是针对Android 2.3(API Level 9)及以上的版本谷歌提供了一系列的support包（和V4包的命名一样，V7最初支持的最低版本是Android 2.1即API Level 7，所以称其为V7，同样在Android Support Library 24.2.0将V7支持的最低版本改为Android 2.3即API Level 9了），这些support包各自对应着特定的功能，每一个都可以单独地被引用。
v7 app-compat这个包支持对Action Bar接口的设计模式、Material Design接口的实现等，核心类有ActionBar、AppCompatActivity、AppCompatDialog、ShareActionProvider等
如何使用v7
compile 'com.android.support:appcompat-v7:24.2.1'
用这个maven方式配置v7会自动引入v4库，so不需要再额外引入v4库了。
gradle中jar依赖语句格式如 compile 'jar文件组（group/命名空间）:jar文件名（name）:jar文件版本（version）'。所以上面的语句意思是依赖Android支持库中第24.2.1版的appcompat-v7库。
Multidex Support Library
当你的项目代码量越来越大的时候，会发现某一天运行在Android5.0以下的手机莫名崩溃。报错：某个类class not found，而这个类明明就有啊。。。其实这就是 著名的方法数超过 64K 的应用异常。解决办法就是这个支持库。
android {
defaultConfig {
...
minSdkVersion 15
targetSdkVersion 26
multiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.1'
}
然后在自定义的Application的加入：
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
v4 supportLibrary重复依赖深究
下面详细介绍 很常见的v4库的重复依赖问题，先抛出两个问题：
v7包含v4吗？
为啥问这个问题，源于我看网上很多文章，介绍v4的时候不假思索地下结论：v7包含v4！真的是这样吗？？？
我们打开v7的jar包看源码，其实appcompat-v7包本身是不包含v4的jar包的：
新建一个工程，加入v7的依赖包：
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:24.2.1'
}
看下项目目前的依赖包情况：
果然，项目自动引入了v4下面的所有包，v7包涵v4的意思是：
compile 'com.android.support:appcompat-v7:24.2.1'， gradle会自动加入所有v4包的依赖，并且是和v7相同的版本
support库必须和compileVersion一致吗？
不是必须的。只是官方建议保持一致，如果版本不一致仍然可以编译运行。
v4包的重复依赖问题
上面已经证明依赖v7包会自动引入v4包，那么在项目中同时依赖v4和v7，会出现所谓的重复依赖编译报错吗？
可以成功编译运行安装，没有报错：
:mylibrary:preDebugUnitTestBuild UP-TO-DATE
:mylibrary:prepareDebugUnitTestDependencies
BUILD SUCCESSFUL
Total time: 7.005 secs
即使同时引入不同版本的v4包，也并没有出现包依赖重复的报错，可以正常编译运行：（注：红线是版本和compileSdkVersion不一致导致，此处忽略）
确实引入了不同版本的v4包：
结论： 如果都是maven的方式引入v4包，gradle会自动选择版本较高的，比如这里的21.0.3版本，不会导致冲突。
接下来，试试maven引入21.0.3的v4包，然后本地引入19.1.0的jar包：
运行时报错: dex文件冲突
当然，如果lib放入的和maven配置v4包版本21.0.3相同，是可以的。
（Android从support-20.0.0版本开始，v4的jar包全部升级为aar包），解压工具提取aar里面的classes.jar然后重命名为support-v4-21.0.3.jar放入lib文件夹
结论：v4的依赖冲突其实是不同版本v4的冲突，并且是本地lib和maven引入不同版本才会冲突
异常冲突解决办法
一个项目往往要引入很多开源库，试图统一所有moduler的v4版本是不现实的，只能通过exclude 方法过滤某些库的v4包，保证整个项目只引入一个版本。
1. 首先查看当前项目各种库的依赖情况：
2. 找到里面版本冲突的依赖库，然后查找app项目，开源库的lib目录，删除对应的jar包改用maven形式引入。
3. 如果你的app必须要使用本地lib引入v4库，那么就排除开源库的v4包：
compile('com.facebook.fresco:fresco:0.10.0') {
exclude module: 'support-v4'
}
如果是源码形式引入的开源库：
compile (project(':thirdpart:RecyclerViewAdapterLibrary')){
exclude group: 'com.android.support'
}
推荐阅读：
如果你想要跟大家分享你的文章，欢迎投稿~