Android 构建过程的历史不断变化，开发人员不断尝试使其在构建时间和生成的 .dex 文件大小方面更加高效。因此，纵观历史，从 .java 文件生成 .dex 文件的过程有很多变化。
在 R8 或 D8 之前，Android 构建过程涉及以下四个步骤：
源代码(.java) ---javac---> Java 字节码(.class) ---Proguard---> 优化的Java字节码(.class) ---德克斯---> Dalvik 优化字节码(.dex)
然后，Android 开发人员决定将其间的所有步骤合并为名为 Jack&Jill 的 1 个步骤以进行优化。然而，它于 2015 年引入，并于 2017 年被放弃，因为它不够灵活，无法与所有不断增长的开发工具配合使用。
然后，引入了 D8，它通过优化的 Dex 转换恢复到原始的 4 步构建过程。该实现产生了比 dx 更好质量的字节码，具有更少的指令和更好的寄存器分配。
现在到 R8，它有一个类似的目标，以 Jack&Jill 作为起点，将其中两个构建步骤合并为一个。 Proguard 和 Dex 步骤。因此，R8 不是先 Proguard 处理 .class 文件，再次返回 .class 文件，然后 Dex/D8 处理器接收 .class 并返回 .dex 文件，而是合并这两个步骤，接收 .class 文件，返回 .dex 文件。这个工具仍在变得更好，试图进一步优化构建过程。因此，现在将您的项目迁移到 R8 是明智之举，因为它是一个仍在不断发展的工具，很快将成为默认构建工具。 （可以看出Android Studio(3.4)升级时默认启用）
此外，Google 问题跟踪器中的开发人员很快就返回了有关 R8 的问题报告，因为他们渴望获得反馈并希望完善该工具。
据报道，使用 R8 会生成更小的 .dex 文件，并且可以更有效地缩小删除未使用的类。从某种程度上来说，这是一个优点和缺点。显然，这是一个优点，因为较小的尺寸总是更好（在编程中！），它是一个缺点，因为你必须复杂地检查你的代码，并检测你的入口点并相应地在你的 proguard 文件中重新实现 keep 规则，如 R8 所介绍的比 Proguard 更积极的缩小。
有关更多信息，您可以查看这篇文章，其中包含关于 R8 与 Proguard 的非常详细的解释：https://www.guardsquare.com/en/blog/proguard-and-r8 https://www.guardsquare.com/en/blog/proguard-and-r8
另外，Google I/O 2018 的官方演讲：
希望这可以帮助，
