咱们都晓得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技术。
对文章有何见解,或者有何技术问题,欢送在评论区一起留言探讨!