1

Flex アプリのパフォーマンスを改善するための非常によく知られた事実は、入れ子になったコンテナーの量を減らすことですが、これを行うのは特に難しいように思えます。

私はモバイルアプリを開発していますが、実行時に一部のコンポーネントのサイズを変更するのが非常に遅くなります (コンポーネントをフルスクリーンに切り替えて元に戻すことができます)。それほど複雑ではないコンポーネントは、目立った遅延なしで即座にサイズ変更されます。これは、すべてのコンポーネントで私が望んでいることです。

次のコンポーネントを想定してみましょう (もちろん簡略化されており、一部のグループはそれ自体がコンポーネントですが、ネスト レベルは非常に正確です)。

<VGroup "the component's base">

   // I guess this is fine
   <HGroup "the component's title bar">
       <SkinnableContainer "title bar skin">
            <title bar components, labels etc. />
       </SkinnableContainer>
   </HGroup>

   <HGroup "options bar that has switchable components">
      <button />
      <array "holds 'views' for the options bar that can be switched">
           <HGroup "one option view">
               <option view contents, labels etc. />
           </HGroup>
           <HGroup "another option view">
               <option view contents, labels etc. />
           </HGroup>
      </array>
     <button />
   </HGroup>

基本的なコンポーネントのレイアウトは以上です。オプションバーを最適化できるかどうかはわかりません.2つのボタンは、ボタンの間に配置されるコンテンツを切り替えるために使用されるため、上部HGroup. 配列内のコンポーネントも水平方向に整列する必要があるため、子HGroups. これは、このコンポーネントのネスト レベル 3 に達しており、それ自体が既にレベル 3 のコンテナーになっています (私のナビゲーションによる)。

コンポーネントのコンテンツ領域へ。

     <Group "this is the content area">

     // this group needs two different layouts (vertical and horizontal) that
     // are switched based upon the user's choice of having the component maximised
     // or minimised 
     <layouts />

     // this list changes it's size based on the selected layout
     <List />

     this group also changes it's size based on the layout
     <VGroup>
        <scroller>
            // the group here holds a large label that needs to be scrollable
            <group>
        </scroller>
        <HGroup>
            <some basic components like `SkinnableContainer` and `Label` />
        </HGroup> 
     </VGroup>
   </Group>

そして、それは私の最悪のパフォーマンス（レイアウトのサイズ変更が賢明）コンポーネントのレイアウトであり、タグを閉じています...

</VGroup>

...これで完了です。

大きな問題ですが、これを最適化する余地はありますか? もしそうなら、どこから始めればよいですか？明らかに、レイアウト マネージャーは、レイアウトの切り替えプロセス中にかなりの量を計算する必要があります。残念ながら、これはモバイル アプリであるため、このアプリをさまざまなプラットフォームと解像度で動作させる必要があるため、絶対的なサイズで作業することはできません。したがって、すべてのグループには相対的なサイズが割り当てられており、通常は幅と高さの両方で 100% です。 .

これを合理化したいのですが、どこから始めればよいのかわかりません。私ができることのヒントはありますか？

4

2 に答える 2

2

私は以前のプロジェクトとほとんど同じことを担当していました。問題の塊を排除する魔法の弾丸は1つもありませんでしたが、それは「千枚の紙切れによる死」理論に沿ったものでした。

あなたに基づく改善のいくつかの例：

TitleBar：スキナブルコンテナにはレイアウトプロパティもあります。外側のグループシェルを削除し、SCをベースとして始めてみませんか？

<!-- <HGroup "the component's title bar"> -->
   <SkinnableContainer id="originalGroupId" "title bar skin">
       <layout>
          <HorizontalLayout /> 
       <layout>
       <title bar components, labels etc. />
   </SkinnableContainer>
<!-- </HGroup> -->

OptionsBar：モバイルスペースに制限があるかどうかはわかりませんが、INavigatorContentインターフェイスを使用するコンテナーを使用できますか？IE。creationPolicyユーザーが実際に要求するまで、コンテナーの孫のみを作成するフラグを基本的に使用するもの。グループには仮想化の概念がないため、すべてのコンポーネントは親のインスタンス化で作成されます。

<ViewStack "options bar that has switchable components">
  <button />
</ViewStack>

コンポーネント領域：これは少し難しくなりますが、実際に表示したい情報を10,000フィートで表示するのに役立つ場合があります（少なくとも私にとってはそうです）。たとえば、非常に長いラベルのスクロールでは、TextAera代わりに次のようなものを使用できますか？もしそうなら、それは外殻を排除するでしょう：

// the group here holds a large label that needs to be scrollable
<TextArea text="my really large label">

</TextArea>

お役に立てば幸いです...

于 2012-07-06T16:10:31.263 に答える
0

無関係かもしれませんが、リストの使用はお勧めしません。同じではないかもしれませんが、コンポーネントの1つをリストの使用から動的なスキンパーツに変更すると、そのコンポーネントのレンダリングが著しく高速になりました（600ミリ秒対100ミリ秒）。Sparkのリストはかなり重いです。

于 2012-07-09T09:27:06.240 に答える