1. Utilizar
El marco de ciclo de vida se utiliza para percibir que los componentes realizan operaciones en respuesta a cambios en el estado del ciclo de vida de otro componente (como Actividad y Fragmento). Estos componentes le ayudan a generar código que es más fácil de organizar y, a menudo, más ligero, que es más fácil de mantener.
Por ejemplo:
si necesita hacer algún procesamiento en el ciclo de vida de Actividad o Fragmento:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
presenter.onCreate()
}
override fun onStart(){
super.onStart()
presenter.onStart()
}
...
override fun onDestroy(){
super.onDestroy()
presenter.onDestroy()
}
Este método de escritura necesita llamar al método correspondiente del presentador en la función de ciclo de vida correspondiente de la Actividad o Fragmento. Este método de escritura es relativamente pesado, no lo suficientemente ligero y no desacopla al presentador y la Actividad. La aparición del ciclo de vida resuelve esto problema.
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
lifecycle.addObserver(Presenter())
}
}
class Presenter():LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
fun onCreate(){
println("presenter oncreate")
}
@OnLifecycleEvent(Lifecycle.Event.ON_START)
fun onStart(){
println("presenter onstart")
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun onResumse(){
println("presenter on resume")
}
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
fun onPause(){
println("presenter on pause")
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
fun onStop(){
println("presenter on stop")
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
fun onDestroy(){
println("presenter on destroy")
}
De esta manera, la relación entre Presentador y Actividad pasa de una relación de asociación a una relación de dependencia, lo que reduce el acoplamiento. Al mismo tiempo, el Presentador ahora también puede ser utilizado para percibir el ciclo de vida correspondiente de la Actividad, sin llamar al Método de presentador en la función de ciclo de vida de la actividad.
2. Análisis
2.1 Modo de observador
A través de los nombres de las interfaces y métodos, puede encontrar que todo el ciclo de vida es en realidad un patrón de observador. El siguiente es un diagrama de clases UML del patrón de observador.
Entonces, ¿cómo se ve duiyingLifecycle? El siguiente es un diagrama de clases UML de un ciclo de vida dibujado por mí mismo.
Nuestras actividades personalizadas se heredan de SupportActivity. Puede encontrar que SupportActivity implementa la interfaz LifecycleOwner y contiene el objeto LifecycleRegistry que implementa Lifecycle. Este objeto puede entenderse como un observador El sujeto y LifecycleRegistr en el patrón agregan varios LifecycleObservers y notifican a LifecycleObserver para que realice las llamadas al método correspondientes cuando cambie el ciclo de vida.
2.2 Percepción del ciclo de vida
El ciclo de vida es un marco para la conciencia del ciclo de vida, entonces, ¿cómo percibe el ciclo de vida de la Actividad? Mira el método onCretae de SupportActivity
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
}
Aquí primero llame al método ReportFragment.injectIfNeededIn (this), mire este método
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 activities
android.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();
}
}
Muy simple, es agregar un ReportFragment a la Actividad actual. Observe la función de ciclo de vida de ReportFragment.
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
dispatchCreate(mProcessListener);
dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
super.onStart();
dispatchStart(mProcessListener);
dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
super.onResume();
dispatchResume(mProcessListener);
dispatch(Lifecycle.Event.ON_RESUME);
}
@Override
public void onPause() {
super.onPause();
dispatch(Lifecycle.Event.ON_PAUSE);
}
@Override
public void onStop() {
super.onStop();
dispatch(Lifecycle.Event.ON_STOP);
}
@Override
public void onDestroy() {
super.onDestroy();
dispatch(Lifecycle.Event.ON_DESTROY);
// just want to be sure that we won't leak reference to an activity
mProcessListener = null;
}
private void dispatch(Lifecycle.Event event) {
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) {
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
Verá que se llama al método de envío y el método de envío determinará si la actividad implementa la interfaz LifecycleOwner. Si la interfaz está implementada, llamará al handleLifecycleEvent de LifecycleRegister, de modo que se notificará el estado del ciclo de vida a cada LifecycleObserver por LifecycleRegistry para llamarlo. Correspondiente al método de Lifecycle.Event. Este método de percibir el ciclo de vida de la actividad a través de Fragmentos se refleja en Glide. Esta es la percepción del ciclo de vida de la actividad, pero ¿qué pasa con los fragmentos? Eche un vistazo al código fuente de Fragment y encontrará que Fragment también implementa la interfaz LifecycleOwner y también está asociado con un objeto LifecycleRegistry
void performCreate(Bundle savedInstanceState) {
if (this.mChildFragmentManager != null) {
this.mChildFragmentManager.noteStateNotSaved();
}
this.mState = 1;
this.mCalled = false;
this.onCreate(savedInstanceState);
this.mIsCreated = true;
if (!this.mCalled) {
throw new SuperNotCalledException("Fragment " + this + " did not call through to super.onCreate()");
} else {
this.mLifecycleRegistry.handleLifecycleEvent(Event.ON_CREATE);
}
}
Vea que se llama a mLifecycleRegistry.handleLifecycleEvent en su performCreate, y también se llama en los métodos performStart y performResume de la misma forma. De hecho, hay un fenómeno interesante aquí: el método dispatch (Lifecycle.Event.ON_CREATE) en ReportFragment se llama en onActivityCreated, y el envío del evento Lifecycle.Event.ON_CREATE del fragmento se llama en performCreate. Este es un Problema. Si agrega un Fragmento al método de actividad onCreate, y este Fragmento también agrega un monitoreo de LifecycleObserver, ¿quién escuchará primero?
por ejemplo:
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
lifecycle.addObserver(Presenter())
supportFragmentManager.beginTransaction().replace(R.id.container,MainFragment()).commit()
}
}
class Presenter:LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
fun onCreate(){
println("presenter oncreate")
}
class MainFragment:Fragment() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
lifecycle.addObserver(FragmentPresenter())
}
}
class FragmentPresenter:LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
fun onCreate(){
println("presenter fragment oncreate")
}
}
Ejecute el programa y verá que el resultado de la impresión es presenter oncreate, y luego presenter fragment oncreate.
Esto es muy confuso. Sabemos que el ciclo de vida del fragmento onCreate es anterior a onActivityCreated. ¿Por qué no ejecutó primero el método onCreate de FragmentPresenter? ? La razón es en realidad commit. Es asincrónico. Cuando se envía el fragmento, se llamará en ese momento, por lo que MainFragment aún no se ha agregado, pero ReportFragment llama al método manager.executePendingTransactions (), que ejecutará el método existente cosas inmediatamente, por lo que este ReportFragment se ha agregado a FragmentManager, por lo que el ciclo de vida no se corresponde con la situación, si también agrega manager.executePendingTransactions () después de la confirmación de MainFragment en MainActivity, encontrará que el resultado de la impresión se invierte.
2.3 Análisis de registro del ciclo de vida
LifecycleRegister es el foco, primero observe el método addObserver
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
if (previous != null) {
return;
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
// it is null we should be destroyed. Fallback quickly
return;
}
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {
pushParentState(statefulObserver.mState);
statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
popParentState();
// mState / subling may have been changed recalculate
targetState = calculateTargetState(observer);
}
if (!isReentrance) {
// we do sync only on the top level.
sync();
}
mAddingObserverCounter--;
}
Aquí encontrará que se genera un ObserverWithState y se coloca en FastSafeIterableMap. Esta clase
es una lista personalizada para guardar observadores y procesar la eliminación / adición durante el recorrido.
Observador 1 y Observador 2 en cualquier momento: si suma_orden (observador1) <suma_orden (observador2), entonces estado (observador1)> = estado (observador2)
Luego mire el método handleLifecycleEvent
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
State next = getStateAfter(event);
moveToState(next);
}
Primero, se obtendrá el estado correspondiente de acuerdo con el evento entrante. La relación de objeto específico se muestra
en la figura siguiente. En el método moveToState, se llamará al método de sincronización
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "
+ "new events from it.");
return;
}
while (!isSynced()) {
mNewEventOccurred = false;
// no need to check eldest for nullability, because isSynced does it for us.
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner);
}
Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
Aquí puede ver que si el estado de ObserverWithState es menor que el estado actual, se llama al método forwardPass. Si es mayor que el estado actual, se llama al método backwardPass. El estado predeterminado de ObserverWithState se determina en addObserver método.
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
Entonces mira el método forwardPass
private void forwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
mObserverMap.iteratorWithAdditions();
while (ascendingIterator.hasNext() && !mNewEventOccurred) {
Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
pushParentState(observer.mState);
observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
popParentState();
}
}
}
Aquí llama al método dispatchEvent de ObserverWithState, eche un vistazo a este método
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
La verdad salió a la luz, y finalmente se llamó mLifecycleObserver.onStateChanged (propietario, evento); al mismo tiempo, actualicé mi estado, cómo lo obtuvo este mLifecycleObserver y qué hizo específicamente, no lo diré específicamente, usted puede entrar y echar un vistazo si está interesado. El método de llamada en este artículo generará un objeto ReflectiveGenericLifecycleObserver, que contendrá el objeto Method del método anotado con @OnLifecycleEvent declarado en el Presentador, y finalmente lo llamará.
Bienvenido a seguir mi cuenta oficial