Analyzing Gradle’s Scheduling Mechanism to Optimize Android Component Publishing

Many large Android projects use an AAR‑based containerization framework to speed up compilation, but some teams (e.g., ByteDance’s Feishu project with over 200 modules) encounter compilation times of 1‑4 hours and occasional “freezes” on high‑end machines.

The root cause is explored through systematic debugging, focusing on Gradle’s internal scheduling rather than memory or simple task anomalies.

Initial hypotheses considered abnormal tasks, memory limits, and concurrency levels. Experiments showed that increasing JVM heap from 9 GB to 40 GB did not noticeably improve build time, while the longest‑running tasks consistently pointed to VerifyLibraryResources .

Further profiling with jstack revealed that most Gradle threads were in WAITING or BLOCKED states, despite the console indicating many active tasks.

Reducing max‑workers from the default (CPU core count) to a small number (e.g., 2) unexpectedly reduced total build time from >30 minutes to ~30 minutes, demonstrating that lower concurrency can be faster due to reduced lock contention.

Gradle’s scheduling works on a DAG of projects and tasks, executing tasks in topological order while respecting two key principles: (1) tasks must run in a valid order, and (2) parallelism should exploit multi‑core CPUs. However, Gradle enforces a rule that tasks belonging to the same project cannot run concurrently because they share mutable project state.

To achieve parallelism within a project, Gradle provides the Worker API . Tasks submit WorkItem s to a shared thread pool; the task thread releases the project lock and waits for the work item to finish. This design improves concurrency but introduces additional lock acquisition, token (WorkLease) management, and frequent notifyAll calls.

Profiling showed that massive numbers of tiny work items (thousands per task) cause severe lock contention and thread‑switch overhead, inflating the apparent execution time of tasks like VerifyResources . The measured task duration includes time spent waiting for locks, leading to misleading “slow task” reports.

By replacing the default work executor with a custom thread‑pool and disabling the Worker API for problematic tasks, the team reduced the overall build time from 45 min 26 s to 2 min 58 s (≈15× faster) and eliminated the top‑10 slow tasks.

Key takeaways: (1) Lowering concurrency can reduce lock contention and improve build speed; (2) Gradle’s timing hooks may over‑estimate task duration when Worker API is heavily used; (3) Precise instrumentation of each task phase is essential for accurate performance analysis.

For reference, the simple test case used in the article is:

finalTask.dependsOn(task1, task2)

task1.doLast { Thread.sleep(4000) }

task2.doLast { Thread.sleep(2000) }

./gradlew finalTask

The output confirms that all three tasks run sequentially on a single thread, illustrating Gradle’s per‑project serialization rule.

Further details, diagrams, and raw data are provided in the original article, along with links to Gradle’s Worker API documentation and a discussion thread about the removal of ParallelizableTask in Gradle 4.0.