Assembling MultDex (for debug) or assembling with ...

# android

[miha-x64]

Assembling MultDex (for debug) or assembling with ProGuard (for release) are both slow. So ➕ for removing componentN (or annotating getters with @Component(N) as I proposed some time ago, but it stayed just a proposal).
@vovkab Jake Wharton's «Exploring Java Hidden Costs» (mentioned above) is 80% about method count, so you should take a look.
Also, I was shrinking some libraries by removing things that could be removed only with dynamc analysis: unused barcode formats from ZXing (2k -> 200 methods), unused TypeAdapters from Gson (1024 -> about 800..900) (also take a look at Moshi; and don't use Jackson — it's cool but it's 8k methods), unused field converters from ORMLite (I prefer Realm or GreenDao, but it was an already written project); I've upgraded Retrolambda and 500 methods gone.
If some equal lambdas are exist in many classes (poor OO design, but it happens), you can create a Runnable / Callback / Action implementation and e. g. replace postDelayed(() -> swipeRefreshLayout.setRefreshing(false)) with postDelayed(new SetSrlRefreshing(swipeRefreshLayout, false)).
Try avoiding Google services, e. g. you can replace Google location service with standard Android location manager.
If you use Guava or commons-lang3, you can copy several methods and remove whole libraries.
Link to Jake's video and transcription: https://realm.io/news/360andev-jake-wharton-java-hidden-costs-android/