10

私はSurfaceViewを使用して、Androidアプリで大きな画像（通常は画面よりも大きいが、常にではない）を表示しています。これは非常に単純なグラフィックであり、OnTouchListenerまたはGestureDetectorを使用してスクロールを実装するのは簡単です。グラフィックはRenderループで実行されますが、パフォーマンスはすべての実際のデバイスに対して十分すぎるようです（ただし、エミュレーターは少し面倒な場合があります）。

画像にピンチとズームを実装することも検討していますが、OpenGLの経験がほとんどなく、OpenGLの使用はこれほど単純なものにはかなりやり過ぎのように思われるため、OpenGLに移動する必要はありません。

android.graphics.Cameraクラスを使用すると、必要なズーム機能を実装できるようになります。

基本的なAndroidSurfaceViewでのピンチズームのような機能の実装を示す良い例を知っている人はいますか？

また、このようなものを実装した場合、パフォーマンスについて何か考えはありますか？ここで必要なものが非常に単純であることを考えると、OpenGLは余分な手間をかける価値がありますか？

ここで質問が不明確ですか、それともAndroid開発者サイトで見つけたはずの目がくらむほど明白なドキュメント/コードが欠落していますか？

4

3 に答える 3

3

OK-ようやく実際に作業してこれについてしばらく研究する時間ができたので、私は実際に私が抱えていた問題を解決する解決策を見つけました。

このソリューションは、BitmapRegionDecoder（API10 +）に依存しています。これにより、アプリがビットマップ全体を一度にロードしようとするのではなく、ビットマップの一部をロードできるようになります。

ソリューションの本質：

  1. ビットマップ全体のダウンサンプリングされたバージョンがメモリに保持されます。このバージョンはダウンサンプリングされているため、永続的に保持できます。
  2. スレッドは、ビットマップの現在のビューポート（またはもう少し）を継続的にメモリにロードします（BitmapRegionDecoderを使用）。これはせいぜい画面よりわずかに大きいので、これもメモリに快適に収まるはずです。
  3. レンダリングスレッドは、適切なバージョンをCanvasに描画します。つまり、ズームアウトしている場合、またはビットマップが使用できない場合（たとえば、バックグラウンドでロードされているため）、ダウンサンプリングされたバージョンが使用されます。
  4. パン、フリング、ズームはGestureListenersで処理されます。

私が見つけたアイデアの最初の実装については、ジョン・ロンバルドの功績によるものです。

https://github.com/micabyte/android_gameで、他のユーティリティクラスと一緒に独自の実装をオープンソース化しました。

これはかなり最近の実装であるため、現時点では実際のユーザーからの火の洗礼はありませんでした。ただし、8000x4000ピクセルのビットマップを表示してテストを実行したところ、これまでのところ問題はありませんでした。パフォーマンスは確かに私のニーズには十分なようです。

于 2013-02-28T00:25:05.580 に答える
0

ピンチとズームの実装は、ScaleGestureDetectorと変換行列を使用したCanvasインターフェイスの組み合わせで行うことです。同じ変換行列を使用して、スケールと変換の両方を処理する必要があります。

于 2012-05-08T23:58:22.683 に答える
0

SonyEricsson開発者サイトのOneFingerZoomの例をご覧ください。 http://developer.sonymobile.com/wp/tag/zoom/

于 2012-05-09T00:08:16.453 に答える