Paul Davies - compiling..... reduce your wait times and “get back to work”

How much of our time do we use up "compiling" or "building". From recent experience on a couple of projects, it seems to be a lot.

Slow build times ruin your flow, and get in your way. I say the performance of your build process is just as important as the performance of the code you are writing. In this talk, I'll discuss the improvements Gradle has provided to give us our time back, and what you can do with your Android team to push your Gradle build to be as fast as you can.

I'll also look at Bazel as an alternative to Gradle, to see if its ready for us "mere mortals", and if its possible to save even more time by switching.

Transcript

1. compiling….. reduce your wait times and “get back to work” Paul Davies rentalcars.com BookingGo (part of Booking.com) @pauldavies83 linkedin.com/in/pauldavies83
2. Who am I • Android software engineer • rentalcars.com app at BookingGo (Booking.com) • Previous life: • BBC iPlayer, BBC iPlayer Radio
3. • Ground transportation division of Booking.com • Manchester, UK • YES, we are hiring :-) • NO, it doesn’t always rain
4. What this talk is... • Our experience at BookingGo with our Android app • My observations gathered from previous roles/apps • A plea for you to care about your build time
5. What this talk isn’t... • A one-size-fits-all answer (sorry!) • Exact numbers
6. What’s “wrong” with Gradle? • It’s “slow”
7. Compiling….. https://xkcd.com /303/
8. What did we start with
9. What we started this year with (Jan 2018) • Gradle v3.5, Android Gradle Plugin v2.3.3 • 1 main app module - 4 small library modules • Java + Kotlin sources • Lots of dependencies, plugins, annotation processors • Clean build ~3 mins 20 secs • Small change in module ~1 min 50 secs
10. What did we try
11. What did we try (Jan 2018) • Move tools to most recent version • Gradle v4.4, AGP v3.0.1 • Enabled parallel tasks • Turned the daemon ON!! • Clean build ~2 mins 25 secs • Small change in module ~1 min 45 secs
12. Why? • CONFIGURATION • Incremental compilation (for Java) • Annotation processors off compile classpath • Compile avoidance (for Java) • Gradle daemon
13. Version bumps
14. What did we try • Gradle v4.4.1, AGP v3.1.2 • Kotlin Gradle Plugin v1.2.21 • Build (-10 secs)
15. Configuration optimizations
16. What did we try • Change ALL PNG resources to WebP • No improvement in build time L • BUT… • Reduced APK size ~5MB J
17. What did we try • Create a dev flavour (remove legacy mutlidex / constrain resources) • Build (- 11 secs)
18. Remove annotation processors
19. What did we try • AutoValue (- 15 secs ) • https://github.com/riclage/ConvertToDataClassPlugin • ButterKnife in .kt files (- 4.5 secs ) • ButterKnife in .java files ( - 5 secs )
20. Build cache
21. Build cache • Turn on Gradle build cache • Build time < 45 seconds (-1 min 40 secs!!)
22. Build cache • Disable Crashlytics on dev variant • Build time < 5 seconds !!!
23. Remote build cache?
24. Remote build cache? • Artifactory (JFrog) has this built in • Gradle provide Docker image • Roll-your own • docs.gradle.org/current/userguide/build_cache.html
25. Can we go even faster?
26. Can we go even faster? • MORE MODULES • More JVM modules / less Android modules • More Kotlin / Less Java
27. Kotlin & Java sources https://jakewharton.com/its-a-kotlin-kotlin-kotlin-world/
28. Can we go even faster? • Change your workflow • Get a faster computer (or use cloud) • https://github.com/gojuno/mainframer • Flutter??? J
29. Tools
30. Tools ./gradlew <task> --profile
31. Tools
32. Tools
33. Tools • Gradle build scan • https://guides.gradle.org/creating-build-scans/
34. Bazel
35. Bazel • Open-source variant of Google’s Blaze • Famed for fast, repeatable builds • Worth a try?
36. Bazel - dependencies • No transitive dependencies with built-in rules • e.g. Retrofit -> OkHttp. Need to specify both • No fun trying to port an Android project! • Open-source rule supporting maven transitive dependencies • Doesn’t support .aar dependencies, only .jar • No fun trying to port an Android project!
37. Bazel - Kotlin • ”Official” rules forked from an open-source project @pubref • “Official” rules support mixed-mode compilation (.kt & .java in one pass). @pubref wouldn’t do this • “Official” rules cannot simply provide its output to an Android application rule (workaround needed)
38. Bazel – my spike experience • Seems difficult at this point to port an existing, complex Android project structure • Bazel IntelliJ plugin doesn’t work in Android Studio 3.1 (but should be fixed in 3.2) • I’ll be really interested in looking again the next time I press File -> New Project!
39. Summary
40. Does all this matter? • How many times do you build each day? • 10 x 3 mins = 30 mins day / 2.5 hrs week • 10 x 0.5 mins = 5 mins day / 25 mins week • Time savings add up • Decide whether savings are worth the cost
41. Summary • Build tools are not fit-and-forget • Gradle isn’t magic - needs configuration and your scripts need maintenance • If you need a nudge/reminder, write it into your CI workflow • Mixing Java & Kotlin means slower builds!
42. Summary • Optimize your work environment • real device instead of an emulator • faster machine / remote build like “mainframer” • ask for a new computer J • Other options (eg Bazel) may be faster in certain circumstances, but not as much support
43. Resources • d.android.com/studio/build/optimize-your-build • docs.gradle.org/current/userguide/troubleshooting.html
44. Resources • Two other great talks from today you to check out…
45. (Less) Compiling….. https://xkcd.com /303/
47. compiling….. reduce your wait times and “get back to work” Paul Davies rentalcars.com BookingGo (part of Booking.com) @pauldavies83 linkedin.com/in/pauldavies83