私は、この質問が広すぎてここで扱うことができないという Ivan の意見に同意します。とにかく、Android プラットフォームについて考慮すべき点がいくつかあります。
3D グラフィックス (OpenGL) を利用したい場合、ボトルネックに遭遇する可能性があります。これは、当面の間、ライブ カメラ プレビューと OpenGL サーフェス ビューを同じ画面で同時に表示することができないためです。問題は、いわゆる SurfaceView (OpenGL レンダリングとカメラのライブ プレビューに使用される) が、互いの上に重ねられるように設計されていないことです。そのため、表示順序 (ビデオ プレビューの背後にレンダリングされた 3D グラフィックス) に関して、予期しない結果が生じる可能性があります。
ただし、この問題には 2 つの解決策があります。
3D グラフィックスを使用せず、カメラ プレビューの上に 2D オブジェクトをレンダリングする手段に頼る
3D グラフィックスを使用しますが、カメラ プレビューをキャプチャし、YUV エンコード データを RGB に変換し (一部のデバイスでは、エンコードの非標準準拠のカスタマイズが原因で問題が発生します)、そのデータを OpenGL テクスチャにロードして、長方形のプリミティブに表示されます。このアプローチの問題点は、追加の処理オーバーヘッドによる速度の不足と、OpenGL に関連する制限のため、カメラ プレビュー テクスチャを縮小する必要がある可能性が高いことです。
さらに、オーバーレイ グラフィックス/仮想オブジェクトの変換に使用できるデバイスの回転行列を計算するためのモーション センサー データのキャプチャに慣れる必要があります。
AR アプリがキャプチャされたライブ ビデオ ストリームと「対話」することになっている場合、次のボトルネックの問題に遭遇します。それはあなたが何を達成しようとしているかに完全に依存します。人間の顔、特定の形状、バーコードなどを認識したいですか...要件が何であれ、Java実装はそれには遅すぎる可能性があり、NDKを使用してCコードを書くことに頼る必要があります(さまざまなハンドセットでの経験から)画像処理に関しては、はるかに高速になります)。そして、それがあなたがカバーする必要がある次のトピックです。また、画像処理に慣れる必要があります。しかし、まず第一に、仕様を作成します。AR アプリに実際に何が必要かを知る必要があります。
一部の最新の AR アプリは、キャプチャしたビデオ データを、形状/画像認識により多くの処理能力を備えたサーバーにライブ ストリーミングすることにも頼っています。
詳細については、トピックに関するこの修士論文を読むことができます。
要するに、AR アプリは非常に野心的なプロジェクトになる可能性があり、膨大な範囲のさまざまなテクノロジと分野が関与するということです。