現在、ユーザーが描画できるアプリを実行しています。簡単に考えて、Canvas クラスを拡張するだけで、ほとんどのことが完了します。
それが私の最初の考えとアイデアでした。ただし、これはユーザーが画面に表示するものにすぎないため、キャンバスはかなり小さいため、描画するスペースはあまりありません。ドキュメントを調べてみるとtranslate()、キャンバスを移動できる方法が見つかりました。私が見つけたのは、それを動かすと、紙を動かすのと同じように、ある種の空白があるということです. 前に言ったように、これは完全に正常であることを理解しています-キャンバスは「画面」にすぎません。
私の質問は、無限のキャンバスのようなものを作成して、巨大な絵を作成し、すべてを移動できるようにする可能性はありますか?
この質問の前に、私はこのようなことができる方法について 2 つのことを考えていました。
キャンバス上のすべてのオブジェクトを同時に移動します。オブジェクトが多数ある場合、移動速度が非常に遅くなるため、悪い考えです。
移動するときと同様のことを
ListView行います（または、画面上で確認することをお勧めします）。画面上にあるビューと前後のビューのみがメモリにロードされ、残りは必要に応じて動的にアップロードされます。これは、この目標を達成するための最良の選択肢だと思います。
編集：
カイからの質問/回答は、質問を編集していくつかのことを明確にする価値があることを示しました。
ユーザーができることに関する基本的な仮定:
- ユーザーは、キャンバス上に描画可能 (ビットマップ) を持つ円と長方形のみを描画する機会が与えられます (約 80%)。
- すべての画面で、最大 500 ～ 800 個の長方形または円が表示されると想定しています。
まず最初に、無限大について考えていたのですが、非常に多くのスクリーンについて考えていました。ユーザーが行っていることにより大きな自由を与える必要があるだけです。
この画面では、通常の描画、拡大縮小 ( TouchListener、ScaleListener、DoubleTapListener) と同じようにすべての操作を行うことができます。スケーリングについて話すとき、キャンバスの「無限」に関連して関係しなければならないことがもう 1 つあります。ユーザーがズームアウトすると、実際にカメラをズームアウトするのと同じように、画面、または目に見えない「隣人」のより正確なオブジェクトが適切なスケーリングで表示されるはずです。
私が気付いたもう1つのことは、小さなズームレベルで描画する可能性です-つまり、2つまたは3つの画面でズームインします-それを切り取り、小さな部分として再計算する必要があると思います.
ハイエンドだけでなく、少なくとも API 10 以降のデバイスをサポートしたいと考えています。
時間に関する質問は最も重要です。すべてをできるだけスムーズにしたいので、ユーザーは毎回新しいキャンバスが作成されていることを知りません。