当前位置:   article > 正文

android support支持库,以及V4 V7重复依赖研究等_android.support.v4依赖

android.support.v4依赖

转载:彻底弄清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.为了支持不同形态的设备
通过使用支持包来在不同形态设备上提供功能,如手机、电视、可穿戴设备等。

support-library支持库

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

    implemention 'com.android.support:support-v4:21.0.3'

同步gradle之后,在ExternalLibrarys右键v4选择:library propertity查看依赖库的信息:

在这里插入图片描述
V4依赖的包就在sdk的extras目录(V7,V13等都在sdk/extras/android/m2repository/com/android/support包下的目录下)
在这里插入图片描述
上面的包是通过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

implemention 'com.android.support:support-v7:21.0.3'`
  • 1

Multidex Support Library

当你的项目代码量越来越大的时候,会发现某一天运行在Android5.0以下的手机莫名崩溃。报错:某个类class not found,而这个类明明就有啊。。。其实这就是 著名的方法数超过 64K 的应用异常。解决办法就是这个支持库。

android {
    defaultConfig {
        ...
        minSdkVersion 15 
        targetSdkVersion 26
        multiDexEnabled true
    }
    ...
}

dependencies {
  implemention 'com.android.support:multidex:1.0.1'
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

然后在自定义的Applitation的方法中初始化:

@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    MultiDex.install(this);
}
  • 1
  • 2
  • 3
  • 4
  • 5

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'
}
  • 1
  • 2
  • 3
  • 4

看下项目目前的依赖包情况:

在这里插入图片描述
果然,项目自动引入了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
  • 1
  • 2
  • 3
  • 4

即使同时引入不同版本的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’
    }

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家自动化/article/detail/445098
推荐阅读
相关标签
  

闽ICP备14008679号