ライフサイクル研究ノートのAndroidJetpackコンポーネント
LiveData研究ノートのAndroidJetpackコンポーネント
ViewModel研究ノートのAndroidJetpackコンポーネント
世界の記事の大きなコピーと言われています。しかし、私は心配していませんし、他人の意見を盗用することもありません。
ブログやGibHubのコンテンツの90％が重複していると言う人もいます。私はこの文章に同意しますが、それは悪いことではないと思います。誰も同じことについて彼自身の弁証法的理解を持つべきではありません、さもなければそれは本当に世界の記事の大きなコピーになるでしょう。
私自身の理解を明確にし、将来のレビューのためにメモを取り、後発者が回り道を避けやすくするために、私はまだフォローアップ記事を書く勇気を奮い立たせました。同様の優れた記事を発表した偉大な神々はたくさんいますが。
多くのナンセンスな話をして、今日はライフサイクルコンポーネントについて話します。
コンポーネントアドレス：https：//developer.android.google.cn/topic/libraries/architecture/lifecycle
この大物による一連の記事を参照することもできます：https：//www.jianshu.com/p/b1208012b268
感動詞ナンセンス：
Androidの公式ウェブサイトhttps://developer.android.comにアクセスするには、壁を越える必要があります。そうしないと、アクセスできなくなります。
壁を越えずにAndroid中国語のウェブサイトhttps://developer.android.google.cnにアクセスします。
内容は.comのウェブサイトと同じようで、公式の.google.cnのウェブサイトは定期的に更新されます。
ライフサイクル環境の構成：
1. SDKが26未満の場合、依存関係パッケージをインポートする必要があります android.arch.lifecycle
2. androidx環境の場合、依存関係パッケージもインポートする必要があります。https： //developer.android.google.cn/jetpack/androidx/releases/lifecycle#declaring_dependenciesを参照して ください。
3.上記を除き、インポートは必要ありません。SDK26以降、ライフサイクル依存関係パッケージがシステムに組み込まれています。
ライフサイクルの公式の元の定義：
ライフサイクル対応コンポーネントは、アクティビティやフラグメントなど、別のコンポーネントのライフサイクルステータスの変化に応じてアクションを実行します。これらのコンポーネントは、保守が容易な、より適切に編成された、多くの場合軽量のコードを作成するのに役立ちます。
ライフサイクルはアクティビティとフラグメントのライフサイクルを認識できるコンポーネントであると言って、公式の説明を読み、多くの優れたブログを読みました。
これは問題を説明するためのデモです。これは、ツールクラスの登録と反登録のアナロジーです。従来の記述方法は次のとおりです。
public class TestBus {
private Activity mActivity;
public void registerBusEvent(Activity activity) {
this.mActivity = activity;
// TODO: 2019/8/11 if
}
public void unRegister(Activity activity) {
// TODO: 2019/8/11 if
}
}
public class LifecycleActivity extends AppCompatActivity {
private TestBus mTestBus;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle);
mTestBus = new TestBus();
mTestBus.registerBusEvent(this);
}
@Override
protected void onDestroy() {
super.onDestroy();
if (mTestBus != null) {
mTestBus.unRegister(this);
}
}
}
公式の説明と偉大な神々の意見を要約すると、上記のコードには次の欠点があります。
1. mTestBusオブジェクトがActivityのonDestroy（）メソッドで登録解除するのを忘れた場合、それは悲劇になりますか？
2.アクティビティのonDestroy（）メソッドで登録が解除された、より類似した機能クラスがある場合、無効なコードの量が増加しますが、これも悲劇ですか？
3.アクティビティこれは、システムプロセスとアプリケーションプロセス間のライフサイクルコールバックのプロキシクラスであり、あまり多くのビジネスコードを記述しないでください。
上記の問題を解決するために、アクティビティとフラグメントのライフサイクルを認識できるライフサイクルコンポーネントがあり、登録防止と同様のコードを独自のビジネスで完全に処理できます。最初に完全なデモに行きましょう、詳細について話しましょう：
public class TestBus implements LifecycleObserver {
private Activity mActivity;
public void registerBusEvent(Activity activity) {
this.mActivity = activity;
// TODO: 2019/8/11 if
}
private void unRegister(Activity activity) {
// TODO: 2019/8/11 if
}
// 需要监控 Activity onDestroy
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void onDestroy() {
unRegister(mActivity);
}
}
public class LifecycleActivity extends AppCompatActivity {
private TestBus mTestBus;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle);
mTestBus = new TestBus();
mTestBus.registerBusEvent(this);
// 注册 lifecycle 观察者
getLifecycle().addObserver(mTestBus);
}
// @Override
// protected void onDestroy() {
// super.onDestroy();
// if (mTestBus != null) {
// mTestBus.unRegister(this);
// }
// }
}
上記のコードを読んだ後、Activityの明らかな変更は、onDestroy（）メソッドに注釈が付けられていることです。つまり、問題は、TestBusの登録防止メソッドがActivityのonDestroy（）メソッドで呼び出されていないかどうかをTestBusがどのように知るのかということです。ライフサイクルは、アクティビティを監視対象のイベントソースとして使用し、TestBusをオブザーバーとして使用してアクティビティのライフサイクルを監視しますか？ソースコードを少し見てみましょう。
上記のデモのActivityのonCreate（）メソッドのコードを最初に見ると、登録されたオブザーバーのように感じられます。
getLifecycle().addObserver(mTestBus);`getLifecycle（）`が最終的に `SupportActivity`の` mLifecycleRegistry`オブジェクトを返すことがわかります。
`LifecycleRegistry`をさらに分析すると、` Lifecycle`は抽象クラスであり、いくつかの抽象メソッドと2つの列挙クラスを提供します。同時に、 `LifecycleRegistry`は` Lifecycle`の抽象クラスを継承します。
`LifecycleRegistry`のコンストラクターで、` LifecycleOwner`インターフェースのインスタンスを渡す必要があることがわかり、 `SupportActivity`がこのインターフェースを実装していることがあります。
同時に、 `SupportActivity`はインターフェースの抽象メソッド` getLifecycle（） `を実装し、返される型は` Lifecycle`型でなければなりません。`SupportActivity`の` getLifecycle（） `メソッドが` LifecycleRegistry`タイプを返すのはたまたまです。
コード `getLifecycle（）。addObserver（mTestBus）;`の分析を続けます。`mLifecycleRegistry`オブジェクトにオブザーバーオブジェクトを追加するのと同様に、必要なパラメータータイプは `LifecycleObserver`である必要があります。偶然にも、デモの「TestBus」はインターフェース「LifecycleObserver」を実装しています。
簡単な分析の結果、次のことがわかりました。
1.`SupportActivity`には組み込みの `LifecycleRegistry`オブジェクトがあります。`LifecycleRegistry`オブジェクトを作成するとき、それは独自のメモリ参照を渡します。
2. `LifecycleRegistry`は、` Activity`が初期化されたときに作成されるActivityイベントソースのライフサイクル状態の管理クラスです。
3. `getLifecycle（）。addObserver（mTestBus）;`このコード行は、オブザーバーオブジェクトを登録するためのものであり、イベントソースのライフサイクルが変更されるとオブザーバーに通知されます。
この時点で、「ライフサイクル」の原則のほとんどを理解しました。残っているのは、上記の例の「TestBus」でのいくつかのアノテーションの役割と、イベントソースのライフサイクルが次のアノテーションメソッドにトリガーされる方法です。 `TestBus`。
`Lifecycle.State`列挙型クラスを検索し、それが` LifecycleDispatcher.makeState（） `メソッドで使用されていることを確認します。`LifecycleDispatcher`の` Lifecycle.State`の特定の列挙を追跡し続けると、それが `LifecycleDispatcher.onActivitySaveInstanceState（）`メソッドで使用され、 `LifecycleDispatcherの内部クラスでも広く使用されていることがわかります。 DestructionReportFragment`。この推測から、 `Activity`と` Fragment`のライフサイクルが変化すると、イベント状態がアクティブにトリガーされ、最終的には `LifecycleRegistry.makeToState（）`メソッドに呼び出され、その後循環的に呼び出されると結論付けることができます。オブジェクトの対応するメソッドをすべてのオブザーバーに通知します。
上記のイベント通知プロセスを理解した後、私が知らない別のステップがあります。イベントがトリガーされるたびに、LifecycleRegistryは、オブザーバーのどのメソッドをコールバックする必要があるかをどのように認識しますか？
または、上記の例のTestBusのonDestroy（）メソッドをLifecycleRegistryから呼び出すにはどうすればよいですか？
オブザーバーを登録する方法を観察します。
LifecycleRegistry.java
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
// 注意看 ObserverWithState 的构造函数
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
// ...
}ObserverWithState.java
ObserverWithState(LifecycleObserver observer, State initialState) {
// 注意看 Lifecycling.getCallback() 方法
mLifecycleObserver = Lifecycling.getCallback(observer);
mState = initialState;
}Lifecycling.java
@NonNull
static GenericLifecycleObserver getCallback(Object object) {
if (object instanceof FullLifecycleObserver) {
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object);
}
if (object instanceof GenericLifecycleObserver) {
return (GenericLifecycleObserver) object;
}
final Class<?> klass = object.getClass();
// 注意看这个方法
int type = getObserverConstructorType(klass);
// ...
}Lifecycling.java
private static int getObserverConstructorType(Class<?> klass) {
if (sCallbackCache.containsKey(klass)) {
return sCallbackCache.get(klass);
}
// 注意看这个方法
int type = resolveObserverCallbackType(klass);
sCallbackCache.put(klass, type);
return type;
}Lifecycling.java
private static int resolveObserverCallbackType(Class<?> klass) {
// anonymous class bug:35073837
// 此行代码
boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass);
}ClassesInfoCache.java
boolean hasLifecycleMethods(Class klass) {
if (mHasLifecycleMethods.containsKey(klass)) {
return mHasLifecycleMethods.get(klass);
}
Method[] methods = getDeclaredMethods(klass);
for (Method method : methods) {
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation != null) {
// Optimization for reflection, we know that this method is called
// when there is no generated adapter. But there are methods with @OnLifecycleEvent
// so we know that will use ReflectiveGenericLifecycleObserver,
// so we createInfo in advance.
// CreateInfo always initialize mHasLifecycleMethods for a class, so we don't do it
// here.
createInfo(klass, methods);
return true;
}
}
mHasLifecycleMethods.put(klass, false);
return false;
}コードはここでトレースされます。これ以上は言いたくありません。注釈、反射！
これまでのところ、ソースコード分析は非常に明確です。
Demo 地址：https://github.com/mengzhinan/Lifecycle_LiveData_ViewModel_demo