Android-Lifecycle原理解析

Posted 2023-05-09

参考技术A

Event触发的时机：

而在androidx.activity.ComponentActivity和androidx.core.app.ComponentActivity中，该方法的实现，其实都是一样的。

但是这两个Activity，其实都有自己的mLifecycleRegistry对象。

LifecycleRegistry对象其实可以理解为观察者模式中的Observable，也就是被观察者，而LifecycleRegistry对象的创建，其实是传入一个LifecycleOwner实现类对象，而androidx.activity.ComponentActivity和androidx.core.app.ComponentActivity实现了LifecycleOwner接口，所以传入的是this。

LifecycleRegistry中聚合了多个LifecycleObserver，生命周期改变时，通知LifecycleObserver进行相应方法的调用。
在LifecycleRegistry类中的addObserver方法中，其实就是通过封装LifecycleObserver生成了一个ObserverWithState对象，然后放入FastSafeIterableMap中，而FastSafeIterableMap其实就是一个自定义列表，用于保存观察者并且可在遍历期间处理删除/添加。
其实在自定义的某个类去实现LifecycleObserver接口的时候，在activity中，是需要通过getLifecycle().addObserver()进行注册的，这个过程其实就是调用了LifecycleRegistry的addObserver()方法。

ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);会将LifecycleObserver对象封装在ReflectiveGenericLifecycleObserver对象中。但是这里的需要判断是实现了哪个接口，比如androidx.activity.ComponentActivity中的构造函数中，因为是直接new LifecycleEventObserver匿名内部类实现接口对象，则isLifecycleEventObserver为true，就不会new ReflectiveGenericLifecycleObserver()，而在自定义一个类的时候，一般实现LifecycleObserver接口，则就会new ReflectiveGenericLifecycleObserver()

androidx.activity.ComponentActivity的构造函数：这里是new LifecycleEventObserver

自定义的BasePresenter：这里是实现LifecycleObserver接口

所以上面的两种不同的实现，BasePresenter实现的是LifecycleObserver，所以这个LifecycleObserver的最终实现是ReflectiveGenericLifecycleObserver。而ComponentActivity因为是new LifecycleEventObserver，所以这个匿名内部类对象就是最终实现。

在androidx.core.app.ComponentActivity的onCreate方法中，会调用

这里使用ReportFragment，如果是api29以及以上的，则可以直接注册回调来获取Activity的生命周期回调。如果是api29以下的，则需要手动给Activity添加一个空白的Fragment，类似于Glide监听生命周期回调的做法。

LifecycleCallbacks的定义如上，是在ReportFragment中定义的，其实就是使用了Application.ActivityLifecycleCallbacks来实现了。
其实就是在androidx.core.app.ComponentActivity中添加一个ReportFragment，而ReportFragment的生命周期方法，其实都调用了一个dispatch方法。

所以在ReportFragment的生命周期方法，其实就会通过调用对应的dispatch方法进而调用到了Activity的getLifecycle()方法获取到一个LifecycleRegistry对象，然后调用LifecycleRegistry的handleLifecycleEvent()方法。

这里需要事先获取到Activity的下一个生命周期状态，而这个状态过程其实与Fragment的类似，都是先升序，然后再降序的一个过程。即ON_CREATE是CREATED，ON_RESUME是RESUMED，然后ON_PAUSE是变成STARTED

而上面调用的sync()方法，其实其内部会调用两个方法backwardPass()和forwardPass()，一个是逆推，一个是顺推，其实就是可以认为一个是正序，一个是倒序。
比如forwardPass()，其实其内部就是遍历刚才缓存Observer的集合，找到每个Observer

而这里的dispatchEvent，其实就是ObserverWithState的方法，因为ObserverWithState内部封装了LifecycleEventObserver对象，而LifecycleEventObserver对象又是封装了LifecycleObserver对象的。

比如Activity的，其实onStateChanged是在androidx.activity.ComponentActivity的构造器中添加注册的LifecycleEventObserver监听接收对应的处理回调，在这里就会根据是ON_STOP还是ON_DESTROY进行回调的处理，也就是生命周期的处理。
这样的生命周期回调，在自定义类实现LifecycleObserver接口的时候，也可以采用注解的方式注册对应的LifecycleEventObserver监听，这样的生命周期的回调，其实就是回调到对应的注解和事件的方法中。这样是采用了类似于apt注解处理器的方式，生成了对应的java类

