Android Jetpack Components of Lifecycle学習ノート
Android Jetpack Components of Lifecycle学習ノート
Android Jetpack Components of LiveData学習ノート
Android Jetpack Components of View Model学習ノート
天下の文章は大写しだと言われている.しかし、私は心配していません.私は他の人の見解をパクリしたことがありません.
ブログ、GibHubの90%が重複しているという人もいます.この言葉には賛成ですが、これは悪いことだとは思いません.同じものは、誰も自分の弁証理解を持つべきではありません.そうしないと、本当に天下の文章の大写しになります.
私自身の理解を明らかにするために、メモとして後で振り返るためにも、後者が回り道をしないようにも、勇気を出して後続の文章を書きました.多くの大神が似たような優秀な文章を発表したにもかかわらず.
くだらないことをたくさん言って、今日私が話したいのはLifecycleコンポーネントです.
コンポーネントアドレス: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公式は定期的に更新されます.
Lifecycle環境構成:
1.sdkが26未満のバージョンの場合、依存パッケージ
2、android xの環境であれば、依存パッケージをインポートする必要もあります.参考にしてください.https://developer.android.google.cn/jetpack/androidx/releases/lifecycle#declaring_dependencies
3、以上の場合を除き、何の導入も不要であり、sdk 26からLifecycle依存パッケージが内蔵されている.
Lifecycle公式原文定義:
Lifecycle-aware components perform actions in response to a change in the lifecycle status of another component, such as activities and fragments. These components help you produce better-organized, and often lighter-weight code, that is easier to maintain.
公式の解釈を見たり、優れたブログを見たりして、LifecycleはActivityとFragmentのライフサイクルを感知できるコンポーネントだと言われています.
Demoを比較して問題を説明し、ツールクラスが逆登録に登録されていることを例えます.伝統的な書き方は以下の通りです.
公式の解釈と各道の大神の見解を総括して、以上のコードには以下の欠点がある.
1、万一mTestBusオブジェクトがActivityのonDestroy()メソッドに逆登録するのを忘れてしまったら、悲劇になるのではないでしょうか.
2、もっと似たような機能クラスがあれば、ActivityのonDestroy()メソッドに逆登録され、無効なコード量が大きくなるのも悲劇ではないでしょうか.
3、Activityはもともとシステムプロセスとアプリケーションプロセスの間でライフサイクルコールバックを行うエージェントクラスであり、あまり多くのビジネスコードを書き込むべきではない.
上記の問題を解決するため、Lifecycleコンポーネントがあり、ActivityとFragmentのライフサイクルを感知することができ、逆登録のようなコードは自分のビジネス内で完全に処理することができます.まず完全なDemoに行って、詳細を話しましょう.
上のコードを見た後、Activityで明らかな変化がonDestroy()メソッドを注釈していることがわかります.では問題ですが、ActivityのonDestroy()メソッドでTestBusの逆登録メソッドを呼び出さないと、TestBusはどのように知っていますか?LifecycleはActivityをイベントソースとして観察者にし、TestBusを観察者にしてActivityのライフサイクルを観察させたのではないでしょうか.では、ソースコードをください.
まず上のDemoのActivityのonCreate()メソッドのようなコードを見てみると、登録観察者のような感じがします.
`getLifecycle()`最終的には`SupportActivity`の`mLifecycleRegistry`オブジェクトが返されます.
さらに`LifecycleRegistry`を深く分析すると、`Lifecycle`は抽象的なクラスであり、いくつかの抽象的な方法と2つの列挙クラスを提供していることがわかります.同時に`LifecycleRegistry`は`Lifecycle`抽象クラスを継承した.
`LifecycleRegistry`のコンストラクション関数では、`LifecycleOwner`インタフェースに転送する必要がある例が発見され、ちょうど`SupportActivity`がこのインタフェースを実現した.
同時に`SupportActivity`はインタフェースの抽象的な方法`getLifecycle()を実現し、返されるタイプは`Lifecycle`タイプでなければならない.ちょうど`SupportActivity`の`getLifecycle()メソッドは`LifecycleRegistry`タイプを返します.
コード`getLifecycle()の分析を続けます.addObserver(mTestBus);` `mLifecycleRegistry`オブジェクトにオブザーバーオブジェクトを追加するように、必要なパラメータタイプは`LifecycleObserver`である必要があります.偶然にも、Demoの`TestBus`はインタフェース`フェース`LifecycleObserver`を実現した.
小段分析を経て、私たちは以下のように理解しました.
1、`SupportActivity`には`LifecycleRegistry`オブジェクトが内蔵されており、`LifecycleRegistry`オブジェクトを構築する際に、独自のメモリリファレンスが転送されます.
2,`LifecycleRegistry`はActivityイベントソースのライフサイクル状態の管理クラスであり,`Activity`初期化時に作成される.
3、`getLifecycle().addObserver(mTestBus);` この行のコードは、イベントソースのライフサイクルが変化すると、オブジェクトに通知されます.
ここで,`Lifecycle`の原理の大部分を理解すると,前例の`TestBus`のいくつかの注釈の役割と,イベントソースのライフサイクルがどのように`TestBus`の注釈方法にトリガされるかが残っている.
検索`Lifecycle.State`列挙類、発見は`LifecycleDispatcher.makeState()`メソッドで使用しました.さらに`LifecycleDispatcher`で`Lifecycleを追跡し続ける.State`の具体的な列挙は、`LifecycleDispatcher."LifecycleDispatcher.DestructionReportFragment`内部クラスでも多く使われています.このことから,`Activity`と`Fragment`のライフサイクルが変化すると自発的にイベント状態がトリガされ,`LifecycleRegistry.に呼び出されると推測する.makeToState()`メソッドでは,全観察者オブジェクトの対応を再循環通知するメソッドである.
上記の事件通知の過程を知って、それはまだ一歩も知らない.LifecycleRegistryはイベントがトリガーされるたびに、観察者のどの方法がコールバックする必要があるかをどのように知っていますか?
あるいは前例のTestBusのonDestroy()メソッドはどのようにLifecycleRegistryにコールバックされますか?
登録観察者の方法を観察します.
コードはここまで追跡して、何も言いたくない.注釈、反射!
ソースコードの分析はここまでで、すでに明らかになった.
Demoアドレス:https://github.com/mengzhinan/Lifecycle_LiveData_ViewModel_demo
Android Jetpack Components of LiveData学習ノート
Android Jetpack Components of View Model学習ノート
天下の文章は大写しだと言われている.しかし、私は心配していません.私は他の人の見解をパクリしたことがありません.
ブログ、GibHubの90%が重複しているという人もいます.この言葉には賛成ですが、これは悪いことだとは思いません.同じものは、誰も自分の弁証理解を持つべきではありません.そうしないと、本当に天下の文章の大写しになります.
私自身の理解を明らかにするために、メモとして後で振り返るためにも、後者が回り道をしないようにも、勇気を出して後続の文章を書きました.多くの大神が似たような優秀な文章を発表したにもかかわらず.
くだらないことをたくさん言って、今日私が話したいのはLifecycleコンポーネントです.
コンポーネントアドレス: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公式は定期的に更新されます.
Lifecycle環境構成:
1.sdkが26未満のバージョンの場合、依存パッケージ
android.arch.lifecycleをインポートする必要がある2、android xの環境であれば、依存パッケージをインポートする必要もあります.参考にしてください.https://developer.android.google.cn/jetpack/androidx/releases/lifecycle#declaring_dependencies
3、以上の場合を除き、何の導入も不要であり、sdk 26からLifecycle依存パッケージが内蔵されている.
Lifecycle公式原文定義:
Lifecycle-aware components perform actions in response to a change in the lifecycle status of another component, such as activities and fragments. These components help you produce better-organized, and often lighter-weight code, that is easier to maintain.
公式の解釈を見たり、優れたブログを見たりして、LifecycleはActivityとFragmentのライフサイクルを感知できるコンポーネントだと言われています.
Demoを比較して問題を説明し、ツールクラスが逆登録に登録されていることを例えます.伝統的な書き方は以下の通りです.
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、もっと似たような機能クラスがあれば、ActivityのonDestroy()メソッドに逆登録され、無効なコード量が大きくなるのも悲劇ではないでしょうか.
3、Activityはもともとシステムプロセスとアプリケーションプロセスの間でライフサイクルコールバックを行うエージェントクラスであり、あまり多くのビジネスコードを書き込むべきではない.
上記の問題を解決するため、Lifecycleコンポーネントがあり、ActivityとFragmentのライフサイクルを感知することができ、逆登録のようなコードは自分のビジネス内で完全に処理することができます.まず完全なDemoに行って、詳細を話しましょう.
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()メソッドを注釈していることがわかります.では問題ですが、ActivityのonDestroy()メソッドでTestBusの逆登録メソッドを呼び出さないと、TestBusはどのように知っていますか?LifecycleはActivityをイベントソースとして観察者にし、TestBusを観察者にしてActivityのライフサイクルを観察させたのではないでしょうか.では、ソースコードをください.
まず上のDemoの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`である必要があります.偶然にも、Demoの`TestBus`はインタフェース`フェース`LifecycleObserver`を実現した.
小段分析を経て、私たちは以下のように理解しました.
1、`SupportActivity`には`LifecycleRegistry`オブジェクトが内蔵されており、`LifecycleRegistry`オブジェクトを構築する際に、独自のメモリリファレンスが転送されます.
2,`LifecycleRegistry`はActivityイベントソースのライフサイクル状態の管理クラスであり,`Activity`初期化時に作成される.
3、`getLifecycle().addObserver(mTestBus);` この行のコードは、イベントソースのライフサイクルが変化すると、オブジェクトに通知されます.
ここで,`Lifecycle`の原理の大部分を理解すると,前例の`TestBus`のいくつかの注釈の役割と,イベントソースのライフサイクルがどのように`TestBus`の注釈方法にトリガされるかが残っている.
検索`Lifecycle.State`列挙類、発見は`LifecycleDispatcher.makeState()`メソッドで使用しました.さらに`LifecycleDispatcher`で`Lifecycleを追跡し続ける.State`の具体的な列挙は、`LifecycleDispatcher."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