jshvarts / AppLifecycleDemo

Uses ProcessLifecycleOwner to react to app coming to foreground and going to background
Apache License 2.0
47 stars 12 forks source link

Determine why kapt for android.arch.lifecycle:compiler is redundant #1

Open jshvarts opened 6 years ago

jshvarts commented 6 years ago

Currently, the build.gradle contains the following lines for android.arch.lifecycle:

// Lifecycle
implementation "android.arch.lifecycle:extensions:$project.archLifecycleVersion"
kapt "android.arch.lifecycle:compiler:$project.archLifecycleVersion"

If the second line (kapt ...) is removed, the app still works and the lifecycle observer annotations are still processed.

https://developer.android.com/topic/libraries/architecture/adding-components.html states that "it's not needed if you are using the DefaultLifecycleObserver from common-java8 artifact."

I don't believe the project uses DefaultLifecycleObserver, at least it cannot resolve in the IDE after the project is built.

GEllickson commented 6 years ago

Hi @jshvarts. Did you ever figure out why the kapt dependency wasn't needed? I've been wondering this myself recently. I had multiple classes in my app using @OnLifecycleEvent annotations that were working without the compiler dependency before I actually realized that was supposedly needed. My guess would be some reflection at some point in the library.

jshvarts commented 6 years ago

Hi @GEllickson,

I have not investigated it further.

GEllickson commented 6 years ago

@jshvarts thanks anyways. Been meaning to dig into the inner working of their code.

mihefan commented 5 years ago

@GEllickson If you use kapt lifecycle-compiler, it will reflect and parse your LifecycleObserver class at compile time to generate a class named xxxx_LifecycleAdapter

If kapt lifecycle-compiler is not used, the reflection operation will take place at runtime, which consumes resources.

Reference to androidx.lifecycle.Lifecycling#getCallback

GEllickson commented 5 years ago

@mihefan thanks for the information. That's pretty interesting how it handles both cases. Seems advisable to use the lifecycle-compiler dependency then.