这里需要注意，如果是自定义添加监听的时候，是实现了LifecycleEventObserver，那么在分发的时候，调用ObserverWithState的dispatchEvent方法去分发，就会直接回调到了自定义LifecycleEventObserver实现类中的onStateChanged中；而如果是使用LiveData添加观察者的话，则是封装成LifecycleBoundObserver对象，然后通过其onStateChanged方法继续进一步的处理分发，调用到对应的Observer的onChanged方法进行最终的处理

如果这里的分发是分发到上面的那个自定义的BasePresenter，则需要经过ReflectiveGenericLifecycleObserver

从上面的原理解析，可以知道，Lifecycle的生命周期的感知和分发，其实也是依赖于一个ReportFragment，这其实也是一个空的Fragment，这样的做法，其实与Glide的生命周期的监听是类似的做法，都是采用一个空的Fragment来监听生命周期的变化，然后在不同的生命周期做不同的操作。

Spring解析Locale的原理

参考技术A

    org.springframework.context.i18n.LocaleContext是一个接口，只有一个方法getLocale()，就是用来获取当前的Locale的，下面看下整体类图。

    从类图中，我们可以看到LocaleContext有三个子类：其中TimeZoneAwareLocaleContext是一个子接口，该接口提供了一个getTimeZone()方法来获取当前时区了；SimepleLocaleContext是对LocaleContext接口的一个简单实现；主要看下SimpleTimeZoneAwareLocaleContext类，这个类继承了SimpleLocaleContext，实现了TimeZoneAwareLocaleContext接口，这也就说该类可以同时获取Locale和TimeZone，这个类也是我们常用的，看下他的实现：

     整个LocaleContext的设计目的是为了保存了整个应用的Locale和TimeZone。看完下面的LocaleResolver，你就会明白LocaleContext的作用。

    首先看下org.springframework.web.servlet.LocaleResolver的整体类图：

    上面这个类图中有两个主要的接口：org.springframework.web.servlet.LocaleResolver和org.springframework.web.servlet.LocaleContextResolver，这两个接口的设计思想和上面的LocaleContext与TimeZoneLocaleContext是一致的。LocaleResolver接口提供了对Locale操作的两个方法：

    LocaleContextResolver提供了对LocaleContext的两个操作方法：

    从上面的类图中，我们可以看到主要有四个实现类：
    1.org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver
        该实现类相当于LocaleResolver的默认实现，由于它只实现了LocaleResolver接口，因此只能解析Locale，不能设置Locale，该类在DispatcherServlet调用initLocaleResolver()方法的时候，会判断IOC容器中是由有一个叫localeResolver的Bean，如果这个Bean不存在，就会初始化该类作为默认的LocaleResolver。这个类是通过判断HTTP Header中的Accept-Language字段的值来决定当前应用的Locale和TimeZone。

    2.org.springframework.web.servlet.i18n.CookieLocaleResolver
        该类是通过应用设置的Cookie来判断当前需要的Locale的，我们只需要给定CookieName，它会自动读取对应的value，设置Locale。

    3.org.springframework.web.servlet.i18nSessionLocaleResolver
        由名字可知，该类是通过设置Session来实现的，实现原理和CookieLocaleResolver大差不差。

    4.org.springframework.web.servlet.i18n.FixLocaleResolver
        该类从名字就可以知道是一个固定的LocaleResolver，也就是说该类一旦设置了默认的Locale和TimeZone，就不可更改，更改会抛出异常。

     总结一下，常用的是CookieLocaleResolver和SessionLocaleResolver。LocaleResolver的初始化是在DispatcherServlet的initLocaleResolver方法中进行的。
无论是使用哪个实现类，Bean的id一定要申明为localeResolver，否则DIspatcherServlet读取不到，将会初始化默认的AcceptHeaderLocaleResolver。
    其他相关文章：
         java原生国际化
         Spring国际化使用教程
         Spring国际化消息解析原理