【Android】源码分析Activity如何实现LifecycleOwner
我们都知道可作为为的使用提供条件，那么是如何实现的呢？
虽然实现了接口，但是并没有实现相关处理，而是通过添加一个来代理的分发。这种通过代理行为的设计在其他一些库也经常出现，相对来说更加无侵和优雅。
通过继承实现接口。注意在中改名为
public class SupportActivity extends Activity implements LifecycleOwner {...private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);...@Overrideprotected void onSaveInstanceState(Bundle outState) {mLifecycleRegistry.markState(Lifecycle.State.CREATED);super.onSaveInstanceState(outState);}...@Overridepublic Lifecycle getLifecycle() {return mLifecycleRegistry;}
}
声明了对象，但是没有直接使用其进行生命周期的分发，而是被通过.()获取使用。
在为自己添加了：
@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);}// ...
}
是的静态方法
public static void injectIfNeededIn(Activity activity) {// ProcessLifecycleOwner should always correctly work and some activities may not extend// FragmentActivity from support lib, so we use framework fragments for activitiesandroid.app.FragmentManager manager = activity.getFragmentManager();if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();// Hopefully, we are the first to make a transaction.manager.executePendingTransactions();}}
低版本兼容
是伴随才出现的，.arch.:为早期还没有继承的也提供了支持，通过实现的注入：
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();}@Overridepublic void onActivityCreated(Activity activity, Bundle savedInstanceState) {if (activity instanceof FragmentActivity) {((FragmentActivity) activity).getSupportFragmentManager().registerFragmentLifecycleCallbacks(mFragmentCallback, true);}ReportFragment.injectIfNeededIn(activity);}}
}
之前还疑惑为什么的实现不写到中去，看到这里终于理解了其存在的意义了吧。
并不需要在中调用，他通过实现初始化
public class ProcessLifecycleOwnerInitializer extends ContentProvider {@Overridepublic boolean onCreate() {LifecycleDispatcher.init(getContext());ProcessLifecycleOwner.init(getContext());return true;}
}
在.arch.:的中注册：
<manifest xmlns:android="http://schemas.android.com/apk/res/android"package="android.arch.lifecycle.extensions" ><uses-sdk android:minSdkVersion="14" /><application><providerandroid:name="android.arch.lifecycle.ProcessLifecycleOwnerInitializer"android:authorities="${applicationId}.lifecycle-trojan"android:exported="false"android:multiprocess="true" />application>manifest>
${}占位符，避免冲突。
可见在无侵这件事情上做到了极致，这种无侵的初始化方法非常值得我们借鉴和使用。
两种
通过上面分析，我们知道是通过代理了的实现。那么在中添加的与的的生命周期是否一致呢？答案是否定的
中存在两种有两种：
由于前者已经被@，所以现在普遍使用的是后者，也就是或者的。而出于低版本兼容性的考虑，是前者。
对于两种生命周期回调的实际并不相同，以和为例，回调的实际如下表：
adk
.(2)
.(3)
.(1)
.(4)
上面表格中（）中的数字表示依次执行的顺序，所以你会发现，adk 的晚于 ，而确更早执行
的虽然是基于实现的，但是同一个的与的生命周期回调实际并不一致。
这在我们的开发重要特备注意，不要视图让和的生命周期中的处理产生时序上的依赖关系。
总结
通过源码分析对于的实现后，我们得到以下结论
