一部のビューの背景を設定する最も良い方法は何ですか?例えばbackroundのの2つのバリエーション:勾配でより良いパフォーマンス、9パッチまたはdrawable xmlリソースにはどうすればよいですか?
- 背景には、ただ一つの色でコーナーとの国境
- 背景を四捨五入し、コーナー
ので変種の、より良い九パッチまたはだろう丸みを帯びましたdrawable xmlリソース?
一部のビューの背景を設定する最も良い方法は何ですか?例えばbackroundのの2つのバリエーション:勾配でより良いパフォーマンス、9パッチまたはdrawable xmlリソースにはどうすればよいですか?
ので変種の、より良い九パッチまたはだろう丸みを帯びましたdrawable xmlリソース?
私の推測では、NinePatch
はほとんどの場合わずかに速くなります。ここに私が見つけたものがあります。
GradientDrawable
(XMLでrectsのために使用されるもの)が順番にSkCanvas
、SkDraw
最終的にSkScan
とSkBlitter
につながるネイティブ呼び出しを使用Canvas
を介して呼び出すためthis codeを使用します。
一方、ネイティブcall to NinePatch.cpp
の前にNinePatch
's draw() has almost zero Java codeshortly calls NinePatchImpl.cpp
-- NinePatch_draw()
---それは魔法がある場所です。そこにあるコードは、マークされた領域を繰り返します。その後多くの呼び出しがSkDraw
(drawPath()
ではなくdrawRect()
ではなく)でほぼ同じロジックを使用して描画しますが、最終的には同じ作業を行うSkScan
とSkBlitter
と同じです。
すべてのコードは、すぐに私の頭を包み込むのはかなり難しいですが、私の目を引っ張ったのは、背景とストロークの両方がある場合(look here)、GradientDrawable
はネイティブスタック全体を2回呼び出します。 NinePatch
は1つだけです。
ので、実際にはほとんどの場合、私は感覚を得る両方のアプローチのための時間を測定することなくNinePatch
は、レースに勝利:我々は[ひどく]はおおよそdrawRect()
とdrawPath()
使用のためにそのネイティブコールスタックほとんど同じロジックとを前提とした場合[別のひどい単純化]NinePatch
とGradientDrawable
で作成されたパラメータセットは、メソッドの複雑さにあまり影響しません。NinePatch
は、塗りつぶしとアウトラインで約2倍の約2倍の速さです。まあ、通常の9セクションの9パッチ(つまり、非常に多くのマーカーで9パッチを細断しないで、過度に努力して、その反復を高価にしないでください)を使用する場合です。
これに遭遇して被験者の詳細を知っている(および/またはネイティブコードの複雑さを見積もる上でより良い)人は、間違っていると私を修正してください。
PSええ、私は私が知っているdont'tこれはストレートな答え
素晴らしい仕事、あなたの答えに感謝します。それはほとんど私が聞きたかったものです。あなたは私にソースでもっと深く見える良い例を示しました:) – cooperok
実際には、私は今答えを編集しています、私はいくつかのものを見落としたので、いくつかの議論を削除しています:)しかしafaik結果は同じ - 'NinePatches'勝。 –
+1。簡単な言葉で言えば、準備完了のピクセルデータと、手作業で生成されたCPUデータと余分なCPUサイクルを伴うものです。これは、一般的なコンピュータグラフィックスにおいても同様である。 –
の多くではありません知っています! :)しかし、標準的なアンドロイドのテーマは9patchを使用しているので、そうすることはあまりにも間違っているとは思わないでしょう。 – pumpkee
もし私がただ一つの色の背景が必要なのであれば、おそらくxmlのリソースがより速くなるでしょうか? 1つの色だけが必要な場合、少なくともxmlファイルは小さいサイズ – cooperok
になります。必要な画像リソースは不要xmlの設定は – MengMeng