私は、Facebook の Android ネイティブ アプリに非常によく似た機能を持つアプリを開発しています。これは、ユーザーがほとんどの時間を、ListView大量の画像の表示や画像ギャラリーへのアクセスなどに費やすソーシャル ネットワークです。
議論のために、スムーズなスクロールを実現するために、私が正しいことと Android のベストプラクティスをすべて実行しているとしましょう (ビューを適切にリサイクルする、必要に応じて異なるビュータイプを使用する、必要なサイズの拡大縮小されたビットマップのみをメモリに読み込む、ビットマップをキャッシュする、ViewHolder デザインパターンを使用する、可能な場合は UI スレッドをブロックしない、など)。
私のアプリの他の部分はすべて最善の方法で書かれており、ベストプラクティスに従っているとしましょう（議論のために... :->）
私のアプリはその段階ではまったく問題なく動作していましたが、ハードウェアアクセラレーションをオンにすると、Android 開発者向けドキュメント 私のアプリはよりスムーズかつ高速になりました。
UIに悪影響はないとしましょう。そして、私は何も実行していません。サポートされていない操作
この件に関する Google のドキュメントによると、この機能を使用しない唯一の理由は (すでに上で述べた他のすべての理由に加えて)、アプリがより多くの RAM を使用する可能性があることです。しかし、RAM はどのくらいでしょうか? かなり多く? アプリが大量の RAM を消費すると、メモリを解放する必要があるときに OS によって破棄される可能性が高いことはわかっています。
私の質問は基本的に -
- 私の状況ではこの機能を使用することは「OK」でしょうか?
- それを使用することで他にどのような問題が発生する可能性がありますか?
ティア
ベストアンサー1
使うか使わないか
ハードウェアアクセラレーションは、画像の拡大縮小、回転、移動などの複雑なカスタム計算を行う場合にのみ使用することをお勧めします。直線や曲線の描画（およびその他の簡単な操作）には使用しないでください（ソース）。
共通の遷移を計画しており、スケーリング、リサイクル、キャッシュなどをすでに考慮している場合は、プロジェクトにこれ以上負担をかけることは意味がないかもしれません。また、ハードウェア アクセラレーションをサポートするためにコードを作り直すのに費やした労力は、2013 年 5 月 8 日時点で市場の約 36% を占める 3.0 未満のバージョンのユーザーには影響しません。
メモリ
メモリ使用量については（この記事)、Android ハードウェアを組み込むことで、アプリケーションは各プロセスの OpenGL ドライバーを読み込み、約 2MB のメモリ使用量を 8MB に増やします。
その他の問題
API バージョンとは別に、バッテリー寿命にも影響すると思います。残念ながら、これについて線引きできるようなさまざまなユースケースのベンチマークはオンラインでは見つかりません。複数の GPU コアがあるため、特定のケースではアクセラレーションを使用するとバッテリー寿命が節約できると主張する人もいます。全体的に、影響はそれほど劇的ではないと思います (そうでなければ、Google はこれを主要なポイントにしていたでしょう)。