私が試みていることが悪い考えであるかどうか疑問に思っています。私は現在、モノタッチで作業中です。同じサイズのUIViewに画面サイズの（iPhone 4の約320x460の）バッファーを描画することが可能ですか？そのバッファーのアニメーション化された変更がエンドユーザーにスムーズに見えるように（drawあたり20ms程度必要です） 。クォーツパフォーマンスの大きなバッファーを描く
私はさまざまな実装を試みました。これまでの中で最も良い方法は、メモリ内のCGLayerを使用してcontext.DrawLayer（）を呼び出してDraw（）内のビューにそれを適用することです。しかしそれでもDrawLayerあたり30〜40msかかる。
私は独自のタイル画像コントロールを作成していますが、パフォーマンス以外の考えはうまくいきます。私はちょうど十分速くUIViewにバッファを取得する方法を把握することはできません。
アイデア？
最近私はカスタムビューを多く扱ってきましたが、パフォーマンス上の問題もたくさんありました。
これらのパフォーマンス上の問題はすべて、再描画が必要な要素を決定することで解決できます。さらに重要なことは、ではない要素はで再描画する必要があります。
次に、レイヤ内のコンテンツを個々のサブレイヤに分割し、必要に応じて再描画するだけです。良いことは、アニメーションなどは個々のレイヤーに対して非常にスムーズです。 （その内容は単純なビットマップであり、あなたがそれを伝えるまで変更されません）。
私が遭遇した唯一の制限は、サブレイヤに対してCGブレンドモード（例えば、乗算）を使用できないことでした。私が知る限り、それは不可能です。これらのブレンドモードは、サブレイヤの内容を描画するために使用されるCGコード内でのみ使用できますが、その後はすべて「通常」モードで構成されます。
本当にあなたが描いているものによって異なります。
単色で塗りつぶした色を描画するだけであれば問題ありません。問題は、あなたが変化している表面の大きさと、それをどのように変更しているかです。
また、描画する内容と、GPUに作業の一部をオフロードできるかどうかによって異なります。たとえば、インターフェイスの静的な部分が同じであるか、独立してアニメーション化/更新されている場合は、それらの領域に別のレイヤーを使用してGPUにそれらを合成させることができます。
レイヤーは、GPUによって合成され、独自のビットマップによってバッキングされるという利点があります。レイヤーの表面に描画すると、OSは結果をGPUにキャッシュし、すべてのレイヤーを同時に作成します。
次に、実際にアプリケーションのどの部分を再描画する必要があるのかを判断し、各フレームのセクションのみを再描画することができます。
しかし、やはりこれは本当にあなたがやろうとしていることに大きく依存します。
これは私が取ってきたアプローチです。問題は、私のレイヤーを常に更新する必要があることです。私は、Googleマップと同様の外観を実現しようとしています。私は、そのレイヤー/バッファーを更新してパフォーマンスを維持する方法を理解していません。それが静的にとどまるならば、私は問題がありません。 – Aaron
唯一の難しい部分は、バッファを絶えず更新する必要があることです。私は新しい画像タイル（Googleマップと思う）を常に読み込んでいますので、バッファーが大きく変わります。 – Aaron
私は本当にこの問題であなたを助けることができないことを申し訳ありません。別のアイデア：あなたのレイヤーは画面よりもかなり大きいですか？それらは私のケースでは巨大なパフォーマンスヒットでした...また、描画ルーチンが遅い部分であることは確かですか？ （そして、タイルをロードするコードではありませんか？） –
私は、CALayersを使用し、ユーザーが物事を移動しなくなったときに新しいバッファーを読み込むことによって、良いバランスを見つけたと思います。それは間違いなくコンテキストにビットマップを描画するように常にボトルネックと思われる。 – Aaron