Copyright notice: we are all adults, hope to indicate the author zhang Shuxin and the original link, thank you for your support!

After reading this article, you will know:

The Android application building process

The process of building an Android application is very complex, as shown in the figure below:

There are mainly the following steps:

  1. The main resource files (layout, values, etc.) are compiled by AAPT and referenced in an R file
  2. Java code is compiled by the Java compiler into JVM bytecode (.class files)
  3. The JVM bytecode is then converted by the dex tool into Dalvik bytecode (.dex files)
  4. These.dex files, compiled resource files, and other resource files (such as images) are then packaged into an APK
  5. Apk files are signed by the debug/release key file before installation
  6. Install to device

A couple of points

  1. The first step in the above steps is to note that the main resource files, some special resource files will not be compiled, such as assets files, files in raw directory and images, will not be compiled. However, files under RAW will generate ids in R files
  2. If the APK is formally signed, you also need to align the APK using the Zipalign tool, which has the benefit of reducing memory overhead when the application is running

As you can see from the introduction above, such a complex build process would be too cruel to be completed manually, so there are various build tools.

Old Android build favorites: Ant, Maven

Before Gradle, Apache Ant and Maven were widely used.

Ant

Ant was released in 2000 and quickly became the most popular build tool for Java projects.

The advantages of Ant are: – Simple, easy to learn, no special preparation is required to get started – procedural programming makes builds very flexible

– Plugins will be supported later.

The downside is that XML is used as a script configuration format, and unless it’s a very small project, its XML files quickly become too large to manage.

Maven

Maven was released in 2004. The goal is to solve some of the problems associated with using Ant.

Maven also uses XML as the file format for the build configuration, but the file structure has changed dramatically:

  • Ant requires the developer to list all the commands needed to execute the task
  • Maven relies on conventions and provides ready – made, callable targets

Not only that, but one of Maven’s more important advances, which revolutionized the way we developed software, was the ability to automatically download dependencies from the network (which Ant later added with Ivy, of course).

Maven’s disadvantages are:

  • Dependency management does not handle conflicts between different versions of the same library file very well (Ivy does this better)
  • XML as a configuration file format has strict structural hierarchies and standards that make it difficult to customize goals

Maven mainly solves dependency management problems, but its mistakes with XML make it difficult to write complex, customized build scripts with Maven, and in large projects, it often has hundreds of lines of code before anything “special” is done, even worse than Ant.

After reflecting on the mistakes of the first two construction tools, the predecessors put forward the concept of DSL (Domain Special Language), aiming at designing a set of languages that can solve domain-specific problems. An example of a successful DSL in this area is Gradle.

New love for Android builds: Gradle

Gradle, launched in 2012, has made many improvements based on the experience of its predecessors.

Gradle’s principle of convention over configuration, which provides default values for Settings and properties, makes it much easier to use than Ant or Maven.

Gradle build scripts are written using DSLS based on Groovy instead of XML (Groovy is a Java virtual Machine based dynamic language that Android developers will look familiar with). This makes build scripts cleaner and more concise than those written with Ant and Maven. Here is a comparison of Maven code and Gradle code for the same purpose:

Gradle combines the power and flexibility of Ant with the dependency management of Maven, plug-in support and ease of use. As a result, it gained widespread attention and was selected by Google as the default build tool for Android Studio in 2013.

Gradle is designed in such a way that it is easy to extend builds and plug into existing build processes. When Google promoted Gradle and Android Studio, the goal was to make it easier to reuse code, build variants, configure, and customize build processes.

Gradle for Android may be concerned about learning Groovy as a new language.

Groovy code is very readable, and if you’ve learned Java, the learning curve isn’t steep. A deeper understanding of Groovy is especially important if you want to build your own tasks and plug-ins.

But because Groovy is Java Virtual Machine based, you can write your own custom plug-ins in Java or any other Java virtual machine based language.

Gradle’s key concepts and build lifecycle

Gradle has two key concepts: projects and tasks.

Each build.gradle build script file represents a project:

Tasks are defined in the build script:

Each build includes at least one project, and each project includes at least one task.

Build life cycle

A Gradle build usually consists of the following three phases:

  1. Initialize the

    • The project instances will be created at this point, if the project has multiple modules, or depends on multiple libraries, all of which have corresponding build.gradle files
  2. configuration

    • In this phase the build script is executed and tasks are created and configured for each project instance
  3. perform

    • At this stage Gradle determines which tasks will be executed based on the configuration of the build script

There can be dependencies between different tasks, so during the configuration phase Gradle produces dependency diagrams, and tasks without dependencies are usually executed first, followed by other tasks. Once a task has been executed, it cannot be executed again.

Gradle Wrapper

Gradle wrappers are provided to ensure that the build is repeatable and compatible with Gradle versions. Gradle wrappers are also provided to ensure that the build is repeatable and compatible with Gradle versions.

The normal Gradle script commands are:

gradle ...
Copy the code

The Gradle Wrapper command simply adds a w to Gradle:

gradlew ...
Copy the code

It is slightly different under Mac:

./gradlew ...
Copy the code

Developers or automated build systems can run gradle commands using wrappers to handle compatibility issues. So we don’t even need to install Gradle, just use gradle Wrapper, as recommended in Android Studio:

I didn’t use wrapper in the image above because when you run gradlew, gradle Wrapper will automatically download the gradle version you need but don’t have and use it. In multi-party collaborations, it is possible that someone else has changed gradle version, uploaded it to Git, and then it takes half a day for you to run your commands.

However, wrappers are still recommended as they are more stable.

conclusion

With Android Studio taking over the market, the build tool Gradle is unsurpassed, and we need to learn and use it to create value for us.

This article gives a general overview of Gradle’s advantages compared to Ant and Maven. After understanding why Gradle is used and what its advantages are, it will help us to further learn how to use Gradle.

Thanks

The Gradle for Android “technologyconversations.com/2014/06/18/… www.kancloud.cn/digest/andr… www.drdobbs.com/jvm/why-bui…