Flexコンポーネントライフサイクル
【注意】書きかけです
カスタムコンポーネントを正しく作るためには、コンポーネントのライフサイクルを正確に理解しておく必要がある、という話をどこかで聞いたので、ライフサイクルと実装の対応関係を整理してみました。
ライフサイクル全体像
ライフサイクルは「生成」「初期化」「更新」「破棄」のフェーズに分かれます。というか分けてみました。
初期化フェーズと更新フェーズで登場する「無効化」と「検証」ステップがポイントです。
＃フルサイズの画像はこちら
では、各ステップを順番にみていきます。
生成フェーズ
コンポーネントにとって、新しい人生のスタートとなるフェーズです。
初期化フェーズ
アタッチメントが完了すると初期化フェーズに突入します。
初期化フェーズでは、preinitializeイベント、initializeイベント、creationCompleteイベントが発火されます。
preinitializeイベント
このイベントでは、子が作成される前に親のプロパティを設定する等の処理を行います。
この時点ではまだ子は作成されていません。つまり、コンストラクタで子を作成するのはおかしいわけです。
（このイベントの用途はあまり無いかも）
createChildren呼出し(子の作成)
このステップでは子を作成するためのcreateChildren()メソッドが呼び出されます。createChildrenを実装してください。
initializeイベント
initializeイベントは、当該コンポーネントとその全ての子が作成された後、コンポーネントのサイズを確定する前に発火されるイベントです。
レイアウトが確定する前に、コンポーネントの設定を行う場合に使います。
無効化
無効化はコンポーネントの仕組みにおいて、キーコンセプトとなる重要なステップです。
次回描画時に、検証ステップに対応するメソッドを呼び出してください、とマーキングする処理を行います。
| 無効化メソッド | 検証メソッド |
|---|---|
| invalidateProperties() | commitProperties() |
| invalidateSize() | measure() |
| invalidateDisplayList() | layoutChrome()、updateDisplayList() |
※invalidateDisplayList()はlayoutChromeとupdateDisplayListが対応していますが、先に呼ばれるのはlayoutChromeです。
例えば、無効化ステップでinvalidateProperties()を呼び出した場合、次回描画時に、Flexによって当該コンポーネントのcommitProperties()が呼び出されます。
検証
検証は長い長いステップです。細かく分けると「コミット」「測定」「レイアウト」に分かれますが、特にレイアウトステップについては、これでもかというぐらい長いです。
- コミット
コンポーネントのプロパティに対する変更を調整するためのステップです。
通常、画面上の表示方法に影響するプロパティに対する調整を行います。
- 測定
サイズを測ります。明示的にサイズが指定されている場合、このステップは実質省略され、measure()メソッドが呼び出されません。ということは、明示的にサイズ指定を行った方がほとんどの場合、計算コストが低いということになります。
- レイアウト
- layoutChrome
ContainerもしくはContainerサブクラスが持つメソッドで、コンテナ周囲の境界線領域を定義します。
-
- updateDisplayList
・コンポーネントの子のサイズと位置を設定
・スキンやグラフィックエレメントの描画
更新フェーズ
更新要求待ち
ボーッとしている状態。
更新要求
テキストを変更したとか、なんかいろいろ。
無効化
初期化フェーズの無効化と同じ。
検証
初期化フェーズの検証と同じ。
破棄フェーズ
さらばコンポーネント。お前のことは忘れないよ。
デタッチメント
お前はうちの子ではない、といって勘当されるステップです。悲しいですね。
ガベージコレクト
んでもって、誰からも気にされていない場合、ゴミとして捨てられます。悲しいですね。
