Booster Architecture Overview

Booster's Architecture Design

Extensibility is the core requirement of Booster's architecture. Through functional modularization, feature development becomes more independent, which also facilitates testing and gradual rollout of features. In addition, the following problems need to be addressed:

1. How to make module development easier?
2. When there are many feature modules, how to ensure build performance?
3. How to resolve open source license conflicts?

To solve these problems effectively, Booster's architecture is designed as shown in the following diagram:

How to Achieve Extensibility?

To achieve dynamic discovery and loading of feature modules, Booster is based on SPI (Service Provider Interface), and simplifies SPI configuration through Google AutoService. Booster provides two main types of SPI:

• Task SPIopen in new window

  Task SPI is used to insert custom tasks into Gradle's Task Graph, for example: booster-task-compression-cwebpopen in new window, booster-task-compression-pngquantopen in new window, etc.

• Transformer SPIopen in new window

  Transformer SPI is used to insert custom Transformers during the Transform process to manipulate bytecode. To accommodate most developers, Booster provides two types of Transformer SPI:

  1. ASM-based ClassTransformeropen in new window
  2. Javassist-based ClassTransformeropen in new window

  Developers can choose to use ASM or Javassist based on their preference.

How to Make Development Easier?

In terms of development experience and convenience, Booster has done the following:

1. Abstracts the Transform process, directly exposing the parsed class file structure to developers;
2. Decouples Transform from Gradle, allowing Booster's Transformer to be reused in non-Gradle projects;
3. Solves the dependency injection problem for external libraries through VariantProcessoropen in new window, making large-scale bytecode injection possible;
4. Starting from AGP 3.0, provides compatibility adaptation for each version of AGP, and abstracts a common Android Gradle APIopen in new window, so developers don't need to worry about differences between AGP versions;
5. Provides a series of utility libraries to improve efficiency in feature module development;

How to Ensure Build Performance?

1. Supports incremental builds

   Both Transform and other Tasks support incremental builds.

2. Single file system I/O

   As can be seen from Booster's source code, the entire Transform process only involves reading and writing the file system once, and all Transformers access the Class structure in memory

3. Transformer Pipeline and parallel Transformers

   The entire Transform process is streamed at the granularity of individual JARs or directories, with each Transformer Pipeline executing in parallel to maximize CPU resource utilization.

4. Parallel disk writing

   Writing classes back to JAR files in parallel.

5. Performance testing

   Benchmark testing of multiple technical solutions through JMH, selecting the optimal performance solution. See: booster-benchmarkopen in new window.

How to Resolve Open Source License Conflicts?

In Booster, besides Task SPIopen in new window and Transform SPIopen in new window, there is another SPI -- Command SPIopen in new window.

Command SPIopen in new window is primarily designed to address the use of GPL License open source software under the Apache License. For example, pngquant uses the GPL License open source license, and using it directly in a project carries certain legal risks. Therefore, Booster's approach is to abstract part of it, dynamically discovering and loading the implementation of Command SPI at runtime in the form of SPI. This way, it ensures the legality of the open source license while still being able to use excellent GPL open source software.