Android 应用构建

六种 依赖方式，如下所示：

1. implementation/api：对所有的 build type 以及 falvors 编译并且打包到 APK。
2. Provided：对所有的 build type 以及 falvors 只编译，不打包到 APK。
3. APK：只会打包到 APK，不参与编译，比如引用 jar 中的类或者方法, 编译时就会报错。
4. Test implementation/api：仅对单元测试的代码和打包的测试 APK 有效，而对 debug 或者 release APK 包无效。
5. Debug implementation/api：仅对 debug 模式的编译和打包的 debug APK 有效，而对 test 或者 release APK 打包无效。
6. Release implementation/api：仅对 Release 模式的编译和打包的 Release APK 有效，而对 test 或者 debug APK 打包无效。

api和implementation的区别：
api
等同于 compile, 用 api 指令编译，表示 三方库的依赖对 module 是可见的，即等同 app Module 可以使用此三方库依赖。
implementation
特点是 将该依赖隐藏在内部，而不对外部公开。比如在组件化项目中，有一个 app module 和一个 base module，app moudle 引入了 base module。其中 base module 使用 implementation 依赖了 Glide 库，因为 implementation 是内部依赖，所以是无法调用到 Glide 库的功能的。因此 implementation 可 以 对外隐藏不必要的接口，并且，使用它可以有效地 提高编译速度。比如，在组件化项目中一般含有多个 Moudle 模块，如 Module A => Module B => Moudle C, 比如 改动 Moudle C 接口的相关代码，如果使用的是 implementation，这时候编译只需要单独编译 Module B 模块就行，但是如果使用 api 或者旧版本的 compile，由 于Module A 也可以访问到 Moudle C，所以 Module A 部分也需要重新编译。所以，在使用无错的情况下，可以优先使用 implementation。

在 Android Studio 3.5 之后，Android 8.0 以后的设备将会使用新的方案 Apply Changes 去代替 Instant Run**。而 ApplyChange 采用了跟 InstantRun 不一样的原理来加快 AndroidStudio 部署安装 APK 的流程。下面，我们就来了解下他们之间的区别。

InstantRun

InstantRun 主要解决以下两个问题：

• 1、减少构建和部署 app 到手机的时间。
• 2、热更新代码改动，无需重启 app 或者 activity。

为了实现这两个目标，InstantRun 通过重写 apk 的构建流程往每个类里去注入 Hook（钩子） 来达到类的热替换。
对于小型的应用，InstantRun 确实很好用，能够节省构建和部署的时间，并且不会出错。但是，对于大型的复杂应用，它会导致更长的构建时间，同时由于 InstantRun 构建过程和正常的 app 构建存在冲突，常常出现让开发者意想不到的错误。AS 开发团队在连续几个大版本中都尝试去解决这些问题，但是效果不理想。

ApplyChanges

对于 运行在 Android 8.0 或者更新版本上的设备和虚拟机，Android Studio 现在有 三个按钮 来控制应用程序重启的程度：

• Run：会部署所有的改动并重启应用程序。
• Apply Changes：会尝试应用资源和代码的更改，并只重启 Activity， 而不是重启应用程序。
• Apply Code Changes：会尝试应用代码的更改，而不重启任何东西。

通常只有方法体内部的代码更改才会对 Apply Changes 具有兼容性。而 ApplyChanges 的 实现原理 就是找出 AndroidStudio 构建出来的 apk 和已经安装到手机设备 apk 的差异。找出差异后，然后将差异发送到手机上执行差异合并。

---

Android 应用构建速度提升的小技巧：
https://mp.weixin.qq.com/s?__biz=MzAwODY4OTk2Mg%3D%3D&mid=2652050269&idx=1&sn=079e9e84cda81b24ee4446d404276772&scene=45#wechat_redirect