咱们都晓得Activity可作为LifecycleOwner为LiveData的应用提供条件，那么Activity是如何实现LifecycleOwner的呢？
Activity尽管实现了LifecycleOwner接口，然而并没有实现相干解决，而是通过增加一个Fragment来代理Lifecycle的散发。这种通过Fragment代理Activity行为的设计在其余一些库也经常出现，相对来说更加无侵和优雅。
SupportActivity
Activity通过继承SupportActivity实现LifecycleOwner接口。留神在AndroidX中SupportActivity改名为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申明了mLifecycleRegistry对象，然而没有间接应用其进行生命周期的散发，而是被ReportFragment通过activity.getLifecycle()获取应用。
ReportFragment
SupportActivity在onCreate为本人增加了ReportFragment：
@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);
}
// ...
}低版本Activity兼容Lifecycle
SupportActivity是随同Lifecycle才呈现的，android.arch.lifecycle:extensions为晚期还没有继承SupportActivity的Activity也提供了反对，通过LifecycleDispatcher实现ReportFragment的注入：
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);
}
}
}之前还纳闷为什么ReportFragment的实现不写到SupportActivity中去，看到这里终于了解了其存在的意义了吧。
LifecycleDispatcher并不需要在Application中调用，他通过ContentProvider实现初始化
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
@Override
public boolean onCreate() {
LifecycleDispatcher.init(getContext());
ProcessLifecycleOwner.init(getContext());
return true;
}
}在android.arch.lifecycle:extensionsaar的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}占位符，防止authroities抵触。
可见在无侵这件事件上做到了极致，这种无侵的初始化办法十分值得咱们借鉴和应用。
两种Fragment
通过下面剖析，咱们晓得Activity是通过ReportFragment代理了LifecycleOwner的实现。那么在Activity中增加的LifecycleOwner与Activity的Fragment的生命周期是否统一呢？答案是否定的
Android中存在两种Fragment有两种：
- ADK自带的
android.app.Fragment - Support包中的
android.support.v4.app.Fragment（AndroidX也归为此类）
因为前者曾经被@Deprecated，所以当初广泛应用的是后者，也就是Support或者AndroidX的Fragment。而出于低版本兼容性的思考，ReportFragment是前者。
Activity对于两种Fragment生命周期回调的理论并不相同，以onResume和onStart为例，Activity回调的理论如下表：
下面表格中()中的数字示意顺次执行的程序，所以你会发现，sdk fragment的onStart晚于support fragment，而onResume却更早执行
Activity的LifecycleOwner尽管是基于Fragment实现的，然而同一个Activity的LifecycleOwner与Fragment的生命周期回调理论并不统一。
这在咱们的开发重要特备留神，不要视图让Fragment和LifecycleOwner的生命周期中的解决产生时序上的依赖关系。
总结
*通过源码剖析Activity对于LifecycleOwner的实现后，咱们失去以下论断
- Activity不间接调用
HandleLifecycleEvent进行生命周期的散发，而是通过ReportFragment实现 - ReportFragment的注入和过程全程无侵，值得咱们借鉴和学习
- 同一个Activity，其
LifecycleOwner与Fragment的生命周期回调理论并不统一，须要特地留神
Android高级开发零碎进阶笔记、最新面试温习笔记PDF，我的GitHub
文末
您的点赞珍藏就是对我最大的激励！
欢送关注我，分享Android干货，交换Android技术。
对文章有何见解，或者有何技术问题，欢送在评论区一起留言探讨！
发表回复