私はかなり奇妙な問題に遭遇しました。私はAndroid用のゲームを作っています。今まではベースライン(mdpi)の密度のスプライトを使っていました。基本的に私はすべてのスプライトを/res/drawable
フォルダにダンプします。画面密度の異なるフォルダはありません。私は現在、画面の密度がhdpiの物理デバイスで自分のアプリケーションをテストしていますので、当然/res/drawable-hdpi
というフォルダを作成し、そこにすべての拡大縮小ビットマップを配置しました。しかし、私のアプリは本当に遅く実行されているようだ。すべてのゲームオブジェクトを描画しアニメーション化しようとすると、巨大なラグがあります。これは/res/drawable
フォルダの内容を使用したときには発生しません。hdpiリソースを使用するとAndroidアプリが遅れる
私はAndroidManifest.xmlファイルのsupports-screens
タグで遊んだりしようとしましたが、実際にはあまり効果がなかったようです。これは私が持っていたものです:
<supports-screens android:resizeable="true"
android:smallScreens="false"
android:normalScreens="true"
android:largeScreens="true"
android:anyDensity="true"/>
は確かに、単にそれぞれのフォルダ内のスケールのバージョンをダンプするよりも異なる密度のためにビットマップを使用することによりがあります。
私はOpenGLに切り替えたくない段階にあります。これが私の最初のアプリだと考えて、私はCanvasを使って逃げることができると思う。また、OpenGLは2Dグラフィックスに関してはるかに優れていますか?私はそれが主に3Dグラフィックスで知られていると思った。意見ですか? – Dan
メモリとハードウェアアクセラレーションの問題が発生します。標準サーフェスは、ハードウェアアクセラレーションされておらず、VMメモリヒープに格納されています(途中では極端に制限されています)。 GLサーフェスはハードウェアアクセラレーテッドで、デバイス上のすべてのメモリにアクセスできます。 GLテクスチャを使用し、それを操作するためにGLエンジンを使用するときは、そのプロセスを高速化するためにハードウェアを使用しています。標準サーフェスを使用している場合は、ソフトウェアを使用してオブジェクトをスクリーンにブリッジしますが、これはもちろん速度がはるかに遅くなります。 – Salx