0

GLKitを使用してレンダリングを行うゲームに取り組んでいます。UIレイアウトの作成作業を節約するために、Interface BuilderビューとUIKitビューを使用して、特定のインターフェイス要素の表示/非表示と相互作用を管理しています。

最近、構造を変更して、GLビューの上にボタンオーバーレイを含む2つのフルスクリーンビューを作成しました。これにより、iPhone4や第4世代iPodTouchなどの低速デバイスでのレンダリングフレームレートが低下しました。これは、既存のIB / UIKitアーキテクチャを使用して、フルコントロールレイアウトを一度に表示/非表示にするのを簡単にするために行いました。

年：

|-Root (GLKView)
|  |-Buttons

新しい：

|-Root  (GLKView)
|  |-Layout 1
|  |  |-Buttons 1
|  |-Layout 2
|  |  |-Buttons 2
(Etc...)

オーバーレイ（レイアウト1、2、...、n）は完全に透明で、画面の端に画像とテキストを含むいくつかのサブビュー（ボタン1、2、...、n）が含まれています。ビューがルートビューの直接の子孫である場合、これらのいくつかのボタンや物をオーバーレイするためのオーバーヘッドはそれほど悪くはありませんでしたが、フレームレートが大幅に低下したため、中央に余分な透明なビューがあると、パフォーマンスが低下したようです。

オーバーヘッドを減らすためにどのようなオプションがありますか？オーバーレイにはアニメーションや何かが起こっていないので、必要以上に再描画するべきではないと思います。パフォーマンスを低下させているのは、追加のアルファブレンドされたフルスクリーンオーバーレイである可能性があります。

hiddenすべてのUIViewのプロパティを、変更されているかどうかを確認せずにフレームごとに設定していますが、その結果、ビューに再描画が必要であるというフラグが立てられる可能性がありますか？

UIButtonsやUISwitches（画像とラベルを含むUIViewsのみ）などのiOSのネイティブコントロールを使用していないため、これらすべてのボタンをOpenGL描画に変換することは可能ですが、可能であれば避けたいと思います。

4

1 に答える 1

1

コストは、ボタンからではなく、OpenGLビューから発生します。それが変更されたとき、一番上のすべてを再合成する必要があります。

では、実用的な解決策として、レイアウトビューを捨てて、IBCollection代わりにsを使用するのはどうでしょうか。配列の反復を避けるために、実際の変更に対してのみ非表示のフラグをプッシュして変更することをお勧めしますが、以前と同じ全体的な合成コストが発生します。

したがって、次のように宣言します。

@property(retain) IBOutletCollection(UIView) NSArray *viewsInLayout1;

次に、インターフェイスデザイナで必要な数のビューにワイヤリングできます。その後、コードでは、あちこちでグループ化をハードコーディングすることなく、あるグループを別のグループと区別するためにviewsInLayout1反復できる（または可能な場合は使用する）配列ができます。makeObjectsPerformSelector:

于 2012-09-29T01:23:23.980 に答える