ViewのrequestLayoutによって開始された再描画プロセスのソースコード分析(Android Q)
通常、ViewクラスのrequestLayoutメソッドを呼び出してビューを更新しますが、どのようにして再描画ロジックを開始しますか?
ビューのrequestLayoutメソッド:
public void requestLayout() {
……
if (mParent != null && !mParent.isLayoutRequested()) {
//调用父视图的 requestLayout 方法
mParent.requestLayout();
}
……
}
このメソッドはいくつかのプロパティを設定してから、親ビューのrequestLayoutメソッドを呼び出します。このメソッドは、ルートビューであるDecorViewに至るまで、常にビューツリーに対して呼び出されます。しかし、結局、DecorViewのrequestLayoutメソッドは呼び出されますか?
まず、mParentが割り当てられている場所を見てみましょう。
ビューのassignParentメソッド
protected ViewParent mParent;
void assignParent(ViewParent parent) {
if (mParent == null) {
mParent = parent;
} else if (parent == null) {
mParent = null;
} else {
throw new RuntimeException("view " + this + " being added, but"
+ " it already has a parent");
}
}
mParentはassignParentのパラメーターを介して設定され、誰がassignParentメソッドを呼び出しましたか?
ViewRootImplのsetViewメソッド:
戻ってみましょう。DecorViewをWindowに追加するときに、ViewRootImplのsetViewメソッドが呼び出されます。
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView){
……
view.assignParent(this);
……
}
実際、ViewRootImplのsetViewメソッドでは、ViewのassignParentメソッドが呼び出され、パラメーターはViewRootImplオブジェクトです。つまり、DecorViewのmParentはViewRootImplオブジェクトです。
したがって、ViewのrequestLayoutメソッドは最終的にそのmParentを介してバブルされ、最終的にViewRootImplでrequestLayoutメソッドを呼び出しました。これは、この記事の前半の内容に関連していませんか?これらのビュー表示プロセスは両方とも、ViewRootImplのrequestLayoutメソッドによって開始されます。
総括する
ViewクラスのrequestLayoutメソッドはビューを更新します。再描画ロジックをどのように開始しますか?
-
ViewRootImplのsetViewメソッドでは、ViewのassignParentメソッドが呼び出され、パラメーターはViewRootImplオブジェクトです。つまり、DecorViewのmParentはViewRootImplオブジェクトです。
-
ViewのrequestLayoutメソッドは最終的にそのmParentを介してバブルされ、最終的にViewRootImplでrequestLayoutメソッドを呼び出しました。つまり、基本的には、ViewRootImplのrequestLayoutメソッドを介して開始されます。
PS: -複数の分析記事のために、一連の記事を確認してください> 「のAndroidの基本的な原則の分析」
PS:複数の分析記事のために、一連の記事を確認してください- > 「のAndroidの基本的な原則の分析」
PS:その他の分析記事については、シリーズ-> 「Androidの基本原則の分析」をご覧ください。