私は現在ソフトウェアキーボードを実装しています（いくつかの洗練された予測を使用して）、そしてキャンバスを使用してそれを描くことはパフォーマンスの点で不十分です。フレームの描画時間が100ミリ秒をはるかに超えていますが、これは明らかに受け入れられません。
キーボード自体は約33個のキーで構成されており、各キーはdrawRoundRectとその上の単純なテキストを使用して描画されます。ウィジェットは一切使用されていないので、それは明白なパフォーマンスです。また、ほとんどすべてのGoogleのパフォーマンスのヒントが使用されているため、速度の理由でもありません。
私は今、openglに切り替えることが実際に意味をなすようになりましたが、openglベースのキーボードがバッテリー寿命に与える影響を考えるとまだ懐疑的です。
そのトピックに関する十分なドキュメントが見つからなかったので、ここの誰かが私を正しい方向に向けてくれることを願っています。
バッテリーをどれだけ消費するかに関係なく、ほとんどの既存のデバイスは同時に複数の OpenGL コンテキストをサポートしていないため、おそらくこれを実行したくないでしょう。自作。これらのデバイスでは、OpenGL コンテキストはフォアグラウンド アプリケーションによってのみ所有されます。ソフト キーボードのような UI の二次的な部分では使用できません。
また、前のポスターが言ったように、通常の描画を最適化する方法を検討するのが最善でしょう. ベクトルの描画は非常に遅いため、ビットマップ ブリットを実行するために事前にビットマップにレンダリングすると非常に役立ちます。また、変更されたウィンドウの部分だけを描画するように注意してください。UI を描画するのに 100 ミリ秒という時間は非常に長いため、かなりの最適化を行うことができます。プラットフォームの KeyboardView コード (標準のソフト キーボードとサンプル IME で使用されます) を確認することをお勧めします。これには、多くの同様の描画最適化が既に含まれています。
余談ですが、キーを一度レンダリングしてからスプライトとして取得し、これらをブリットすることを検討しましたか? ベクター グラフィックスのレンダリングよりもはるかに優れているはずです。
具体的な数値を示すことはできません (apphacker が指摘したように、これはデバイス固有のものです)。ただし、OpenGL がハードウェア アクセラレーションを使用しているため、より多くのバッテリーを使用する可能性がある場合でも、操作ははるかに高速に完了し、全体としてより少ない電力を使用するはずです。ハードウェアで高速化されていない場合、1 つの描画 API を別の描画 API と交換するだけなので、操作の完了に時間がかかる場合にのみ、より多くの電力を使用する必要があるのは当然のことです。全体として、外部イベントが発生したときにのみ描画する必要があるため、長期的にはあまり問題にならないはずです。おそらく、人々は 1 分間に数個のキーしか入力していないからです。
おそらく、それを実装して（おそらく単純化されたテストケースで）、測定を行う必要があります。