Reduce Glide setup time

[sjudd]

Currently it seems like it can take up to 30ms. We should consider ways to reduce that time or at least allow ModelLoaders to be registered lazily. Branching from @TWiStErRob in #295:

Normal startup (5 samples):
TIMING﹕ Glide.get: 15.87, Glide.register: 0.09, new Client: 0.70, new Factory: 0.12
TIMING﹕ Glide.get: 16.60, Glide.register: 0.09, new Client: 0.76, new Factory: 0.15
TIMING﹕ Glide.get: 20.78, Glide.register: 0.12, new Client: 1.10, new Factory: 0.21
TIMING﹕ Glide.get: 23.38, Glide.register: 0.12, new Client: 1.07, new Factory: 0.21
TIMING﹕ Glide.get: 31.86, Glide.register: 0.18, new Client: 5.16, new Factory: 0.34

with Start Method Tracing:
TIMING﹕ Glide.get: 64.97, Glide.register: 0.82, new Client: 2.47, new Factory: 0.40

[TWiStErRob]

77% is spent loading classes and the rest is mostly the lot of news

The problem is that you need everything ready when you start to load the first image, i.e. the first occurrence of Glide.with. Which means that if the first activity loads an image with Glide, it's going to set things up anyway, even if lazy. I'm curious what's your idea to tackle this?

Just throwing it in: the GlideBuilder could make sure setup is delayed, but since Glide is kind of mutable (un/register) the builder may don't have the right cause to exist.

[sjudd]

My thought is just that Glide shouldn't contribute to delaying cold start times. Even though apps would still have to pay the price when they load the first image, many apps will be able to show some content before or while loading images.

By avoiding the class loader penalty until the first image load, we let apps get past the blank loading screen faster.

[bubbleguuum]

30ms is really not much and perfectly acceptable IMHO

[sjudd]

We have a plan to make this and initializing Glide in general easier. We will add an interface that looks something like this:

public interface GlideModule {
    void initialize(Context context, Glide glide);
}

Users of the library can implement that module, and then add a metadata tag to their AndroidManifest.xml containing the fully qualified class name of their implementation`:

<meta-data
    android:name="glidemodule:com.bumptech.glide.samples.flickr.FlickrGlideModule"
    android:value="" />

When the Glide singleton is first created, it can read the metadata tag, use reflection to instantiate the module, and call initialize. Since both reading the metadata and the reflection happen only on the first Glide.with() call, the overhead should be minimal.

Using this strategy avoids the requirement that users call Glide.get() eagerly in their application and/or activities when they want to register components, which provides two benefits:

1. Cold start times are reduced
2. There is no longer any need to subclass Application.
3. Races where an image load starts on a background thread before components are registered are no longer possible.

The only caveat is that users will need to add their implementation of the module to their proguard config so it isn't stripped out.