Android Studio 依赖方式 implementation 与 compile(API dependency)的区别

本文介绍了Android Studio 3.0以后的依赖管理变化,包括compile到api的转变及implementation的概念,对比了implementation与compile的不同之处,并提供了迁移建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言

android studio 3.0 版本之前,第三方库或者module的依赖方式有compile、implementation。android studio 3.0 版本之后,compile被取代,改用API dependency,实质完全等同于compile。

implement

概念 : 将该依赖隐藏在内部,而不对外部公开。

理解 : 在 app mudule 中使用 implement 依赖的第三方库, 在其他 mudule 是无法调用的.

举例 : 此时项目中有一个 mudule 是 ImageLoader ,其内部用 implement 指令依赖了 glide 这个库, 那么此时我们在 app mudule 中无法调用 glide 库中的方法.

compile

概念: android studio 3.0 版本后废弃该指令 改用 api 代替, api 完全等同于之前的 compile 指令, 也就是普通的依赖, 第三方库在 mudule 中依赖后其他 mudule 都可以使用该库.

官方推荐在不影响的前提下优先使用 implement 指令依赖.

compile-->api 

对比Implementation 变化 & compile 变化 :

Implementation 变化 

当本module依赖的ib(也可以是module)发生变化时,由于本module对外暴露的接口并不发生变化,在构建工程时gradle将会只重新编译本module,所有依赖于本module的module并不会发生编译。这种情况是没什么问题的。如图所示。


compile 变化 

当本module依赖的lib(也可以是module)发生变化时,本module向外暴露的接口发生了变化,那么所有直接依赖于本module的module将不得不重新编译。


接下来,这些上层module可能通过其本身的接口对外暴露了底层module的部分内容,即意味着本module暴露的接口也发生了变化,这会使得依赖于上层module的上上层module也需要重新编译。这就导致了一个连锁效应,因此,为了绝对的安全起见,gradle将不得不重新编译整个工程,使得编译时间变得较长。如图所示。


那么重点来了:一点代码的改动可能会引起整个工程的重新编译,这将是多么悲催,而实际上我们之前的gradle插件2.0版本系列的确如此,根本原因就是gradle压根不知道暴露的接口可以通过一个接一个的依赖传递影响整个工程。

  • Android Gradle plugin 3.0带来了解决方案 
    最新版的Gradle plugin需要你指出一个module的接口是否对外暴露其依赖lib的接口。基于此,可以让项目构建时,gradle可以判断哪个需要重新编译。因此,老版本的构建关键字compile被废弃了,而是改成了这两个:
  • api:同compile作用一样,即认为本module将会泄露其依赖的module的内容。
  • implementation:本module不会通过自身的接口向外部暴露其依赖module的内容。 
    由此,我们可以明确的告诉gradle去重新编译一个module,若是这个使用的module的接口发生变化的话。
  • dependencies {
    //当legofy接口发生变化时,需要重新编译本module以及所有使用本module的module
    api project(':legofy') 
    // 仅当landscapevideocamera发生变化时,重新编译本module
    implementation project(':landscapevideocamera:1.0.0')
    }

  • 迁移指南 
    理论上,你可以将原来工程中的compile完全替换为现在的api,但是一旦依赖发生变化,将会使所有的module重新编译,造成编译过长。

所以更好的方式就是使用implementation来进行依赖,这会大大改善工程的构建时间。只有你明确要向外部暴露所依赖lib的接口时,才需要使用api依赖,整体来说,会减少很多重新编译。这一点,在官方指南中说的比较明确。


在最新版的Android Studio中,如果你需要处理应用中超过65K方法数的限制(即单dex文件大小上限),可以添加多Dex支持(Multidex)。以下是步骤: 1. **打开项目设置**: 打开项目结构 (Project Structure) 或者右键点击 `app` 根目录,选择 "Structure" -> "App Modules"。 2. **进入模块配置**: 在打开的模块配置窗口中,找到 "Modules" 部分,选择 "app",然后点击 "+" 号,在 "Dependencies" 区域下方添加 "Library Dependency"。 3. **搜索并选择Multidex库**: 在弹出的搜索框里输入 "Multidex",从搜索结果中找到 "androidx.multidex:multidex" 或 "com.android.support:multidex" (取决于你是否使用了AndroidX),选中它并添加到 "Implementation" 或 "Compile" 部分。 4. **配置MultiDexApplication**: 在 `app/src/main/java/your_package_name/App.java` 文件中(假设为`YourAppNameActivity extends AppCompatActivity`),将`AppCompatActivity`替换为`MultiDexApplication`提供的子类,例如`MultiDexApplicationCompat`。 5. **更新build.gradle**(Module: app): 添加 Multidex 插件,并配置 multidexEnabled 为 true: ```groovy apply plugin: 'com.android.application' // ... defaultConfig { multiDexEnabled true } // ... dependencies { implementation 'androidx.multidex:multidex:2.0.1' // 或者 com.android.support:multidex // 其他应用依赖 } ``` 6. **运行时启动MultiDex**: 在你的主入口 Activity 中,加入 MultiDex 的初始化代码,通常在 `onCreate()` 方法之前: ```java if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { MultiDex.install(this); } super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ``` 完成以上步骤后,你的应用就可以利用多Dex功能了。记得检查 Gradle 构建过程是否有错误,以及在设备上测试应用性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值