We all know that Activity can be used as a lifecycle owner to provide conditions for the use of LiveData. How does Activity implement a lifecycle owner?
Although the Activity implements the Lifecycle owner interface, it does not implement related processing, but adds a Fragment to proxy the distribution of Lifecycle. This design of proxy Activity behavior through Fragment often occurs in other libraries, which is relatively more intrusion free and elegant.
SupportActivity
The Activity implements the lifecycle owner interface by inheriting SupportActivity. Note that in Android x, SupportActivity is renamed ComponentActivity
public class SupportActivity extends Activity implements LifecycleOwner {
...
private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
...
@Override
protected void onSaveInstanceState(Bundle outState) {
mLifecycleRegistry.markState(Lifecycle.State.CREATED);
super.onSaveInstanceState(outState);
}
...
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}SupportActivity declares the mlife cycleregistry object, but it is not directly used for lifecycle distribution. Instead, it is passed by ReportFragment through activity Getlifecycle() gets the usage.
ReportFragment
SupportActivity added ReportFragment for itself in onCreate:
@RestrictTo(LIBRARY_GROUP)
public class SupportActivity extends Activity implements LifecycleOwner {
// ...
@Override
@SuppressWarnings("RestrictedApi")
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
}
// ...
}The lower version of Activity is Lifecycle compatible
SupportActivity appears with lifecycle, Android arch. Lifecycle: extensions also provides support for activities that have not inherited SupportActivity in the early stage, and implements the injection of ReportFragment through LifecycleDispatcher:
class LifecycleDispatcher {
static void init(Context context) {
if (sInitialized.getAndSet(true)) {
return;
}
((Application) context.getApplicationContext())
.registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
}
static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
private final FragmentCallback mFragmentCallback;
DispatcherActivityCallback() {
mFragmentCallback = new FragmentCallback();
}
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
if (activity instanceof FragmentActivity) {
((FragmentActivity) activity).getSupportFragmentManager()
.registerFragmentLifecycleCallbacks(mFragmentCallback, true);
}
ReportFragment.injectIfNeededIn(activity);
}
}
}I was wondering why the implementation of ReportFragment was not written in SupportActivity. I finally understand the significance of its existence here.
LifecycleDispatcher does not need to be invoked in Application, and it is initialized through ContentProvider.
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
@Override
public boolean onCreate() {
LifecycleDispatcher.init(getContext());
ProcessLifecycleOwner.init(getContext());
return true;
}
}On Android arch. Lifecycle: extensionsaar is registered in Android Manifest:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="android.arch.lifecycle.extensions" >
<uses-sdk android:minSdkVersion="14" />
<application>
<provider
android:name="android.arch.lifecycle.ProcessLifecycleOwnerInitializer"
android:authorities="${applicationId}.lifecycle-trojan"
android:exported="false"
android:multiprocess="true" />
</application>
</manifest>${applicationId} placeholder to avoid authroities conflicts.
It can be seen that we have achieved the ultimate in non-invasive. This non-invasive initialization method is very worthy of our reference and use.
Two fragments
Through the above analysis, we know that the Activity implements the lifecycle owner through the ReportFragment agent. Is the lifecycle owner added in the Activity consistent with the lifecycle of the Fragment of the Activity? The answer is No
There are two types of fragments in Android:
- ADK comes with Android app. Fragment
- Android in the Support package Support. v4. app. Fragment (AndroidX also falls into this category)
Since the former has been @ Deprecated, the latter is now widely used, that is, Support or AndroidX fragments. For low version compatibility, ReportFragment is the former.
The actual of Activity callback for two Fragment lifecycle callbacks are different. Take onResume and onStart as examples, the actual of Activity callback is as follows:
The numbers in () in the above table indicate the sequence of execution, so you will find that onStart of sdk fragment is later than support fragment, while onResume is earlier
Although the lifecycle owner of an Activity is implemented based on Fragment, the lifecycle owner of the same Activity is actually inconsistent with the lifecycle callback of Fragment.
This is important in our development. Special attention should be paid not to make the processing in the life cycle of Fragment and lifecycle owner have temporal dependencies.
summary
*After analyzing the implementation of lifecycle owner by Activity through the source code, we get the following conclusions
- The Activity does not directly call handlellifecycle event for life cycle distribution, but is implemented through ReportFragment
- The injection and process of ReportFragment are non-invasive, which is worthy of our reference and learning
- The lifecycle owner of the same Activity is actually inconsistent with the lifecycle callback of the Fragment, which needs special attention
Advanced notes of Android advanced development system, latest interview review notes PDF, My GitHub
end of document
Your favorite collection is my greatest encouragement! Welcome to follow me, share Android dry goods and exchange Android technology. If you have any opinions on the article or any technical problems, please leave a message in the comment area for discussion!