1. 사용
수명주기 프레임 워크는 다른 구성 요소 (예 : 활동 및 조각)의 수명주기 상태 변경에 응답하여 작업을 수행하는 구성 요소를 인식하는 데 사용됩니다. 이러한 구성 요소를 사용하면 구성하기 쉽고 종종 더 가볍고 유지 관리하기 쉬운 코드를 생성 할 수 있습니다.
예를 들어 :
활동 또는 조각의 수명주기에서 일부 처리를 수행해야하는 경우 :
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
presenter.onCreate()
}
override fun onStart(){
super.onStart()
presenter.onStart()
}
...
override fun onDestroy(){
super.onDestroy()
presenter.onDestroy()
}
이 쓰기 방법은 Activity 또는 Fragment의 해당 라이프 사이클 함수에서 발표자의 해당 메소드를 호출해야합니다.이 쓰기 방법은 상대적으로 무겁고 가볍지 않으며 발표자와 Activity를 분리하지 않습니다. 라이프 사이클의 출현으로이를 해결합니다. 문제.
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")
}
이러한 방식으로 발표자와 활동 사이의 관계가 연관 관계에서 종속성 관계로 변경되어 결합이 감소합니다. 동시에 발표자는 다음을 호출하지 않고도 활동의 해당 라이프 사이클을 인식하는 데 사용할 수 있습니다. 활동의 라이프 사이클 기능에서 발표자 방법.
2. 분석
2.1 관찰자 모드
인터페이스와 메소드의 이름을 통해 전체 Lifecycle이 실제로 관찰자 패턴임을 알 수 있습니다. 다음은 관찰자 패턴의 UML 클래스 다이어그램입니다.
그러면 duiyingLifecycle은 어떤 모습일까요? 다음은 직접 그린 Lifecycle의 UML 클래스 다이어그램입니다.
사용자 정의 활동은 SupportActivity에서 상속됩니다. SupportActivity가 LifecycleOwner 인터페이스를 구현하고 Lifecycle을 구현하는 LifecycleRegistry 객체를 보유하고 있음을 알 수 있습니다.이 객체는 관찰자로 이해할 수 있습니다. The Subject 패턴의 LifecycleRegistr는 여러 LifecycleObserver를 집계하고 라이프 사이클이 변경 될 때 해당 메소드 호출을 작성하도록 LifecycleObserver에 알립니다.
2.2 수명주기 인식
수명주기는 수명주기 인식을위한 프레임 워크입니다. 그렇다면 활동의 수명주기를 어떻게 인식합니까? SupportActivity의 onCretae 메소드를 살펴보십시오.
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
}
먼저 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 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();
}
}
매우 간단합니다. 현재 활동에 ReportFragment를 추가하는 것입니다. 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);
}
}
}
디스패치 메소드가 호출되고 디스패치 메소드는 Activity가 LifecycleOwner 인터페이스를 구현하는지 여부를 결정합니다. 인터페이스가 구현되면 LifecycleRegister의 handleLifecycleEvent를 호출하여 라이프 사이클의 상태를 알립니다. LifecycleRegistry에서 각 LifecycleObserver를 호출하여 Lifecycle.Event의 메소드에 해당합니다. Fragment를 통해 활동 수명주기를 인식하는이 방법은 실제로 Glide에 반영됩니다. 이것이 Activity의 라이프 사이클 인식이지만 Fragment는 어떻습니까? Fragment 소스 코드를 살펴보면 Fragment가 LifecycleOwner 인터페이스도 구현하고 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);
}
}
mLifecycleRegistry.handleLifecycleEvent가 performCreate에서 호출되고, 동일한 방식으로 performStart 및 performResume 메소드에서도 호출됩니다. 실제로 여기서 흥미로운 현상은 ReportFragment의 dispatch (Lifecycle.Event.ON_CREATE) 메서드가 onActivityCreated에서 호출되고 조각의 Lifecycle.Event.ON_CREATE 이벤트 전송이 performCreate에서 호출된다는 것입니다. Activity의 onCreate 메서드에 Fragment를 추가하고이 Fragment도 LifecycleObserver 모니터링을 추가하면 누가 먼저 수신할까요?
예를 들면 :
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")
}
}
프로그램을 실행하면 인쇄 결과가 생성시 발표자이고 생성시 발표자 조각임을 알 수 있습니다.
이것은 매우 혼란 스럽습니다. 조각 onCreate의 수명주기가 onActivityCreated 이전이라는 것을 알고 있습니다. FragmentPresenter의 onCreate 메서드를 먼저 실행하지 않은 이유는 무엇입니까? ? 그 이유는 실제 커밋입니다. 비동기 적입니다. Fragment가 제출되면 그 시점에 호출되므로 MainFragment가 아직 추가되지 않았지만 ReportFragment는 기존을 실행하는 manager.executePendingTransactions () 메서드를 호출합니다. 즉,이 ReportFragment가 FragmentManager에 추가되었으므로 수명주기가 상황과 일치하지 않습니다. MainActivity에서 MainFragment 커밋 후에 manager.executePendingTransactions ()도 추가하면 인쇄 결과가 반전되는 것을 알 수 있습니다.
2.3LifecycleRegister 분석
LifecycleRegister가 초점입니다. 먼저 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--;
}
여기에서 ObserverWithState가 생성되어 FastSafeIterableMap에 저장되는 것을 볼 수 있습니다.이 클래스
는 관찰자를 저장하고 순회 중 삭제 / 추가를 처리하기위한 사용자 지정 목록입니다.
관찰자 1과 관찰자 2는 언제든지 : if addition_order (observer1) <addition_order (observer2), then state (observer1)> = state (observer2)
다음으로 handleLifecycleEvent 메서드를 살펴 봅니다.
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
State next = getStateAfter(event);
moveToState(next);
}
먼저 들어오는 Event에 따라 해당 State를 얻습니다. 특정 객체 관계는 아래 그림과 같습니다.
moveToState 메서드에서 sync 메서드가 호출됩니다.
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;
}
여기에서 ObserverWithState의 상태가 현재 상태보다 작 으면 forwardPass 메서드가 호출되는 것을 볼 수 있습니다. 현재 상태보다 크면 backwardPass 메서드가 호출됩니다. ObserverWithState의 기본 State는 addObserver에서 결정됩니다. 방법.
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
그런 다음 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();
}
}
}
여기에서 ObserverWithState의 dispatchEvent 메소드를 호출합니다.이 메소드를 살펴보세요.
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
진실이 밝혀졌고 마침내 mLifecycleObserver.onStateChanged (owner, event);라고 불 렸습니다. 동시에 저는 상태를 업데이트했고,이 mLifecycleObserver가 어떻게 얻었는지, 구체적으로 무엇을했는지 구체적으로 말하지 않겠습니다. 이 문서의 호출 메서드는 Presenter에서 선언 된 @OnLifecycleEvent로 주석이 추가 된 메서드의 Method 개체를 보유하고 마지막으로 호출 할 ReflectiveGenericLifecycleObserver 개체를 생성합니다.
내 공식 계정 팔로우를 환영합니다