ああ、そうだね。特に、Android 3より前のデバイスをターゲットにしている場合は、SurfaceView（Canvas.drawXxx（）呼び出しを使用）からOpenGlSurfaceに移行するとうまくいきます。1秒あたりのフレーム（更新）が高速になるだけでなく、メモリ消費量も大幅に向上します。
これが私が気付いたポイントのいくつかです：
- （マルチ）スプライトアニメーションを実行する場合は、OpenGLテクスチャとしてロードされ、OpenGLクワッドに表示される画像を使用してアニメーションを実行すると、より多くのメモリスペースが得られます。これは、通常のビットマップオブジェクトがプロセスあたりのAndroidのメモリ制限（デバイスとAndroidのバージョンに応じて16〜48 Mbのようなもの）によって制限されている一方で、それらの画像からOpenGLテクスチャを作成する（そして直後に画像をクリアする）ためです）この制限はありません。制限されるのは、デバイスの合計メモリ数が16〜48メガバイトを超える場合のみです。
次に、Android 2以下では、ビットマップインスタンスが必要とするメモリの量を追跡することは、Javaヒープメモリに対して報告されないため、非常に注意が必要です。それらは他のメモリスペースに割り当てられます。つまり、OpenGLを使用すれば、もう1つの手間が省けます。
OpenGLを使用すると、画像の回転などの単純なアニメーションが簡単になります。クワッドにテクスチャを付けてから、好きなようにローテーションします。スプライトアニメーションと同等の機能は、画像のさまざまな（回転バージョン）を順番に表示することです。これは、メモリ消費と速度に優れています。
2Dのようなゲームをしている場合、OpenGLの正射影を使用すると、通常のOpenGLパースペクティブ射影で発生する（この場合は役に立たない）面倒な作業が大幅に簡素化されるだけでなく、実際には多くの問題が軽減されます。すべてのグラフィック要素をスケーリングする必要がある場合は、通常のSurfaceViewを使用して、さまざまな画面解像度/比率で同じサイズに見えるようにします。OpenGLの正投影を使用すると、目的の幅と高さの固定領域を効果的に作成し、OpenGLにデバイスの画面領域に自動的に投影させることができます。
言うまでもなく、一部のグラフィック要素に影響を与える脈動するライトなどの単純なエフェクトを作成する方が、SurfaceViewとスプライトで焼いた。
私は実際にSurfaceViewとCanvasを使って小さな星空の防衛のようなゲームを開始し、その後すぐに上記の理由でOpenGLに切り替えました。簡単に言うと、ゲームの見た目は良くなり、最初はSamsungTEOSでは16UPS、Optimus LG2xでは30UPSで実行されていましたが、現在はTeosでは33 UPS、LG2xでは約80UPSで実行されています。